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

NOMBRE

       accept - acepta una conexion sobre un conector (socket).

SINOPSIS

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

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

DESCRIPCI'ON

       La   funcion  accept  se  usa  con  conectores  orientados  a  conexion
       (SOCK_STREAM, SOCK_SEQPACKET y SOCK_RDM).  Extrae la  primera  peticion
       de  conexion  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 cual es el valor
       devuelto por la llamada.  El conector original s no se ve afectado  por
       esta  llamada.  Dese  cuenta  que  cualquier  opcion  por descriptor de
       fichero (cualquiera que se pueda establecer con F_SETFL de fcntl,  como
       no bloqueante o estado asincrono) no se hereda en un accept.

       El  argumento s es un conector que ha sido creado con socket(2), ligado
       a una direccion 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 direccion de la  entidad  con  la  que  se
       conecta,  tal  y  como  la conoce la capa de comunicaciones. El formato
       exacto de la direccion pasada en el parametro  addr  viene  determinado
       por  la familia del conector (vea socket(2) y las paginas de manual del
       protocolo correspondiente).  El argumento addrlen es  un  parametro  de
       entrada/salida:  al  efectuar  la llamada debe contener el tamano de la
       estructura apuntada por addr; a la salida, contendra la  longitud  real
       (en  bytes)  de  la  direccion  devuelta.  Cuando  addr es NULL nada se
       rellena.

       Si no hay conexiones pendientes en  la  cola  y  el  conector  no  esta
       marcado  como  "no bloqueante", accept bloqueara al invocador hasta que
       se  presente  una  conexion.  Si  el  conector  esta  marcado  como  no
       bloqueante  y no hay conexiones pendientes en la cola, accept devolvera
       EAGAIN.

       Para ser informado de las conexiones entrantes que se  produzca  en  un
       conector,  puede  usar  select(2) o poll(2).  Se producira un evento de
       lectura en el intento de una nueva conexion y entonces puede  llamar  a
       accept  para  obtener  un conector para esa conexion. Alternativamente,
       puede configurar el conector para que provoque una senal  SIGIO  cuando
       se produzca actividad en el conector; vea socket(7) para mas detalles.

       Para  determinados protocolos que necesitan una confirmacion explicita,
       tales como DECNet, accept se puede interpretar como  una  funcion  que,
       simplemente,  desencola  la siguiente peticion de conexion sin que ello
       implique la confirmacion.  Se sobreentiende la confirmacion  cuando  se
       produce  una  lectura  o  escritura normal sobre el nuevo descriptor de
       fichero, y el rechazo puede ser de igual manera implicito  cerrando  el
       nuevo conector. Actualmente, solo DECNet tiene esta semantica en Linux.

OBSERVACIONES

       Puede  que  no  siempre  haya  una conexion esperando despues de que se
       produzca una  senal  SIGIO,  o  despues  de  que  select(2)  o  poll(2)
       devuelvan  un  evento de lectura, debido a que la conexion podria haber
       sido eliminada por un error asincrono de red u otro hilo antes  de  que
       se  llame  a  accept.   Si esto ocurre entonces la llamada se bloqueara
       esperando a que llegue la siguiente conexion. Para  asegurarse  de  que
       accept nunca se bloquea, es necesario que el conector s pasado tenga la
       opcion O_NONBLOCK activa (vea socket(7)).

VALOR DEVUELTO

       La llamada devuelve -1 ante un  error.  Si  tiene  exito,  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  codigo  de  error   de   accept.    Este
       comportamiento  difiere de otras construcciones de conectores BSD. Para
       un funcionamiento fiable, la aplicacion debe detectar  los  errores  de
       red  definidos  por  el protocolo tras una llamada a accept y tratarlos
       como EAGAIN reintentado la operacion. En el caso de  TCP/IP  estos  son
       ENETDOWN,   EPROTO,   ENOPROTOOPT,   EHOSTDOWN,  ENONET,  EHOSTUNREACH,
       EOPNOTSUPP y ENETUNREACH.

ERRORES

       accept fallara si:

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

       EBADF  El descriptor es invalido.

       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 senal que fue
              capturada antes de que llegara una conexion valida.

       ECONNABORTED
              Una conexion fue abortada.

       EINVAL El conector no esta escuchando conexiones.

       EMFILE El limite de descriptores de fichero  abiertos  por  proceso  ha
              sido alcanzado.

       ENFILE El  limite  maximo  del  sistema para descriptores de fichero ha
              sido alcanzado.

       accept puede fallar si:

       EFAULT El parametro 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 asignacion de memoria  esta  limitada  por  los
              limites 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 prohiben la conexion.

       Ademas,  se pueden devolver otros errores de red para el nuevo conector
       y que se encuentren definidos en el protocolo.  Diferentes  nucleos  de
       Linux   pueden   devolver   otros   errores   diferentes   como  ENOSR,
       ESOCKTNOSUPPORT,  EPROTONOSUPPORT,  ETIMEDOUT.   El  valor  ERESTARTSYS
       puede darse durante una ejecucion paso a paso.

CONFORME A

       SVr4,  4.4BSD  (la funcion accept aparecio por primera vez en BSD 4.2).
       La pagina 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. Ademas,
       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 declaro originalmente como un `int  *'
       (y  asi  esta en libc4 y libc5 y en otros muchos sistemas como BSD 4.*,
       SunOS 4, SGI); el estandar propuesto POSIX 1003.1g  quiso  cambiarlo  a
       `size_t  *'  y  asi  esta  en SunOS 5.  Mas tarde, los borradores POSIX
       tenian `socklen_t *' y asi lo tomaron the Single Unix  Specification  y
       glibc2.   Citando  a  Linus  Torvalds: _Cualquier_ biblioteca razonable
       _debe_ hacer que "socklen_t" sea del mismo tama~no  que  int.  Cualquier
       otra  cosa  destroza  todo  lo  de  la  capa  de  conectores BSD. POSIX
       inicialmente estableci'o 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~no que "int"
       en arquitecturas de 64 bit. Y _tiene_ que  ser  del  mismo  tama~no  que
       "int"  porque  as'i est'a en la interfaz de conectores BSD.  De cualquier
       modo, los de POSIX finalmente tuvieron una idea y crearon  "socklen_t".
       Para empezar, no deber'ian haberlo tocado pero, una vez que lo hicieron,
       pensaron que  deb'ian  tener  un  tipo  con  nombre  propio  por  alguna
       insondable  raz'on  (probablemente alguien no quer'ia desprestigiarse por
       haber  cometido  la  estupidez  original  por  lo   que,   simplemente,
       renombraron su metedura de pata de forma silenciosa).

V'EASE TAMBI'EN

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

Pagina de Linux 2.2              23 Abril 2002                       ACCEPT(2)