accept(2)

NAVN
accept, accept4 - accepter en forbindelse på en sokkel

BIBLIOTEK
C-standardbibliotek (libc, -lc)

SYNOPSIS
#include <sys/socket.h>

int accept(int sockfd, struct sockaddr *_Nullable restrict addr,
           socklen_t *_Nullable restrict addrlen);

#define _GNU_SOURCE             /* Se feature_test_macros(7) */
#include <sys/socket.h>

int accept4(int sockfd, struct sockaddr *_Nullable restrict addr,
           socklen_t *_Nullable restrict addrlen, int flags);

BESKRIVELSE
Systemkaldet accept() bruges med forbindelsesbaserede sokkeltyper (SOCK_STREAM, SOCK_SEQPACKET). Det udtrækker den første forbindelsesanmodning på køen for afventende forbindelser for den lyttende sokkel, sockfd, opretter en ny forbundet sokkel og returnerer en ny fildeskriptor, der refererer til den sokkel. Den netop oprettede sokkel er ikke i lyttetilstanden. Den oprindelige sokkel sockfd er upåvirket af dette kald.

Argumentet sockfd er en sokkel, der er blevet oprettet med socket(2), bundet til en lokal adresse med bind(2), og lytter efter forbindelser efter en listen(2).

Argumentet addr er en peger til strukturen sockaddr. Denne struktur er udfyldt med adressen af modpartsoklen, som kendt af kommunikationslaget. Det præcise format for adressen returneret addr bestemmes af soklens adressefamilie (se socket(2) og de respektive protokolmanualsider). Når addr er NULL, udfyldes intet; i det tilfælde, bruges addrlen ikke, og skal også være NULL.

Argumentet addrlen er et værdi-resultat argument: kalderen skal igangsætte det for at have størrelsen (i byte) for strukturen pegende mod addr; ved returnering vil det indeholde den faktiske størrelse for modpartsadressen.

Den returnerede adresse er forkortet hvis bufferen tilbudt er for lille; i dette tilfælde vil addrlen returnere en værdi større end den var leveret til kaldet.

Hvis ingen ventende forbindelser er til stede på køen og soklen ikke er markeret som ikkeblokerende, så blokerer accept() kalderen indti len forbindelse er til stede. Hvis soklen er markeret som ikkeblokernede og ingen igangværende forbindleser er til stede på køen, så fejler accept() med fejlen EAGAIN eller EWOULDBLOCK.

For at blive påmindet om indgående forbindelser på en sokkel, så kan du bruge select(2), poll(2) eller epoll(7). En læsbar hændelse vil blive leveret, når en ny forbindelse forsøges og du kan så kalde accept() for at få en sokkel for den forbindelse. Alternativt kan du angive soklen til at levere SIGIO når aktivitet sker på en sokkel; se socket(7) for detaljer.

Hvis flag er nul, så er accept4() det samme som accept(). De følgende værdier være bitwise ORed i flag for at hente forskellig opførelse:

SOCK_NONBLOCK
    Angiv filstatusflaget O_NONBLOCK på den åbne filbeskrivelse (se open(2)) refereret til af den nye fildeskriptor. Brug af dette flag forhindrer ekstra kald til fcntl(2) for at opnå det samme resultat.

SOCK_CLOEXEC
    Angiv flaget close-on-exec (FD_CLOEXEC) på den nye fildeskriptor. Se beskrivelsen af flaget O_CLOEXEC i open(2) for årsagerne til hvorfor dette kan være nyttigt.

RETURVÆRDI
Ved succes returnerer disse systemkald en fildeskriptor for den accepterede sokkel (et ikkenegativ heltal). Ved fejl returneres -1, errno angives for at indikere fejlen og addrlen forbliver uændret.

  Fejlhåndtering
Linux accept() (og accept4()) sender allerede igangværende netværksfejl på den nye sokkel som en fejlkode fra accept(). Denne opførelse er forskellig fra andre BSD-sokkelimplementeringer. For troværdig operation bør programmet registrere netværksfejl defineret for protokollen efter accept() og behandle dem som EAGAIN ved at prøve igen. I tilfælde af TCP/IP, er disse ENETDOWN, EPROTO, ENOPROTOOPT, EHOSTDOWN, ENONET, EHOSTUNREACH, EOPNOTSUPP og ENETUNREACH.

FEJL

