NOMBRE

       accept - acepta una conexión sobre un conector (socket).

SINOPSIS

       #include <sys/types.h>
       #include <sys/socket.h>

       int accept(int s, struct sockaddr *addr, socklen_t *addrlen);

DESCRIPCIÓN

       La función accept se usa con conectores orientados a conexión (SOCK_STREAM, SOCK_SEQPACKET
       y SOCK_RDM).  Extrae la primera petición de conexión de la cola de conexiones  pendientes,
       le  asocia  un nuevo conector con, practicamente, las misma propiedades que s y reserva un
       nuevo descriptor de fichero para el conector, el cuál es el valor devuelto por la llamada.
       El  conector  original  s  no  se  ve afectado por esta llamada. Dese cuenta que cualquier
       opción por descriptor de fichero (cualquiera que se pueda establecer con F_SETFL de fcntl,
       como no bloqueante o estado asíncrono) no se hereda en un accept.

       El  argumento  s  es  un conector que ha sido creado con socket(2), ligado a una dirección
       local con bind(2) y que se encuentra a la escucha tras un listen(2).

       El argumento addr es un puntero a una estructura sockaddr. Esta estructura se rellena  con
       la  dirección  de  la  entidad  con  la  que  se  conecta, tal y como la conoce la capa de
       comunicaciones. El formato exacto de la  dirección  pasada  en  el  parámetro  addr  viene
       determinado  por  la  familia  del  conector  (vea  socket(2)  y las páginas de manual del
       protocolo correspondiente).  El argumento addrlen es un parámetro  de  entrada/salida:  al
       efectuar  la  llamada  debe  contener  el  tamaño de la estructura apuntada por addr; a la
       salida, contendrá la longitud real (en bytes) de la dirección  devuelta.  Cuando  addr  es
       NULL nada se rellena.

       Si  no  hay  conexiones  pendientes  en  la  cola  y  el conector no está marcado como "no
       bloqueante", accept bloqueará al invocador hasta que  se  presente  una  conexión.  Si  el
       conector está marcado como no bloqueante y no hay conexiones pendientes en la cola, accept
       devolverá EAGAIN.

       Para ser informado de las conexiones entrantes que se produzca en un conector, puede  usar
       select(2)  o  poll(2).   Se  producirá  un  evento  de  lectura en el intento de una nueva
       conexión y entonces puede llamar a accept para obtener  un  conector  para  esa  conexión.
       Alternativamente, puede configurar el conector para que provoque una señal SIGIO cuando se
       produzca actividad en el conector; vea socket(7) para más detalles.

       Para determinados protocolos que necesitan una confirmación explícita, tales como  DECNet,
       accept  se  puede  interpretar  como  una función que, simplemente, desencola la siguiente
       petición de  conexión  sin  que  ello  implique  la  confirmación.   Se  sobreentiende  la
       confirmación cuando se produce una lectura o escritura normal sobre el nuevo descriptor de
       fichero, y el rechazo puede ser de igual manera  implícito  cerrando  el  nuevo  conector.
       Actualmente, sólo DECNet tiene esta semántica en Linux.

OBSERVACIONES

       Puede  que  no  siempre  haya  una conexión esperando después de que se produzca una señal
       SIGIO, o después de que select(2) o poll(2) devuelvan un evento de lectura, debido  a  que
       la conexión podría haber sido eliminada por un error asíncrono de red u otro hilo antes de
       que se llame a accept.  Si esto ocurre entonces la llamada se bloqueará  esperando  a  que
       llegue la siguiente conexión. Para asegurarse de que accept nunca se bloquea, es necesario
       que el conector s pasado tenga la opción O_NONBLOCK activa (vea socket(7)).

VALOR DEVUELTO

       La llamada devuelve -1 ante un error. Si tiene éxito, devuelve un entero no  negativo  que
       es el descriptor del conector aceptado.

MANEJO DE ERRORES

       La  llamada  accept de Linux pasa los errores de red ya pendientes sobre el nuevo conector
       como un código de error de accept.  Este comportamiento difiere de otras construcciones de
       conectores  BSD. Para un funcionamiento fiable, la aplicación debe detectar los errores de
       red definidos por el  protocolo  tras  una  llamada  a  accept  y  tratarlos  como  EAGAIN
       reintentado  la  operación.  En el caso de TCP/IP estos son ENETDOWN, EPROTO, ENOPROTOOPT,
       EHOSTDOWN, ENONET, EHOSTUNREACH, EOPNOTSUPP y ENETUNREACH.

