.\" -*- coding: UTF-8 -*- .\" t .\" Copyright (c) 1983, 1991 The Regents of the University of California. .\" All rights reserved. .\" .\" Redistribution and use in source and binary forms, with or without .\" modification, are permitted provided that the following conditions .\" are met: .\" 1. Redistributions of source code must retain the above copyright .\" notice, this list of conditions and the following disclaimer. .\" 2. Redistributions in binary form must reproduce the above copyright .\" notice, this list of conditions and the following disclaimer in the .\" documentation and/or other materials provided with the distribution. .\" 3. All advertising materials mentioning features or use of this software .\" must display the following acknowledgement: .\" This product includes software developed by the University of .\" California, Berkeley and its contributors. .\" 4. Neither the name of the University nor the names of its contributors .\" may be used to endorse or promote products derived from this software .\" without specific prior written permission. .\" .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE .\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF .\" SUCH DAMAGE. .\" .\" $Id: socket.2,v 1.4 1999/05/13 11:33:42 freitag Exp $ .\" .\" Modified 1993-07-24 by Rik Faith .\" Modified 1996-10-22 by Eric S. Raymond .\" Modified 1998, 1999 by Andi Kleen .\" Modified 2002-07-17 by Michael Kerrisk .\" Modified 2004-06-17 by Michael Kerrisk .\" .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH SOCKET 2 "19. Januar 2009" Linux Linux\-Programmierhandbuch .SH BEZEICHNUNG socket \- einen Kommunikationsendpunkt erzeugen .SH ÜBERSICHT \fB#include \fP /* Siehe ANMERKUNGEN */ .br \fB#include \fP .sp \fBint socket(int \fP\fIdomain\fP\fB, int \fP\fItype\fP\fB, int \fP\fIprotocol\fP\fB);\fP .SH BESCHREIBUNG \fBsocket\fP() erzeugt einen Kommunikationsendpunkt und gibt einen Deskriptor zurück. .PP Der Parameter \fIdomain\fP spezifiziert eine Kommunikations\-Domain; dies wählt die Protokollfamilie aus, die benutzt werden soll. Diese Familien sind in \fI\fP definiert. Zu den derzeit verstandenen Formaten gehören: .TS tab(:); l l l. Name:Zweck:Handbuchseite T{ \fBAF_UNIX\fP, \fBAF_LOCAL\fP T}:T{ Lokale Kommunikation T}:T{ \fBunix\fP(7) T} T{ \fBAF_INET\fP T}:IPv4\-Internet\-Protokolle:T{ \fBip\fP(7) T} T{ \fBAF_INET6\fP T}:IPv6\-Internet\-Protokolle:T{ \fBipv6\fP(7) T} T{ \fBAF_IPX\fP T}:IPX\-Novell\-Protokolle: T{ \fBAF_NETLINK\fP T}:T{ Kernel\-Benutzerschnittstellengerät T}:T{ \fBnetlink\fP(7) T} T{ \fBAF_X25\fP T}:ITU\-T\-X.25\- / ISO\-8208\-Protokoll:T{ \fBx25\fP(7) T} T{ \fBAF_AX25\fP T}:T{ Amateurfunk\-Protokoll AX.25 T}: T{ \fBAF_ATMPVC\fP T}:Zugriff auf unbearbeitete ATM PVCs: T{ \fBAF_APPLETALK\fP T}:Appletalk:T{ \fBddp\fP(7) T} T{ \fBAF_PACKET\fP T}:T{ Systemnahe Paketschnittstelle T}:T{ \fBpacket\fP(7) T} .TE .PP Der Socket hat den in \fItype\fP angegebenen Typ, welcher die Kommunikationssemantik festlegt. Derzeit sind folgende Typen definiert: .TP 16 \fBSOCK_STREAM\fP Stellt sequentielle, zuverlässige, verbindungsorientierte Zweiweg\-Bytestreams bereit. Ein »Out\-of\-Band«\-Datenübertragungsmechanismus kann unterstützt werden. .TP \fBSOCK_DGRAM\fP Unterstützt Datagramme (verbindungslose, unzuverlässige Nachrichten mit einer festen Maximallänge). .TP \fBSOCK_SEQPACKET\fP 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. .TP \fBSOCK_RAW\fP Bietet Zugriff auf das »rohe« Netzwerkprotokoll. .TP \fBSOCK_RDM\fP Bietet eine zuverlässige Datagramm\-Ebene, die aber keine Reihenfolge garantiert. .TP \fBSOCK_PACKET\fP Veraltet und sollte nicht in neuen Programmen verwendet werden; siehe \fBpacket\fP(7). .PP Einige Socket\-Typen sind möglicherweise nicht von allen Protokollfamilien implementiert; beispielsweise ist \fBSOCK_SEQPACKET\fP nicht für \fBAF_INET\fP implementiert. .PP Seit Linux 2.6.27 dient das Argument \fItype\fP 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 \fBsocket\fP() zu verändern: .TP 16 \fBSOCK_NONBLOCK\fP setzt den Dateistatus\-Schalter \fBO_NONBLOCK\fP für die neue offene Dateibeschreibung. Die Verwendung dieses Schalters spart zusätzliche Aufrufe von \fBfcntl\fP(2), um das gleiche Ergebnis zu erreichen. .TP \fBSOCK_CLOEXEC\fP Setzt den Schalter »schließen bei Ausführung« (close\-on\-exec, \fBFD_CLOEXEC\fP) für den neuen Dateideskriptor. Die Beschreibung des Schalters \fBO_CLOEXEC\fP in \fBopen\fP(2) begründet, warum das nützlich sein kann. .PP Das \fIprotocol\fP 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 \fIprotocol\fP 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 \fBprotocols\fP(5). Lesen Sie \fBgetprotoent\fP(3), um zu erfahren, wie Sie die Protokollnamenzeichenketten auf Protokollnummern abbilden. .PP Sockets des Typs \fBSOCK_STREAM\fP sind Vollduplex\-Byte\-Streams, ähnlich wie Pipes. Sie erhalten die Grenzen von Datensätzen nicht. Ein Stream\-Socket muss sich in einem \fIconnected\fP\-Status befinden, bevor mit ihm irgendwelche Daten gesendet oder empfangen werden können. Eine Verbindung zu einem anderen Socket wird mit \fBconnect\fP(2) hergestellt. Einmal verbunden können Daten mit \fBread\fP(2) und \fBwrite\fP(2) übertragen werden bzw. mit Varianten von \fBsend\fP(2) oder \fBrecv\fP(2). Wenn eine Sitzung abgeschlossen ist, kann \fBclose\fP(2) ausgeführt werden. Out\-of\-band Daten können, wie in \fBsend\fP(2) und \fBrecv\fP(2) beschrieben, gesendet und empfangen werden. .PP Die Kommunikationsprotokolle, die ein \fBSOCK_STREAM\fP 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 \fBSO_KEEPALIVE\fP 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 \fBSIGPIPE\fP\-Signal ausgelöst, wenn ein Prozess auf einem unterbrochenen Stream sendet oder empfängt; naive Prozesse, die das Signal nicht abfangen, werden beendet. \fBSOCK_SEQPACKET\fP\-Sockets verwenden die gleichen Systemaufrufe wie \fBSOCK_STREAM\fP\-Sockets. Der einzige Unterschied ist, dass Aufrufe von \fBread\fP (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. .PP \fBSOCK_DGRAM\fP\- und \fBSOCK_RAW\fP\-Sockets ermöglichen das Senden von Datagrammen zu Empfängern, die in \fBsend\fP(2)\-Aufrufen benannt werden. Datagramme werden grundsätzlich mit \fBrecvfrom\fP(2) empfangen, das das nächste Datagramm zusammen mit der Absenderadresse zurückliefert. .PP \fBSOCK_PACKET\fP ist ein veralteter Socket\-Typ für den Empfang von Rohdaten direkt vom Treiber. Verwenden Sie stattdessen \fBpacket\fP(7). .PP Mit einer \fBfcntl\fP(2)\-\fBF_SETOWN\fP\-Operation kann ein Prozess oder eine Prozessgruppe angegeben werden, der/die ein \fBSIGURG\fP empfangen soll, wenn Out\-of\-Band\-Daten eintreffen, oder \fBSIGPIPE\fP, wenn eine \fBSOCK_STREAM\fP\-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 \fBSIGIO\fP empfängt. Die Verwendung von \fBF_SETOWN\fP entspricht einem Aufruf von \fBioctl\fP(2) mit den Argumenten \fBFIOSETOWN\fP oder \fBSIOCSPGRP\fP. .PP 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 \fBIP_RECVERR\fP in \fBip\fP(7). .PP Die Arbeitsweise von Sockets wird von Socket\-Level\-\fIOptionen\fP gesteuert. Diese sind in der Include\-Datei \fI\fP definiert. \fBsetsockopt\fP(2) und \fBgetsockopt\fP(2) werden verwendet, um diese Optionen zu setzen bzw. zu lesen. .SH RÜCKGABEWERT Bei Erfolg wird ein Dateideskriptor für den neuen Socket zurückgegeben. Bei einem Fehler wird \-1 zurückgegeben und \fIerrno\fP entsprechend gesetzt. .SH FEHLER .TP \fBEACCES\fP Es ist dem Prozess nicht erlaubt, einen Socket von angegebenen Typ und/oder Protokoll zu erzeugen. .TP \fBEAFNOSUPPORT\fP Die Implementierung unterstützt die angegebene Adressfamilie nicht. .TP \fBEINVAL\fP Unbekanntes Protokoll oder Protokollfamilie nicht verfügbar. .TP \fBEINVAL\fP .\" Since Linux 2.6.27 Ungültige Schalter in \fItype\fP. .TP \fBEMFILE\fP Überlauf der Prozessdateitabelle .TP \fBENFILE\fP Der Systemschwellwert für die Anzahl geöffneter Dateien ist erreicht. .TP \fBENOBUFS\fP oder \fBENOMEM\fP Es ist nicht ausreichend Speicher verfügbar. Der Socket kann nicht erzeugt werden, bis ausreichend Ressourcen freigegeben wurden. .TP \fBEPROTONOSUPPORT\fP Der Protokolltyp oder das angegebene Protokoll wird von dieser Kommunikations\-Domain nicht unterstützt. .PP Andere Fehler können von den unterliegenden Protokollmodulen erzeugt werden. .SH "KONFORM ZU" 4.4BSD, POSIX.1\-2001. Die Schalter \fBSOCK_NONBLOCK\fP und \fBSOCK_CLOEXEC\fP sind Linux\-speziifisch. \fBsocket\fP() 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). .SH ANMERKUNGEN POSIX.1\-2001 erfordert nicht, dass \fI\fP 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 \fBPF_UNIX\fP, \fBPF_INET\fP und so weiter, währen \fBAF_UNIX\fP, \fBAF_INET\fP 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_. .SH BEISPIEL Ein Beispiel für die Verwendung von \fBsocket\fP() ist in \fBgetaddrinfo\fP(3) dargestellt. .SH "SIEHE AUCH" \fBaccept\fP(2), \fBbind\fP(2), \fBconnect\fP(2), \fBfcntl\fP(2), \fBgetpeername\fP(2), \fBgetsockname\fP(2), \fBgetsockopt\fP(2), \fBioctl\fP(2), \fBlisten\fP(2), \fBread\fP(2), \fBrecv\fP(2), \fBselect\fP(2), \fBsend\fP(2), \fBshutdown\fP(2), \fBsocketpair\fP(2), \fBwrite\fP(2), \fBgetprotoent\fP(3), \fBip\fP(7), \fBsocket\fP(7), \fBtcp\fP(7), \fBudp\fP(7), \fBunix\fP(7) .PP \(lqAn Introductory 4.3BSD Interprocess Communication Tutorial\(rq ist in \fIUNIX Programmer's Supplementary Documents Volume 1\fP nochmals gedruckt. .PP \(lqBSD Interprocess Communication Tutorial\(rq ist in \fIUNIX Programmer's Supplementary Documents Volume 1\fP nochmals gedruckt. .SH KOLOPHON Diese Seite ist Teil der Veröffentlichung 3.42 des Projekts Linux\-\fIman\-pages\fP. Eine Beschreibung des Projekts und Informationen, wie Fehler gemeldet werden können, finden sich unter http://www.kernel.org/doc/man\-pages/. .SH ÜBERSETZUNG Die deutsche Übersetzung dieser Handbuchseite wurde von Martin Schulze , Sebastian Rittau , Helge Kreutzmann und Martin Eberhard Schauer 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 .