EAGAIN eller EWOULDBLOCK
    Soklen er markeret ikkeblokerende og ingen forbindelser er til stede for accept. POSIX.1-2001 og POSIX.1-2008 tillader ikke at fejl returneres i dette tilfælde og kræver ikke at disse konstanter har den samme værdi, så et flytbart program skal tjekke for begge muligheder.

EBADF
    sockfd er ikke en åben fildeskriptor.

ECONNABORTED
    En forbindelse er blevet afbrudt.

EFAULT
    Argumentet addr er ikke en skrivbar del af brugeradresserummet.

EINTR
    Systemkaldet blev afbrudt af et signal, der blev fanget før en gyldig forbindelse ankom; se signal(7).

EINVAL
    Sokket lytter ikke efter forbindelser, eller addrlen er ugyldig (f.eks. er negativ).

EINVAL
    (accept4()) ugyldig værdi i flag.

EMFILE
    Begrænsningen per proces for antallet af åbne fildeskriptorer er blevet nået.

ENFILE
    Systemets begrænsning på det samlede antal åbne filer er nået.

ENOBUFS
ENOMEM
    Ikke nok ledig hukommelse. Dette betyder ofte at hukommelsesallokeringen er begrænset af sokkelbufferbegrænsningerne, ikke af systemhukommelsen.

ENOTSOCK
    Fildeskriptoren sockfd refererer ikke til en sokkel.

EOPNOTSUPP
    Den refererede sokkel er ikke af typen SOCK_STREAM.

EPERM
    Brandmursregler forbyder forbindelse.

EPROTO
    Protokolfejl.

Derudover kan netværksfejl for den nye sokkel og som defineret for protokollen blive returneret. Diverse Linuxkerner kan returnere andre fejl såsom ENOSR, ESOCKTNOSUPPORT, EPROTONOSUPPORT, ETIMEDOUT. Værdien ERESTARTSYS kan ses under en registrering.

VERSIONER
På Linux arver den nye sokkel returneret af accept() ikke filstatusflag såsom O_NONBLOCK og O_ASYNC fra den lyttende sokkel. Denne opførelse er forskellig fra den kanoniske BSD-sokkelimplementering. Flytbare programmer bør altid afhænge af arv eller ikke-arvelighed for filstatusflag og altid eksplicit angive alle krævede flag på soklen returneret fra accept().

STANDARDER
POSIX.1-2024.

HISTORIK

accept()
    POSIX.1-2001, SVr4, 4.4BSD (accept() var første gang i 4.2BSD).

accept4()
    POSIX.1-2024. Linux 2.6.28, glibc 2.10.

NOTER
Der er ikke altid en forbindelse ventende efter en SIGIO er leveret eller select(2), poll(2) eller epoll(7) returnerer en læsbarhedshændelse da forbindelsen kan være fjernet af en asynkron netværksfejl eller en anden tråd før accept() kaldes. Hvis dette sker, så vil kaldet blokere ventende på at den næste forbindelse ankommer. For at sikre at accept() aldrig blokerer, skal den sendte sokkel sockfd have flaget O_NONBLOCK angivet (se socket(7)).

For bestemte protokoller, der kræver en eksplicit bekræftelse, såsom DECnet, kan accept() ses som blot afkørende den næste forbindelsesanmodning og ikke implementere bekræftelse. Bekræftelse kan være underforstået som en normal læs eller skriv på den nye fildeskriptor, og afvigelse kan være underforstået ved at lukke den nye sokkel. I øjeblikket har kun DECnet denne semantik på Linux.

  Socklen_t-typen
I den originale BSD-sokkelimplementering (og på andre ældre systemer) blev det tredje argument for accept() erklæret som en int *. En POSIX.1g-kladdestandard ønskede at ændre det til en size_t *; senere POSIX-standard og glibc 2.x har socklen_t * .

EKSEMPLER
Se bind(2).

SE OGSÅ
bind(2), connect(2), listen(2), select(2), socket(2), socket(7)

OVERSÆTTELSE
Oversættere af denne manual til dansk Joe Dalton <joedalton2@yahoo.dk>

Denne oversættelse er gratis dokumentation; læs GNU General Public License version 3 (https://www.gnu.org/licenses/gpl-3.0.html) eller nyere for ophavsretbetingelser. Der er INGEN ANSVAR.

Hvis du støder på fejl i oversættelsen af ​​denne vejledning, skal du sende en besked til debian-l10n-danish@lists.debian.org.