Provided by: manpages-de-dev_0.10-1_all bug

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