Provided by:
manpages-es_1.55-10_all 
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)