.\" Copyright (c) 1983, 1990, 1991 The Regents of the University of California. .\" Todos los derechos reservados. .\" .\" Se permite la redistribución y uso en formatos fuente y binario, con o .\" sin modificación, siempre que se cumplan las siguientes condiciones: .\" 1. Las redistribuciones del código 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 documentación y/o en otros materiales .\" proporcionados junto con la distribución. .\" 3. Todos los materiales publicitarios que mencionen características 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 específico. .\" .\" LOS REGENTES Y COLABORADORES PROPORCIONAN ESTE SOFTWARE "TAL CUAL" Y .\" RECHAZAN CUALQUIER GARANTÍA EXPLÍCITA O IMPLÍCITA, INCLUYENDO, PERO NO .\" LIMITADO A, LAS GARANTÍAS QUE SE SOBREENTIENDAN DEL COMERCIO Y .\" CONVENIENCIA PARA UN PROPÓSITO PARTICULAR. EN NINGÚN CASO LOS .\" REGENTES O COLABORADORES SERÁN RESPONSABLES DE DAÑOS DIRECTOS, .\" INDIRECTOS, INCIDENTALES, ESPECIALES, EJEMPLARES O CONSECUTIVOS .\" (INCLUYENDO, PERO NO LIMITADO A, LA OBTENCIÓN DE BIENES O SERVICIOS .\" SUPLENTES; PERDIDA DE UTILIDAD, DATOS O BENEFICIOS; O INTERRUPCIÓN DE .\" NEGOCIO) CAUSADOS DE CUALQUIER MANERA Y BAJO NINGUNA TEORÍA DE .\" RESPONSABILIDAD, AUN ESCRITA, NI RESPONSABLES DE NINGÚN 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 DAÑO. .\" .\" $Id: accept.2,v 1.2 2005/02/21 16:25:16 pepin.jimenez Exp $ .\" .\" Modified Sat Jul 24 16:42:42 1993 by Rik Faith .\" Modified Mon Oct 21 23:05:29 EDT 1996 by Eric S. Raymond .\" Modified 1998-2000 by Andi Kleen to match Linux 2.2 reality .\" Modified Tue Apr 23 20:33:18 CEST 2002 by Roger Luethi .\" Revisado el Dom 4 de Abr de 1999 por Juan Piernas .\" Revisado el vie 25 de jun de 1999 por Juan Piernas .\" Revisado el sáb 8 de ene del 2000 por Juan Piernas .\" Revisado por Miguel Pérez Ibars el 17-septiembre-2004 .\" .TH ACCEPT 2 "23 Abril 2002" "Página de Linux 2.2" "Manual del programador de Linux" .SH NOMBRE accept \- acepta una conexión sobre un conector (socket). .SH SINOPSIS .B #include .br .B #include .sp .BI "int accept(int " s ", struct sockaddr *" addr ", socklen_t *" addrlen ); .SH DESCRIPCIÓN La función .B accept se usa con conectores orientados a conexión .RB ( SOCK_STREAM , .B SOCK_SEQPACKET y .BR 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 .I s y reserva un nuevo descriptor de fichero para el conector, el cuál es el valor devuelto por la llamada. El conector original .I s no se ve afectado por esta llamada. Dese cuenta que cualquier opción por descriptor de fichero (cualquiera que se pueda establecer con .B F_SETFL de fcntl, como no bloqueante o estado asíncrono) no se hereda en un .I accept. .PP El argumento .I s es un conector que ha sido creado con .BR socket (2), ligado a una dirección 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 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 .I addr viene determinado por la familia del conector (vea .BR socket (2) y las páginas de manual del protocolo correspondiente). El argumento .I addrlen es un parámetro de entrada/salida: al efectuar la llamada debe contener el tamaño de la estructura apuntada por .IR addr ; a la salida, contendrá la longitud real (en bytes) de la dirección 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 conexión. 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 conexión y entonces puede llamar a .B accept para obtener un conector para esa conexión. Alternativamente, puede configurar el conector para que provoque una señal .B SIGIO cuando se produzca actividad en el conector; vea .BR socket (7) para más detalles. .PP Para determinados protocolos que necesitan una confirmación explícita, tales como DECNet, .B 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. .SH OBSERVACIONES Puede que no siempre haya una conexión esperando después de que se produzca una señal .BR SIGIO , o después de que .BR select (2) o .BR 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 .BR accept . Si esto ocurre entonces la llamada se bloqueará esperando a que llegue la siguiente conexión. Para asegurarse de que .B accept nunca se bloquea, es necesario que el conector .I s pasado tenga la opción .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 pendientes sobre el nuevo conector como un código de error de .BR 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 .B accept y tratarlos como .BR EAGAIN reintentado la operación. 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 .B accept fallará si: .TP .BR EAGAIN " o " EWOULDBLOCK El conector está marcado como no-bloqueante y no hay conexiones que aceptar. .TP .B EBADF El descriptor es inválido. .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 EINTR La llamada al sistema fue interrumpida por una señal que fue capturada antes de que llegara una conexión válida. .TP .B ECONNABORTED Una conexión fue abortada. .TP .B EINVAL El conector no está escuchando conexiones. .TP .B EMFILE El límite de descriptores de fichero abiertos por proceso ha sido alcanzado. .TP .B ENFILE El límite máximo del sistema para descriptores de fichero ha sido alcanzado. .PP .B accept puede fallar si: .TP .B EFAULT El parámetro .I addr no se encuentra en una zona accesible para escritura por el usuario. .TP .B 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. .TP .B EPROTO Error de protocolo. .PP La llamada .B accept de Linux puede fallar si: .TP .B EPERM Las reglas del cortafuegos prohíben la conexión. .PP 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 .BR ENOSR , .BR ESOCKTNOSUPPORT , .BR EPROTONOSUPPORT , .BR ETIMEDOUT . El valor .B ERESTARTSYS puede darse durante una ejecución paso a paso. .SH CONFORME A SVr4, 4.4BSD (la función .B 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. .LP La llamada accept de Linux no hereda opciones de conector como .BR 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. .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 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: .\" .I fails: only italicizes a single line \fI_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)\fP. .SH "VÉASE TAMBIÉN" .BR bind (2), .BR connect (2), .BR listen (2), .BR select (2), .BR socket (2)