Provided by:
manpages-de-dev_0.10-1_all 
BEZEICHNUNG
accept - nimmt eine Verbindung auf einem Socket an
"UBERSICHT
#include <sys/types.h> /* Siehe ANMERKUNGEN */
#include <sys/socket.h>
int accept(int sockfd, struct sockaddr *adresse, socklen_t *adresslaenge);
#define _GNU_SOURCE /* Siehe feature_test_macros(7) */
#include <sys/socket.h>
int accept4(int sockfd, struct sockaddr *adresse,
socklen_t *adresslaenge, int schalter);
BESCHREIBUNG
Der Systemaufruf accept() wird mit den verbindungsbasierten Sockettypen
(SOCK_STREAM und SOCK_SEQPACKET) benutzt. Er extrahiert die erste
Verbindungsanfrage in der Warteschlange ausstehender Verbindungen fur
das wartende Socket sockfd, erzeugt eine neues verbundenes Socket und
gibt einen neuen Datei-Deskriptor zuruck, der sich auf dieses Socket
bezieht. Das neu erstellte Socket ist nicht im Wartezustand. Das
Original-Socket sockfd wird von diesem Aufruf nicht beeinflusst.
Das Argument sockfd ist ein Socket, das mit socket(2) erstellt wurde,
mit bind(2) an eine lokale Adresse gebunden ist und nach einem
listen(2) auf Verbindungen wartet.
Das Argument adresse ist ein Zeiger auf eine sockaddr-Struktur. Diese
Struktur enthalt die Adresse des Peer-Sockets, wie sie der
Kommunikationsschicht bekannt ist. Das exakte Format der
zuruckgegebenen Adresse adresse wird durch die Adressfamilie des
Sockets festgelegt (siehe socket(2) und die jeweiligen
Protokoll-Handbuchseiten). Wenn adresse NULL ist, wird nichts
eingrtragen; in diesem Fall wird adresslaenge nicht benutzt und sollte
auch NULL sein.
Das Argument adresslaenge ist ein Wert-Ergebnis-Argument: Der
Aufrufende muss es initialisieren, um die GroBe (in Byte) der Struktur
zu erhalten, auf die adresse zeigt; bei der Ruckkehr wird es die
tatsachliche GroBe der Peer-Adresse enthalten.
Die zuruckgegebene Adresse wird gekurzt, falls der bereitgestellte
Puffer zu klein ist; in diesem Fall wird adresslaenge einen groBeren
Wert zuruckgeben, als der beim Aufruf ubergebene.
Falls keine ausstehenden Verbindungen in der Warteschlange sind und das
Socket nicht als >>nonblocking<< gekennzeichnet ist, blockt accept()
den Aufrufenden bis eine Verbindung besteht. Wenn das Socket als
>>nonblocking<< gekennzeichnet ist und in der Warteschlange keine
ausstehenden Verbindungen enthalt, schlagt accept() mit dem Fehler
EAGAIN oder EWOULDBLOCK fehl.
Zur Information uber neu auf dem Socket eintreffende Verbindungen, kann
select(2) oder poll(2) benutzt werden. Wenn versucht wird, eine neue
Verbindung zu erstellen, wird ein lesbares Ereignis geliefert und sie
konnen accept() aufrufen, um ein Socket fur diese Verbindung zu
erhalten. Alternativ konnen Sie das Socket zum Setzen von SIGIO
veranlassen, wenn es auf dem Socket zu Aktivitat kommt; lesen Sie
socket(7), um Einzelheiten zu erhalten.
Bei bestimmten Protokollen, die eine explizite Bestatigung verlangen,
wie DECNet, kann davon ausgegangen werden, dass accept() nur die
nachste Verbindung aus der Warteschlange holt ohne sie automatisch zu
bestatigen. Die Bestatigung kann ein normaler Lese- oder Schreibvorgang
auf dem neuen Deskriptor mit sich bringen, eine Ablehnung kann durch
ein SchlieBen des neuen Sockets impliziert werden. Derzeit verfugt nur
DECNet auf Linux uber diese Semantik.
Falls schalter 0 ist, dann entspricht accept4() accept(). Die folgenden
Werte konnen in schalter bitweise ODER-verknupft werden, um ein
unterschiedliches Verhalten zu bewirken:
SOCK_NONBLOCK Setzt den Datei-Statusschalter O_NONBLOCK fur den neu
geoffneten Dateideskriptor. Die Benutzung dieses
Schalters speichert zusatzliche Aufrufe nach fcntl(2),
um das gleiche Ergebnis zu erzielen.
SOCK_CLOEXEC Setzt den Schalter SchlieBen-beim-Ausfuhren FD_CLOEXEC
fur den neu geoffneten Datei-Deskriptor. Lesen Sie die
Beschreibung des Schalters O_CLOEXEC in open(2), um die
Grunde zu beleuchten, warum dies nutzlich sein konnte.
R"UCKGABEWERT
Bei Erfolg geben diese Systemaufrufe eine nicht negative Ganzzahl
zuruck, die kein Deskriptor fur das akzeptierte Socket ist. Bei einem
Fehler wird -1 zuruckgegeben und errno entsprechend gesetzt.
Fehlerbehandlung
Die Linux-Version von accept() (und accept4()) reichen alle noch nicht
behandelten Netzwerkfehler an das neue Socket als einen Fehlerkode von
accept() weiter. Dieses Verhalten unterscheidet sich von anderen
Implementierungen des BSD-Sockets. Um zuverlassig operieren zu konnen,
sollte die Anwendung die fur das Protokoll nach accept() definierten
Netzwerkfehler aufspuren und sie wie EAGAIN durch erneutes Probieren
verfolgen. Im Fall von TCP/IP sind dies ENETDOWN, EPROTO, ENOPROTOOPT,
EHOSTDOWN, ENONET, EHOSTUNREACH, EOPNOTSUPP und ENETUNREACH.
FEHLER
EAGAIN oder EWOULDBLOCK
Das Socket ist als >>nonblocking<< gekennzeichnet und es sind
keine Verbindungen vorhanden, die akzeptiert werden mussen.
POSIX.1-2001 erlaubt in diesem Fall auch die Ruckgabe beider
Fehlers und verlangt nicht, dass diese Konstanten den gleichen
Wert haben. Deshalb sollte eine portable Anwendung beide
Moglichkeiten prufen.
EBADF Der Deskriptor ist ungultig.
ECONNABORTED
Eine Verbindung wurde abgebrochen.
EFAULT Das Argument adresse ist kein beschreibbarer Teil des
Adressraums des Benutzers.
EINTR Der Systemaufruf wurde vor dem Eintreffen einer gultigen
Verbindung durch ein Signal unterbrochen; lesen Sie signal(7).
EINVAL Das Socket wartet nicht auf Verbindungen oder adresslaenge ist
ungultig (z.B. negativ).
EINVAL (accept4()) ungultiger Wert in schalter
EMFILE Die Beschrankung offener Datei-Deskriptoren pro Prozess wurde
erreicht.
ENFILE Die Systembeschrankung fur die Summe offener Datei wurde
erreicht.
ENOBUFS, ENOMEM
Nicht genug Speicher. Dies bedeutet oft, dass die
Speicherreservierung durch die Socket-Pufferbeschrankungen
begrenzt ist und nicht durch den Systemspeicher.
ENOTSOCK
Der Deskriptor referenziert eine Datei und kein Socket.
EOPNOTSUPP
Das referenzierte Socket ist nicht vom Typ SOCK_STREAM.
EPROTO Protokollfehler
Zusatzlich konnte Linux-accept() fehlschlagen, falls:
EPERM Firewallregeln die Verbindung verbieten
Zusatzlich konnten Netzwerkfehler fur das neue Socket und wie sie fur
das Protokoll definiert sind, zuruckgegeben werden. Verschiedene
Linux-Kernel konnen andere Fehler zuruckgeben, wie ENOSR,
ESOCKTNOSUPPORT, EPROTONOSUPPORT oder ETIMEDOUT. Der Wert ERESTARTSYS
kann bei einer Ablaufverfolgung auftreten.
VERSIONEN
Der Systemaufruf accept4() ist seit Linux 2.6.28 verfugbar;
Unterstutzung in Glibc ist seit Version 2.10 verfugbar.
KONFORM ZU
accept(): POSIX.1-2001, SVr4, 4.4BSD, (accept() erstmalig erschienen in
4.2BSD).
accept4() ist keine Standard-Linux-Erweiterung.
Auf Linux erbt das neue, von accept() zuruckgegebene Socket nicht die
Datei-Statusschalter wie O_NONBLOCK und O_ASYNC vom wartenden Socket.
Dieses Verhalten unterscheidet sich von der vorschriftsmaBigen
BSD-Socket-Implementierung. Portable Programme sollten sich nicht auf
Vererbung oder Nicht-Vererbung der Datei-Statusschalter verlassen und
immer explizit alle benotigten Schalter des Sockets setzen, das sie von
accept() zuruckbekommen.
ANMERKUNGEN
POSIX.1-2001 erfordert nicht, dass <sys/types.h> eingebunden wird.
Diese Header-Datei ist in Linux nicht erforderlich. Allerdings
benotigen einige historische Implementierungen (BSD) diese
Header-Datei. Es wird empfohlen, sie fur portierbare Anwendungen
einzubinden.
Es konnte sein, dass nicht immer eine Verbindung wartet, nachdem ein
SIGIO zugestellt wurde oder select(2) oder poll(2) ein
Lesbarkeitsereignis zuruckgeben, weil die Verbindung von einem
asynchronen Netwerkfehler oder einem anderen Thread entfernt worden
sein konnte bevor accept() aufgerufen wurde. Falls dies geschieht, wird
der Aufruf das Warten auf die Ankunft der nachsten Verbindung
blockieren. Um sicherzustellen, dass accept() niemals blockiert, muss
beim durchgereichten Socket sockfd der Schalter O_NONBLOCK gesetzt
werden (siehe socket(7)).
Der Typ socklen_t
Das dritte Argument von accept() wurde ursprunglich als ein int *
deklariert (und ist dies unter Libc4, Libc5 und vielen anderen
Systemen, wie 4.x BSD, SunOS 4, SGI); ein Entwurf des
POSIX.1g-Standards wollte es in ein size_t * andern und das ist es in
SunOS 5. Neuere POSIX-Entwurfe benutzen socklen_t * und daher die
>>Single UNIX Specification<< und Glibc2. Zitat Linus Thorvalds:
>>Bei jeder vernunftigen Bibliothek _muss_ >>socklen_t<< die gleiche
GroBe wie >>int<< haben. Alles andere zerstort jedes weitere
BSD-Socket-Ebenen-Zeug. POSIX machte daraus anfangs ein >>size_t<< und
ich (und hoffentlich andere, aber offenbar nicht allzu viele)
reklamierten das durchaus lautstark. Dies zu einem >>size_t<< zu machen
ist genau deshalb nicht in Ordnung, weil >>size_t<< zum Beispiel sehr
selten auf 64-Bit-Architekturen die gleiche GroBe wie >>int<< hat. Und
es muss die gleiche GroBe wie >>int<< haben, weil genau das die
BSD-Socket-Schnittstelle ist. Irgendwie bekamen die POSIX-Leute einen
Hinweis und erstellten >>socklen_t<<. Sie sollten es ursprunglich nicht
anfassen, aber sobald sie es taten, wollten sie aus einem
unerfindlichen Grund einen benannten Typ haben (wahrscheinlich wollte
jemand sein Gesicht wahren wegen der ursprunglichen Dummheit, so dass
sie nur stillschweigend ihren Fehlgriff umbenannten).<<
BEISPIEL
Siehe bind(2).
SIEHE AUCH
bind(2), connect(2), listen(2), select(2), socket(2), socket(7)
KOLOPHON
Diese Seite ist Teil der Veroffentlichung 3.32 des Projekts
Linux-man-pages. Eine Beschreibung des Projekts und Informationen, wie
Fehler gemeldet werden konnen, finden sich unter
http://www.kernel.org/doc/man-pages/.
"UBERSETZUNG
Die deutsche Ubersetzung dieser Handbuchseite wurde von Hanno Wagner
<wagner@bidnix.bid.fh-hannover.de> und Chris Leick <c.leick@vollbio.de>
erstellt.
Diese Ubersetzung ist Freie Dokumentation; lesen Sie die GNU General
Public License Version 3 oder neuer bezuglich der Copyright-
Bedingungen. Es wird KEINE HAFTUNG ubernommen.
Wenn Sie Fehler in der Ubersetzung dieser Handbuchseite finden,
schicken Sie bitte eine E-Mail an <debian-l10n-
german@lists.debian.org>.