socket - einen Kommunikationsendpunkt erzeugen
Standard-C-Bibliothek (
libc,
-lc)
#include <sys/socket.h>
int socket(int Domain, int type, int Protokoll);
socket() erzeugt einen Kommunikationsendpunkt und gibt einen
Dateideskriptor zurück, der diesen Endpunkt referenziert. Der von einem
erfolgreichen Aufruf zurückgelieferte Dateideskriptor wird der
Dateidesriptor mit der niedrigsten Nummer sein, die noch nicht für den
Prozess offen ist.
Der Parameter
Domain spezifiziert eine Kommunikations-Domain; dies
wählt die Protokollfamilie aus, die benutzt werden soll. Diese Familien
sind in
<sys/socket.h> definiert. Zu den derzeit vom Linux Kernel
verstandenen Formaten gehören:
| Name |
Zweck |
Handbuchseite |
| AF_UNIX |
Lokale Kommunikation |
unix(7) |
| AF_LOCAL |
Synonym für AF_UNIX
|
|
| AF_INET |
IPv4-Internet-Protokolle |
ip(7) |
| AF_AX25 |
Amateurfunk-Protokoll AX.25 |
. ax25(4) |
| AF_IPX |
IPX-Novell-Protokolle |
|
| AF_APPLETALK |
AppleTalk |
ddp(7) |
| AF_X25 |
ITU-T-X.25- / ISO-8208-Protokoll |
x25(7) |
| AF_INET6 |
IPv6-Internet-Protokolle |
ipv6(7) |
| AF_DECnet |
DECet-Protokoll-Sockets |
|
| AF_KEY |
Schlüsselverwaltungsprotokoll, ursprünglich für den
Einsatz mit IPsec entwickelt |
|
| AF_NETLINK |
Kernel-Benutzerschnittstellengerät |
netlink(7) |
| AF_PACKET |
Systemnahe Paketschnittstelle |
packet(7) |
| AF_RDS |
. »Reliable Datagram Sockets (RDS)«-Protokoll |
. . rds(7) rds-rdma(7) |
| AF_PPPOX |
Generische PPP-Transportschicht, für die Einrichtung von
L2-Tunneln (L2TP und PPPoE) |
|
| AF_LLC |
. Logische-Link-Steuerung-Protokoll (IEEE 802.2 LLC) |
|
| AF_IB |
. Native InfiniBand-Adressierung |
|
| AF_MPLS |
. Multiprotocol Label Switching |
|
| AF_CAN |
. »Controller Area Network«-Automobilbusprotokoll |
|
| AF_TIPC |
. TIPC, »cluster domain sockets«-Protokoll |
|
| AF_BLUETOOTH |
. Systemnahes Bluetooth-Socket-Protokoll |
|
| AF_ALG |
. Schnittstelle zur Kernel-Crypto-API |
|
| AF_VSOCK |
. VSOCK- (ursprünglich »VMWare VSockets«-)Protokoll
für Hypervisor-Gast-Kommunikation |
vsock(7) |
| AF_KCM |
. KCM (kernel connection multiplexer)-Schnittstelle |
|
| AF_XDP |
. XDP (express data path)-Schnittstelle |
|
Weitere Details über die obigen Adressfamilien sowie Informationen
über eine Reihe anderer Adressfamilien kann in
address_families(7) gefunden werden.
Der Socket hat den in
type angegebenen Typ, welcher die
Kommunikationssemantik festlegt. Derzeit sind folgende Typen definiert:
- SOCK_STREAM
- Stellt sequentielle, zuverlässige,
verbindungsorientierte Zweiweg-Bytestreams bereit. Ein
»Out-of-Band«-Datenübertragungsmechanismus kann
unterstützt werden.
- SOCK_DGRAM
- Unterstützt Datagramme (verbindungslose,
unzuverlässige Nachrichten mit einer festen
Maximallänge).
- SOCK_SEQPACKET
- Bietet einen sequenziellen, verlässlichen,
verbindungsbasierten Zwei-Wege-Übertragungspfad für
Datagramme einer festen maximalen Länge; ein Abnehmer ist
erforderlich, um mit jedem Eingabe-Systemaufruf ein ganzes Paket zu
lesen.
- SOCK_RAW
- Bietet Zugriff auf das »rohe«
Netzwerkprotokoll.
- SOCK_RDM
- Bietet eine zuverlässige Datagramm-Ebene, die aber
keine Reihenfolge garantiert.
- SOCK_PACKET
- Veraltet und sollte nicht in neuen Programmen verwendet
werden; siehe packet(7).
Einige Socket-Typen sind möglicherweise nicht von allen Protokollfamilien
implementiert.
Seit Linux 2.6.27 dient das Argument
type einem zweiten Zweck:
Zusätzlich zur Angabe des Socket-Typs kann es ein bitweises ODER von
einem der folgenden Werte enthalten, um das Verhalten von
socket() zu
verändern:
- SOCK_NONBLOCK
- Setzt den Dateistatus-Schalter O_NONBLOCK für
die geöffnete Datei-Deskription (siehe open(2)), auf die
sich der neue Dateideskriptor bezieht. Die Verwendung dieses Schalters
spart zusätzliche Aufrufe von fcntl(2), um das gleiche
Ergebnis zu erreichen.
- SOCK_CLOEXEC
- Setzt den Schalter »Schließen bei
Ausführung« (close-on-exec, FD_CLOEXEC) für
den neuen Dateideskriptor. Lesen Sie die Beschreibung des Schalters
O_CLOEXEC in open(2), um die Gründe zu beleuchten,
warum dies nützlich sein könnte.
Das
Protokoll bezeichnet ein spezielles Protokoll, das auf diesem Socket
benutzt wird. Normalerweise gibt es nur ein einziges Protokoll, das von einem
speziellen Sockettyp einer Protokollfamilie unterstützt wird. In diesem
Fall kann
Protokoll als 0 angegeben werden. Nichtsdestotrotz ist es
möglich, dass mehrere Protokolle existieren. In diesem Fall muss das zu
Verwendende auf diese Art angegeben werden. Die Protokollnummer ist
individuell für die bestimmte »Kommunikations-Domain«.
Siehe dazu auch
protocols(5). Lesen Sie
getprotoent(3), um zu
erfahren, wie Sie die Protokollnamenzeichenketten auf Protokollnummern
abbilden.
Sockets des Typs
SOCK_STREAM sind Vollduplex-Byte-Streams. Sie erhalten
die Grenzen von Datensätzen nicht. Ein Stream-Socket muss sich in einem
connected-Status befinden, bevor mit ihm irgendwelche Daten gesendet
oder empfangen werden können. Eine Verbindung zu einem anderen Socket
wird mit
connect(2) hergestellt. Einmal verbunden können Daten
mit
read(2) und
write(2) übertragen werden bzw. mit
Varianten von
send(2) oder
recv(2). Wenn eine Sitzung
abgeschlossen ist, kann
close(2) ausgeführt werden. Out-of-band
Daten können, wie in
send(2) und
recv(2) beschrieben,
gesendet und empfangen werden.
Die Kommunikationsprotokolle, die ein
SOCK_STREAM implementieren,
gewährleisten, dass die Daten nicht verloren gehen oder dupliziert
werden. Falls ein Datenelement, für das das Peer-Protokoll Platz im
Pufferspeicher bereithält, nicht erfolgreich innerhalb einer
angemessenen Zeitspanne übertragen werden kann, dann wird die
Verbindung als »tot« betrachtet. Falls
SO_KEEPALIVE
für den Socket aktiviert ist, überprüft das Protokoll auf
eine protokollspezifische Weise, ob das andere Ende »noch am
Leben« ist. Es wird ein
SIGPIPE-Signal ausgelöst, wenn
ein Prozess auf einem unterbrochenen Stream sendet oder empfängt; naive
Prozesse, die das Signal nicht abfangen, werden beendet.
SOCK_SEQPACKET-Sockets verwenden die gleichen Systemaufrufe wie
SOCK_STREAM-Sockets. Der einzige Unterschied ist, dass Aufrufe von
read (2) nur die Menge an angeforderten Daten zurückgeben und
alle verbleibenden Daten im ankommenden Paket verwerfen. Ebenso werden alle
Nachrichtengrenzen in eingehenden Datagrammen beibehalten.
SOCK_DGRAM- und
SOCK_RAW-Sockets ermöglichen das Senden von
Datagrammen zu Empfängern, die in
send(2)-Aufrufen benannt
werden. Datagramme werden grundsätzlich mit
recvfrom(2)
empfangen, das das nächste Datagramm zusammen mit der Absenderadresse
zurückliefert.
SOCK_PACKET ist ein veralteter Socket-Typ für den Empfang von
Rohdaten direkt vom Treiber. Verwenden Sie stattdessen
packet(7).
Mit einer
fcntl(2)-
F_SETOWN-Operation kann ein Prozess oder eine
Prozessgruppe angegeben werden, der/die ein
SIGURG empfangen soll, wenn
Out-of-Band-Daten eintreffen, oder
SIGPIPE, wenn eine
SOCK_STREAM-Verbindung unerwartet unterbrochen wird. Diese Aktion kann
auch verwendet werden, um den Prozess oder die Prozessgruppe festzulegen,
welche(r) die E/A und die asynchrone Benachrichtigung über
E/A-Ereignisse mittels
SIGIO empfängt. Die Verwendung von
F_SETOWN entspricht einem Aufruf von
ioctl(2) mit den Argumenten
FIOSETOWN oder
SIOCSPGRP.
Wenn das Netzwerk dem Protokollmodul einen Fehlerzustand signalisiert (z.B.
mittels einer ICMP-Nachricht für IP) wird für den Socket der
Schalter für einen anstehenden Fehler gesetzt. Die nächste
Operation auf diesem Socket liefert den Fehlercode des anstehenden Fehlers.
Bei manchen Protokollen ist es möglich, für jeden Socket eine
Fehler-Warteschlange zu aktivieren, um detaillierte Informationen über
den Fehler abrufen zu können; siehe
IP_RECVERR in
ip(7).
Die Arbeitsweise von Sockets wird von Socket-Level-
Optionen gesteuert.
Diese sind in der Include-Datei
<sys/socket.h> definiert.
setsockopt(2) und
getsockopt(2) werden verwendet, um diese
Optionen zu setzen und zu lesen.
Bei Erfolg wird ein Dateideskriptor für den neuen Socket
zurückgegeben. Bei einem Fehler wird -1 zurückgegeben und
errno gesetzt, um den Fehler anzuzeigen.
- EACCES
- Es ist dem Prozess nicht erlaubt, einen Socket von
angegebenen Typ und/oder Protokoll zu erzeugen.
- EAFNOSUPPORT
- Die Implementierung unterstützt die angegebene
Adressfamilie nicht.
- EINVAL
- Unbekanntes Protokoll oder Protokollfamilie nicht
verfügbar.
- EINVAL
- Ungültige Schalter in type.
- EMFILE
- Die Beschränkung pro Prozess der Anzahl offener
Datei-Deskriptoren wurde erreicht.
- ENFILE
- Die systemweite Beschränkung für die
Gesamtzahl offener Dateien wurde erreicht.
-
ENOBUFS oder ENOMEM
- Es ist nicht ausreichend Speicher verfügbar. Der
Socket kann nicht erzeugt werden, bis ausreichend Ressourcen freigegeben
wurden.
- EPROTONOSUPPORT
- Der Protokolltyp oder das angegebene Protokoll wird von
dieser Kommunikations-Domain nicht unterstützt.
Andere Fehler können von den unterliegenden Protokollmodulen erzeugt
werden.
POSIX.1-2001, POSIX.1-2008, 4.4BSD.
Die Schalter
SOCK_NONBLOCK und
SOCK_CLOEXEC sind
Linux-speziifisch.
socket() erschien in 4.2BSD. Es ist grundsätzlich zu/von
Nicht-BSD-Systemen portierbar, die Clone der BSD-Socket-Schicht
unterstützen (einschließlich System-V-Varianten).
Die unter 4.x BSD verwendeten Manifest-Konstanten für Protokollfamilien
sind
PF_UNIX,
PF_INET und so weiter, währen
AF_UNIX,
AF_INET und so weiter für Adressfamilien
verwendet werden. Jedoch verspricht schon die BSD-Handbuchseite:»The
protocol family generally is the same as the address family« und
nachfolgende Standards verwenden überall AF_.
Ein Beispiel für die Verwendung von
socket() ist in
getaddrinfo(3) dargestellt.
accept(2),
bind(2),
close(2),
connect(2),
fcntl(2),
getpeername(2),
getsockname(2),
getsockopt(2),
ioctl(2),
listen(2),
read(2),
recv(2),
select(2),
send(2),
shutdown(2),
socketpair(2),
write(2),
getprotoent(3),
address_families(7),
ip(7),
socket(7),
tcp(7),
udp(7),
unix(7)
“An Introductory 4.3BSD Interprocess Communication Tutorial” und
“BSD Interprocess Communication Tutorial”, nochmals in
UNIX
Programmer's Supplementary Documents Volume 1 gedruckt.
Die deutsche Übersetzung dieser Handbuchseite wurde von Martin Schulze
<
[email protected]>, Sebastian Rittau
<
[email protected]>, Helge Kreutzmann
<
[email protected]>, Martin Eberhard Schauer
<
[email protected]>, Mario Blättermann
<
[email protected]> und Dr. Tobias Quathamer
<
[email protected]> erstellt.
Diese Übersetzung ist Freie Dokumentation; lesen Sie die
GNU
General Public License Version 3 oder neuer bezüglich der
Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.
Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken
Sie bitte eine E-Mail an die
Mailingliste
der Übersetzer