jammy (2) socket.2.gz

BEZEICHNUNG

       socket - einen Kommunikationsendpunkt erzeugen

ÜBERSICHT

       #include <sys/types.h> /* Siehe ANMERKUNGEN */
       #include <sys/socket.h>

       int socket(int Domain, int type, int Protokoll);

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  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(7)
                    (RDS)«-Protokoll                           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   vsock(7)
                    VSockets«-)Protokoll                 für
                    Hypervisor-Gast-Kommunikation
       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.

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_.

BEISPIELE

       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), 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.

KOLOPHON

       Diese  Seite  ist  Teil  der  Veröffentlichung  5.10  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
       ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ 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 ⟨debian-l10n-german@lists.debian.org⟩.