.\" Copyright (c) 1983, 1990, 1991 The Regents of the University of California.
.\" Todos los derechos reservados.
.\"
.\" Se permite la redistribucin y uso en formatos fuente y binario, con o
.\" sin modificacin, siempre que se cumplan las siguientes condiciones:
.\" 1. Las redistribuciones del cdigo fuente deben conservar el aviso
.\"    anterior de copyright, esta lista de condiciones y el siguiente
.\"    rechazo de responsabilidad.
.\" 2. Las redistribuciones en formato binario deben reproducir el aviso de
.\"    copyright anterior, esta lista de condiciones y el siguiente rechazo
.\"    de responsabilidad en la documentacin y/o en otros materiales
.\"    proporcionados junto con la distribucin.
.\" 3. Todos los materiales publicitarios que mencionen caractersticas o
.\"    uso de este software deben mostrar el siguiente reconocimiento:
.\"       Este producto incluye software desarrollado por la Universidad de
.\"       California, Berkeley y sus colaboradores.
.\" 4. No se deben usar ni el nombre de la Universidad ni los nombres de sus
.\"    colaboradores para endosar o promover productos derivados de este software sin
.\"    previo permiso escrito especfico.
.\"
.\" LOS REGENTES Y COLABORADORES PROPORCIONAN ESTE SOFTWARE "TAL CUAL" Y
.\" RECHAZAN CUALQUIER GARANTA EXPLCITA O IMPLCITA, INCLUYENDO, PERO NO
.\" LIMITADO A, LAS GARANTAS QUE SE SOBREENTIENDAN DEL COMERCIO Y
.\" CONVENIENCIA PARA UN PROPSITO PARTICULAR. EN NINGN CASO LOS
.\" REGENTES O COLABORADORES SERN RESPONSABLES DE DAOS DIRECTOS,
.\" INDIRECTOS, INCIDENTALES, ESPECIALES, EJEMPLARES O CONSECUTIVOS
.\" (INCLUYENDO, PERO NO LIMITADO A, LA OBTENCIN DE BIENES O SERVICIOS
.\" SUPLENTES; PERDIDA DE UTILIDAD, DATOS O BENEFICIOS; O INTERRUPCIN DE
.\" NEGOCIO) CAUSADOS DE CUALQUIER MANERA Y BAJO NINGUNA TEORA DE
.\" RESPONSABILIDAD, AUN ESCRITA, NI RESPONSABLES DE NINGN DELITO
.\" (INCLUYENDO NEGLIGENCIA O CUALQUIER OTRO CASO) QUE SURJA DE CUALQUIER
.\" FORMA FUERA DEL USO DE ESTE SOFTWARE, INCLUSO AUNQUE SE HAYA ADVERTIDO
.\" DE LA POSIBILIDAD DE TAL DAO.
.\"
.\"     $Id: accept.2,v 1.7 1999/05/24 11:53:23 freitag Exp $
.\"
.\" Modificado el Sb 24 de Jul de 1993 a las 16:42:42 por Rik Faith (faith@cs.unc.edu)
.\" Modificado el Lun 21 de Oct de 1996 a las 23:05:29 por Eric S. Raymond <esr@thyrsus.com>
.\" Traducido el Dom 20 de Jul de 1997 por Juan Piernas (piernas@dif.um.es)
.\" Revisado el Vie 2 de Oct de 1998 por Juan Piernas <piernas@ditec.um.es>
.\" Modificado en 1998, 1999 por Andi Kleen para adaptar la pgina a la
.\" realidad de la versin 2.2 de Linux
.\" Revisado el Dom 4 de Abr de 1999 por Juan Piernas <piernas@ditec.um.es>
.\" Revisado el vie 25 de jun de 1999 por Juan Piernas <piernas@ditec.um.es>
.\"
.TH ACCEPT 2 "7 Mayo 1999" "Pgina de Linux 2.2" "Manual del programador de Linux"
.SH NOMBRE
accept \- acepta una conexin sobre un conector (socket).
.SH SINOPSIS
.B #include <sys/types.h>
.br
.B #include <sys/socket.h>
.sp
.BI "int accept(int " s ", struct sockaddr *" addr ", socklen_t *" addrlen );
.SH DESCRIPCIN

La funcin
.B accept
se usa con conectores orientados a conexin
.RB ( SOCK_STREAM ,
.B SOCK_SEQPACKET
y
.BR SOCK_RDM ).
Extrae la primera peticin de conexin de la cola de conexiones pendientes,
le asocia un nuevo conector con las misma propiedades que
.I s
y reserva un nuevo descriptor de fichero para el conector, el cul es el
valor devuelto por la llamada.
El conector original
.I s
no se ve afectado por esta llamada.
.PP
El argumento
.I s
es un conector que ha sido creado con
.BR socket (2),
ligado a una direccin local con
.BR bind (2)
y que se encuentra a la escucha tras un
.BR listen (2).

