Provided by: manpages-es_1.55-9_all bug

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 tamao 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 tamao que  "int"
       en  arquitecturas  de  64  bit.  Y _tiene_ que ser del mismo tamao 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 deberan haberlo tocado pero, una vez que lo hicieron,
       pensaron  que  deban  tener  un  tipo  con  nombre  propio  por alguna
       insondable razn (probablemente alguien no quera  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)