Provided by: manpages-de-dev_2.5-1_all 
BEZEICHNUNG
socket - einen Kommunikationsendpunkt erzeugen
ÜBERSICHT
#include <sys/types.h> /* Siehe ANMERKUNGEN */
#include <sys/socket.h>
int socket(int domain, int type, int protocol);
BESCHREIBUNG
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 verstandenen Formaten gehören:
Name Zweck Handbuchseite
AF_UNIX, AF_LOCAL Lokale Kommunikation unix(7)
AF_INET IPv4-Internet-Protokolle ip(7)
AF_INET6 IPv6-Internet-Protokolle ipv6(7)
AF_IPX IPX-Novell-Protokolle
AF_NETLINK Kernel-Benutzerschnittstellengerät netlink(7)
AF_X25 ITU-T-X.25- / ISO-8208-Protokoll x25(7)
AF_AX25 Amateurfunk-Protokoll AX.25
AF_ATMPVC Zugriff auf unbearbeitete ATM PVCs
AF_APPLETALK AppleTalk ddp(7)
AF_PACKET Systemnahe Paketschnittstelle packet(7)
AF_ALG Schnittstelle zur
Kernel-Crypto-API
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 den neu geöffneten
Dateideskriptor. 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 protocol 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 protocol 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 Operation
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 bzw. zu lesen.
RÜCKGABEWERT
Bei Erfolg wird ein Dateideskriptor für den neuen Socket zurückgegeben. Bei einem Fehler
wird -1 zurückgegeben und errno entsprechend gesetzt.
FEHLER
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.
KONFORM ZU
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).
ANMERKUNGEN
POSIX.1 erfordert nicht, dass <sys/types.h> eingebunden wird. Diese Header-Datei ist in
Linux nicht erforderlich. Allerdings benötigen einige historische Implementierungen (BSD)
diese Header-Datei. Es wird empfohlen, sie für portierbare Anwendungen einzubinden.
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_.
Der AF_ALG-Protokolltyp wurde in Linux 2.6.38 hinzugefügt. Weitere Informationen zu dieser
Schnittstelle finden Sie in der Kernel-Dokumentation auf
https://www.kernel.org/doc/htmldocs/crypto-API/User.html.
BEISPIEL
Ein Beispiel für die Verwendung von socket() ist in getaddrinfo(3) dargestellt.
SIEHE AUCH
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), 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.
KOLOPHON
Diese Seite ist Teil der Veröffentlichung 4.15 des Projekts Linux-man-pages. Eine
Beschreibung des Projekts, Informationen, wie Fehler gemeldet werden können sowie die
aktuelle Version dieser Seite finden sich unter https://www.kernel.org/doc/man-pages/.
ÜBERSETZUNG
Die deutsche Übersetzung dieser Handbuchseite wurde von Martin Schulze
<joey@infodrom.org>, Sebastian Rittau <srittau@jroger.in-berlin.de>, Helge Kreutzmann
<debian@helgefjell.de>, Martin Eberhard Schauer <Martin.E.Schauer@gmx.de>, Mario
Blättermann <mario.blaettermann@gmail.com> und Dr. Tobias Quathamer <toddy@debian.org>
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 <debian-l10n-german@lists.debian.org>.