.\" 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.
.\"
.\"     @(#)socket.2	6.8 (Berkeley) 3/10/91
.\"
.\" Modified Sat Jul 24 10:36:46 1993 by Rik Faith (faith@cs.unc.edu)
.\" Translated into german by Martin Schulze (joey@infodrom.north.de)
.\" Modified Mon Jun 10 22:47:47 1996 by Martin Schulze (joey@linux.de)
.\"
.TH SOCKET 2 "2. Mai 1996" "BSD Man Page" "Systemaufrufe"
.SH BEZEICHNUNG
socket \- erzeuge einen Kommunikationsendpunkt
.SH SYNTAX
.B #include <sys/types.h>
.br
.B #include <sys/socket.h>
.sp
.BI "int socket(int " domain ", int " type ", int " protocol );
.SH BESCHREIBUNG
.B Socket
erzeugt einen Kommunikationsendpunkt und gibt den zugehrigen
Deskriptor zurck.

Der Parameter
.I domain
spezifiziert die Kommunikationsdomain, in der die Kommunikation
stattfinden soll, also die Protokollfamilie, die benutzt werden
soll.  Diese Familien sind in der Include-Datei 
.I <sys/socket.h>
definiert.

Zur Zeit werden folgende Domains untersttzt:

.RS
.TP 0.9i
.B AF_UNIX
(UNIX interne Protokolle)
.TP
.B AF_INET
(ARPA Internet Protokolle)
.TP
.B AF_ISO
(ISO Protokolle)
.TP
.B AF_NS
(Xerox Network Systems Protokolle)
.TP
.B AF_IMPLINK
(IMP \*(lqhost at IMP\*(rq Link Ebene)
.RE

Der Socket hat den in
.I type
angegebenen Typ, der die Art der Kommunikation bestimmt.  Zur Zeit
sind folgende Arten definiert:

.RS
.nf
SOCK_STREAM
SOCK_DGRAM
SOCK_RAW
SOCK_SEQPACKET
SOCK_RDM
.fi
.RE

Ein Socket vom Typ
.B SOCK_STREAM
stellt einen sequenziellen, verllichen, zwei-weg-basierten
Byte-Stream zur Verfgung.  Ein "out-of-band" bertragungsmechanismus
kann untersttzt werden.  Ein Socket vom Typ
.B SOCK_DGRAM
bietet Datagramme (verbindungslos, unverlliche Nachricht einer
festen (meist kleinen) maximalen Lnge).  Ein
.B SOCK_SEQPACKET
Socket kann einen sequenziellen, verllichen, zwei-weg-basierten
bertragungspfad fr Datagramme einer festen maximalen Lnge
bieten.  Mglicherweise wird vom lokalen Endpunkt erwartet, da er
ein komplettes Paket mit jedem read System-Call liest.  Diese Art ist
protokollspezifisch und zur Zeit nur fr
.B AF_NS
implementiert.
.B SOCK_RAW
Sockets stellen Zugriff auf interne Netzwerkprotokolle und
Schnittstellen zur Verfgung.  Die Typen
.BR SOCK_RAW ,
der nur fr den Superuser (=root) zugnglich ist, und
.BR SOCK_RDM ,
der geplant aber noch nicht implementiert ist, werden hier nicht
beschrieben.

Das
.I protocol
bezeichnet ein spezielles Protokoll, das auf diesem Socket benutzt
wird.  Normalerweise gibt es nur ein einziges Protokoll, das von einem
speziellen Socket einer Protokollfamilie untersttzt
wird.  Nichtsdestotrotz ist es mglich, da mehrere Protokolle
existieren.  In diesem Fall mu das zu verwendende auf diese Art
angegeben werden.  Die Protokollnummer ist individuell fr eine
bestimmte "Kommunikationsdomain".  Siehe dazu auch
.BR protocols (5).

Sockets des Typs
.B SOCK_STREAM
sind voll-duplex-orientierte Byte-Streams, hnlich wie Pipes.  Ein
Stream-Socket mu sich in einem 
.I connected
Stadium befinden bevor mit ihm irgendwelche Daten gesendet oder
empfangen werden knnen.  Eine Verbindung zu einem anderen Socket wird
mit 
.BR connect (2)
hergestellt.  Einmal verbunden knnen Daten mit
.BR read (2)
und
.BR write (2)
bertragen werden bzw. mit Varianten von
.BR send (2)
oder
.BR recv (2).
Wenn eine Verbindung abgebaut werden soll, wird
.BR close (2)
ausgefhrt.  Out-of-band Daten knnen, wie in 
.BR send (2)
beschrieben, gesendet und, wie in
.BR recv (2)
beschrieben, empfangen werden.

Die Kommunikationsprotokolle, die verwendet werden, um ein
.B SOCK_STREAM
zu implementieren, stellen sicher, da Daten weder verloren gehen
noch verdoppelt werden.  Wenn ein Datum, fr das das Partnerprotokoll
ausreichend Puffer zur Verfgung hat, in einem angemessenen Zeitraum
nicht erfolgreich bertragen werden kann, wird angenommen, da die
Verbindung kaputt ("broken") ist und Aufrufe zeigen einen Fehler an,
indem sie \-1 zurckgeben und 
.B ETIMEDOUT
als entsprchenden Wert in der globalen Variable
.I errno 
setzen.  Die Protokolle halten den Socket unter Umstnden
.IR warm ,
indem sie ca. jede Minute eine bertragung erzwingen, wenn keine
anderen Aktivitten vorliegen.  Ein Fehler wird angezeigt, wenn keine
Antwort auf einer sonst stillen Verbindung in einer erweiterten
Zeitspanne (z.B. 5 Minuten) erzielt werden kann.  Ein
.BR SIGPIPE -Signal
wird erzeugt, wenn ein Proze auf einen kaputten Stream sendet; das
verursacht bei naive Prozesse, die das Signal nicht verarbeiten, ein
Programmende.

.BR SOCK_SEQPACKET -Sockets
setzen dieselben Systemcalls ein wie
.BR SOCK_STREAM -Sockets.
Der einzige Unterschied besteht darin, da
.BR read (2)
nur die angeforderte Menge an Daten zurckliefert und alle restlichen
verwirft.

.BR SOCK_DGRAM "\-"
und
.BR SOCK_RAW "\-Sockets"
erlauben das Senden von Datagrammen zu Empfngern, die im 
.BR send (2)
Aufruf genannt werden.  Datagramme werden grundstzlich mit
.BR recvfrom (2)
empfangen, das das nchste Datagramm zusammen mit der Absenderadresse
zurckliefert.

Ein
.BR fcntl (2)
Aufruf kann benutzt werden, um ein Prozegruppe zu spezifizieren, die
ein 
.BR SIGURG "\-Signal"
empfangen soll, wenn out-of-band Daten ankommen.  So kann ebenfalls
eingestellt werden, da non-blocking I/O und asynchrone
Benachrichtigung von I/O Ereignissen  via
.B SIGIO 
vorgenommen werden.

Die Arbeitsweise von Sockets wird von
.RB Socket-Level- Optionen
gesteuert.  Diese sind in der Include-Datei
.I <sys/socket.h> 
definiert.
.BR Setsockopt (2)
und
.BR getsockopt (2)
werden verwendet, um diese Optionen zu setzen bzw. zu lesen.

.SH "RCKGABEWERTE"
\-1 wird zurckgegeben, wenn ein Fehler auftritt, ansonsten wird die
Nummer des Deskriptors zurckgegeben, der den Socket referenziert.

.SH FEHLER
.TP 0.8i
.B EPROTONOSUPPORT
Der Protokolltyp, der in
.I protocol
angegeben ist, wird nicht von dieser Kommunikationsdomain
untersttzt.
.TP
.B EMFILE
Die Deskriptor-Tabelle des Prozesses ist voll.
.TP
.B ENFILE
Die System-Dateitabelle ist voll.
.TP
.B EACCESS
Es ist dem Prozess nicht erlaubt, einen Socket von angegebenen Tyo
und/oder Protokoll zu erzeugen.
.TP
.B ENOBUFS
Es ist nicht ausreichend Speicher verfgbar.  Der Socket kann nicht
erzeugt werden bis ausreichend Resourcen freigemacht wurden.
.SH GESCHICHTE
Die
.B socket
Funktion taucht in BSD 4.2 auf.
.SH "SIEHE AUCH"
.BR accept (2),
.BR bind (2),
.BR connect (2),
.BR getprotoent (3),
.BR getsockname (2),
.BR getsockopt (2),
.BR ioctl (2),
.BR listen (2),
.BR read (2),
.BR recv (2),
.BR select (2),
.BR send (2),
.BR shutdown (2),
.BR socketpair (2),
.BR write (2).
"An Introductory 4.3 BSD Interprocess Communication Tutorial"
is reprinted in
.I UNIX Programmer's Supplementary Documents Volume 1
.sp
"BSD Interprocess Communication Tutorial"
is reprinted in
.I UNIX Programmer's Supplementary Documents Volume 1