El argumento
.I addr
es un puntero a una estructura sockaddr. Esta estructura se rellena con la
direccin de la entidad con la que se conecta, tal y como la conoce la capa
de comunicaciones. El formato exacto de la direccin pasada en el parmetro
.I addr
viene determinado por la familia del conector (vea
.BR socket (2)
y las pginas de manual del protocolo correspondiente).
El argumento
.I addrlen
es un parmetro de entrada/salida: al efectuar la llamada debe contener
el tamao de la estructura apuntada por
.IR addr ;
a la salida, contendr la longitud real (en bytes) de la direccin
devuelta. Cuando
.I addr
es NULL nada se rellena.
.PP
Si no hay conexiones pendientes en la cola y el conector no est marcado como
"no bloqueante",
.B accept
bloquear al invocador hasta que se presente una conexin. Si el conector est
marcado como no bloqueante y no hay conexiones pendientes en la cola, 
.B accept
devolver EAGAIN.
.PP
Para ser informado de las conexiones entrantes que se produzca en un conector,
puede usar
.BR select (2)
o
.BR poll (2).
Se producir un evento de lectura en el intento de una nueva conexin y
entonces puede llamar a
.B accept
para obtener un conector para esa conexin. Alternativamente, puede
configurar el conector para que provoque una seal
.B SIGIO
cuando se produzca actividad en el conector; vea
.BR socket (7)
para ms detalles.
.PP
Para determinados protocolos que necesitan una confirmacin explcita, tales
como DECNet,
.B accept
se puede interpretar como una funcin que, simplemente, desencola la
siguiente peticin de conexin sin que ello implique la confirmacin.
Se sobreentiende la confirmacin cuando se produce una lectura o escritura
normal sobre el nuevo descriptor de fichero, y el rechazo puede ser de igual
manera implcito cerrando el nuevo conector. Actualmente, slo DECNet tiene
esta semntica en Linux.
.SH NOTAS
Puede que no siempre haya una conexin esperando despus de que se produzca
una seal
.BR SIGIO ,
o despus de que
.BR select (2)
o
.BR poll (2)
devuelvan un evento de lectura, debido a que la conexin podra haber sido
eliminada por un error asncrono de red u otro hilo antes de que se llame a
.BR accept .
Si esto ocurre entonces la llamada se bloquear esperando a que llegue la
siguiente conexin. Para asegurarse de que
.B accept
nunca se bloquea, es necesario que el conector
.I s
pasado tenga la opcin
.B O_NONBLOCK
activa (vea
.BR socket (7)).
.SH "VALOR DEVUELTO"
La llamada devuelve \-1 ante un error. Si tiene xito, devuelve un entero no
negativo que es el descriptor del conector aceptado.
.SH MANEJO DE ERRORES
La llamada
.B accept
de Linux pasa los errores de red ya pendienes sobre el nuevo conector como
un cdigo de error de
.BR accept .
Este comportamiento difiere de otras construcciones de conectores BSD. Para
un funcionamiento fiable, la aplicacin debe detectar los errores de red
definidos por el protocolo tras una llamada a
.B accept
y tratarlos como
.BR EAGAIN
reintentado la operacin. En el caso de TCP/IP estos son
.BR ENETDOWN ,
.BR EPROTO ,
.BR ENOPROTOOPT ,
.BR EHOSTDOWN ,
.BR ENONET ,
.BR EHOSTUNREACH ,
.BR EOPNOTSUPP
y
.BR ENETUNREACH .
.SH ERRORES
.TP
.BR EAGAIN " o " EWOULDBLOCK
El conector est marcado como no-bloqueante y no hay conexiones que
aceptar.
.TP
.B EBADF
El descriptor es invlido.
.TP
.B ENOTSOCK
El descriptor referencia a un fichero, no a un conector.
.TP
.B EOPNOTSUPP
El conector referenciado no es del tipo
.BR SOCK_STREAM . 
.TP
.B EFAULT
El parmetro
.I addr
no se encuentra en una zona accesible para escritura por el usuario.
.TP
.B EPERM
Las reglas del cortafuegos prohiben la conexin.
.TP
.B ENOBUFS, ENOMEM
No hay suficiente memoria disponible.
.PP
Adems, se pueden devolver otros errores de red para el nuevo conector y que
se encuentren definidos en el protocolo. Diferentes ncleos de Linux pueden
devolver otros errores diferentes como
.BR EMFILE ,
.BR EINVAL ,
.BR ENOSR ,
.BR ENOBUFS ,
.BR EPERM ,
.BR ECONNABORTED ,
.BR ESOCKTNOSUPPORT ,
.BR EPROTONOSUPPORT ,
.BR ETIMEDOUT ,
.BR ERESTARTSYS .
.SH CONFORME A
SVr4, 4.4BSD (la funcin
.B accept
apareci por primera vez en BSD 4.2).
La pgina de manual de BSD documenta cinco posibles respuestas de error
(EBADF, ENOTSOCK, EOPNOTSUPP, EWOULDBLOCK, EFAULT).
SUSv2 documenta los errores EAGAIN, EBADF, ECONNABORTED, EFAULT, EINTR,
EINVAL, EMFILE, ENFILE, ENOBUFS, ENOMEM, ENOSR, ENOTSOCK, EOPNOTSUPP,
EPROTO, EWOULDBLOCK.
.SH NOTA
El tercer argumento de 
.B 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 estndar propuesto
POSIX 1003.1g quiso cambiarlo a `size_t *' y as est en SunOS 5.
Ms tarde, los borradores POSIX tenan `socklen_t *' y as lo tomaron
the Single Unix Specification y glibc2.
Citando a Linus Torvalds:
.I
_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).
.SH "VASE TAMBIN"
.BR bind (2),
.BR connect (2),
.BR listen (2),
.BR select (2),
.BR socket (2)