ERRORES

       accept fallará si:

       EAGAIN o EWOULDBLOCK
              El conector está marcado como no-bloqueante y no hay conexiones que aceptar.

       EBADF  El descriptor es inválido.

       ENOTSOCK
              El descriptor referencia a un fichero, no a un conector.

       EOPNOTSUPP
              El conector referenciado no es del tipo SOCK_STREAM.

       EINTR  La llamada al sistema fue interrumpida por una señal que fue capturada antes de que
              llegara una conexión válida.

       ECONNABORTED
              Una conexión fue abortada.

       EINVAL El conector no está escuchando conexiones.

       EMFILE El límite de descriptores de fichero abiertos por proceso ha sido alcanzado.

       ENFILE El límite máximo del sistema para descriptores de fichero ha sido alcanzado.

       accept puede fallar si:

       EFAULT El  parámetro  addr  no  se  encuentra  en una zona accesible para escritura por el
              usuario.

       ENOBUFS, ENOMEM
              No hay suficiente memoria disponible.  Esto normalmente significa que la asignación
              de  memoria  está  limitada  por  los  límites  del buffer de conectores, no por la
              memoria del sistema.

       EPROTO Error de protocolo.

       La llamada accept de Linux puede fallar si:

       EPERM  Las reglas del cortafuegos prohíben la conexión.

       Además, se pueden devolver otros errores de red para el nuevo conector y que se encuentren
       definidos  en  el  protocolo.  Diferentes  núcleos  de Linux pueden devolver otros errores
       diferentes como ENOSR, ESOCKTNOSUPPORT, EPROTONOSUPPORT, ETIMEDOUT.  El valor  ERESTARTSYS
       puede darse durante una ejecución paso a paso.

CONFORME A

       SVr4, 4.4BSD (la función accept apareció por primera vez en BSD 4.2).  La página de manual
       de BSD  documenta  cinco  posibles  respuestas  de  error  (EBADF,  ENOTSOCK,  EOPNOTSUPP,
       EWOULDBLOCK,  EFAULT).   SUSv3  documenta  los errores EAGAIN, EBADF, ECONNABORTED, EINTR,
       EINVAL, EMFILE,  ENFILE,  ENOBUFS,  ENOMEM,  ENOTSOCK,  EOPNOTSUPP,  EPROTO,  EWOULDBLOCK.
       Además, SUSv2 documenta EFAULT y ENOSR.

       La  llamada  accept  de  Linux  no  hereda  opciones  de  conector  como O_NONBLOCK.  Este
       comportamiento difiere de otras construcciones de conectores BSD.  Los programas portables
       no deben confiar en este comportamiento y establecer siempre todas las opciones requeridas
       en el conector devuelto por accept.

NOTA

       El tercer argumento de accept se declaró originalmente como un `int  *'  (y  así  está  en
       libc4  y  libc5  y  en  otros  muchos  sistemas  como  BSD 4.*, SunOS 4, SGI); el estándar
       propuesto POSIX 1003.1g quiso cambiarlo a `size_t *' y así está en SunOS  5.   Más  tarde,
       los borradores POSIX tenían `socklen_t *' y así lo tomaron the Single Unix Specification y
       glibc2.  Citando a Linus Torvalds:  _Cualquier_  biblioteca  razonable  _debe_  hacer  que
       "socklen_t"  sea del mismo tamaño que int. Cualquier otra cosa destroza todo lo de la capa
       de conectores BSD. POSIX inicialmente estableció el tipo a size_t y, de hecho, yo (y es de
       suponer que otros aunque, obviamente, no demasiados) nos quejamos a gritos. El ser de tipo
       size_t es completamente desastroso, precisamente porque, por ejemplo, size_t muy rara  vez
       es  del  mismo  tamaño  que  "int" en arquitecturas de 64 bit. Y _tiene_ que ser del mismo
       tamaño que "int" porque así está en la interfaz de conectores BSD.  De cualquier modo, los
       de  POSIX  finalmente  tuvieron  una idea y crearon "socklen_t". Para empezar, no deberían
       haberlo tocado pero, una vez que lo hicieron, pensaron que debían tener un tipo con nombre
       propio  por  alguna  insondable razón (probablemente alguien no quería desprestigiarse por
       haber cometido la estupidez original por lo que, simplemente, renombraron su  metedura  de
       pata de forma silenciosa).

VÉASE TAMBIÉN

       bind(2), connect(2), listen(2), select(2), socket(2)