'\" t .\" Copyright (c) 1983, 1991 The Regents of the University of California. .\" All rights reserved. .\" .\" Redistribution and use in source and binary forms, with or without .\" modification, are permitted provided that the following conditions .\" are met: .\" 1. Redistributions of source code must retain the above copyright .\" notice, this list of conditions and the following disclaimer. .\" 2. Redistributions in binary form must reproduce the above copyright .\" notice, this list of conditions and the following disclaimer in the .\" documentation and/or other materials provided with the distribution. .\" 3. All advertising materials mentioning features or use of this software .\" must display the following acknowledgement: .\" This product includes software developed by the University of .\" California, Berkeley and its contributors. .\" 4. Neither the name of the University nor the names of its contributors .\" may be used to endorse or promote products derived from this software .\" without specific prior written permission. .\" .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE .\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF .\" SUCH DAMAGE. .\" .\" $Id: socket.2,v 1.4 2005/05/30 07:34:00 juan.piernas Exp $ .\" .\" Modified Sat Jul 24 10:36:46 1993 by Rik Faith .\" Modified Tue Oct 22 22:10:43 1996 by Eric S. Raymond .\" Modified 1998,1999 by Andi Kleen .\" Modified, 17 Jul 02 by Michael Kerrisk .\" Translated into Spanish Tue Feb 17 15:37:13 CET 1998 by .\" Gerardo Aburruzaga García .\" Translation revised Tue Apr 6 1999 by Juan Piernas .\" Translation revised Sun Jun 27 1999 by Juan Piernas .\" Translation revised Sun Apr 16 2000 by Juan Piernas .\" Revisado por Miguel Pérez Ibars el 1-diciembre-2004 .\" .TH SOCKET 2 "24 abril 1999" "Página man de Linux" "Manual del Programador de Linux" .SH NOMBRE socket \- crea un extremo de una comunicación .SH SINOPSIS .B #include .br .B #include .sp .BI "int socket(int " dominio ", int " tipo ", int " protocolo ); .SH DESCRIPCIÓN .B Socket crea un extremo de una comunicación y devuelve un descriptor. .PP El parámetro .I dominio especifica un dominio de comunicaciones. Esto selecciona la familia de protocol que se usará para la comunicación. Estas familias se definen en .BR . Los formatos actualmente reconocidos incluyen: .PP .TS tab(:); l l l. Nombre:Propósito:Página de manual T{ .B "PF_UNIX,PF_LOCAL" T}:T{ Comunicación local T}:T{ .BR unix (7) T} T{ .B PF_INET T}:Protocolos de Internet IPv4:T{ .BR ip (7) T} T{ .B PF_INET6 T}:Protocolos de Internet IPv6:T{ T} T{ .B PF_IPX T}:Protocolos IPX \- Novell:T{ T} T{ .B PF_NETLINK T}:T{ Dispositivo de la intefaz de usuario del núcleo T}:T{ .BR netlink (7) T} T{ .B PF_X25 T}:Protocolo ITU-T X.25 / ISO-8208:T{ .BR x25 (7) T} T{ .B PF_AX25 T}:T{ Protocolo AX.25 de radio para aficionados T}: T{ .B PF_ATMPVC T}:Acceso directo a PVCs ATM: T{ .B PF_APPLETALK T}:Appletalk:T{ .BR ddp (7) T} T{ .B PF_PACKET T}:T{ Interfaz de paquetes de bajo nivel T}:T{ .BR packet (7) T} .TE .PP El conector tiene el .I tipo indicado, que especifica la semántica de la comunicación. Los tipos definidos en la actualidad son: .TP .B SOCK_STREAM Proporciona flujos de bytes basados en una conexión bidireccional secuenciada, confiable. Se puede admitir un mecanismo de transmisión de datos fuera-de-banda. .TP .B SOCK_DGRAM Admite datagramas (mensajes no confiables, sin conexión, de una longitud máxima fija). .TP .B SOCK_SEQPACKET Proporciona un camino de transmisión de datos basado en conexión bidireccional secuenciado, confiable, para datagramas de longitud máxima fija; se requiere un consumidor para leer un paquete entero con cada llamada al sistema de lectura. .TP .B SOCK_RAW Proporciona acceso directo a los protocolos de red. .TP .B SOCK_RDM Proporciona una capa de datagramas fiables que no garantiza el orden. .TP .B SOCK_PACKET Obsoleto y no debería utilizarse en programas nuevos. Vea .BR packet (7). .PP Algunos tipos de conectores pueden no ser implementados por todas las familias de protocolos. Por ejemplo, .B SOCK_SEQPACKET no está implementado para .BR AF_INET . .PP El .I protocolo especifica un protocolo particular para ser usado con el conector. Normalmente sólo existe un protocolo que admita un tipo particular de conector dentro de una familia de protocolos dada, en cuyo caso .I protocolo se puede especificar como 0. Sin embargo, es posible que puedan existir varios protocolos, en cuyo caso un protocolo particular puede especificarse de esta manera. El número de protocolo a emplear es específico al \*(lqdominio de comunicación\*(rq en el que la comunicación va a tener lugar; vea .BR protocols (5). Consulte .BR getprotoent (3) para ver cómo asociar una cadenas con el nombre de un protocolo a un número de protocolo. .PP Los conectores del tipo .B SOCK_STREAM son flujos de bytes bidireccionales, similares a tuberías, que no conservan los límites de registro. Un conector de flujo debe estar en un estado .I conectado antes de que cualquier dato pueda ser enviado o recibido en él. Se crea una conexión con otro conector mediante la llamada .BR connect (2). Una vez hecha la conexión, los datos pueden transferirse utilizando llamadas .BR read (2) y .BR write (2) o alguna variante de las llamadas .BR send (2) y .BR recv (2). Cuando una sesión se ha completado, se puede efectuar un .BR close (2). Los datos fuera-de-banda pueden transmitirse también como se describe en .BR send (2) y recibirse según se describe en .BR recv (2). .PP Los protocolos de comunicaciones que implementan un .B SOCK_STREAM aseguran que los datos no se pierden ni se duplican. Si un trozo de dato para el cual el protocolo de la pareja tiene espacio de búfer no puede ser transmitido satisfactoriamente en un período razonable de tiempo, entonces la conexión se considera muerta. Cuando se activa .B SO_KEEPALIVE en el conector el protocolo comprueba de una manera específica del protocolo si el otro extremo todavía está vivo. Se lanza una señal .B SIGPIPE si un proceso envía o recibe en un flujo roto; esto provoca que procesos simples, que no manejan la señal, acaben. Los conectores .B SOCK_SEQPACKET emplean las mismas llamadas al sistema que los .BR SOCK_STREAM . La única diferencia es que las llamadas a .BR read (2) devolverán solamente la cantidad de datos pedidos, y los que queden en el paquete que llega se perderán. También se conservarán todos los límites de mensaje en los datagramas que lleguen. .PP Los conectores .B SOCK_DGRAM y .B SOCK_RAW permiten el envío de datagramas a los correspondientes nombrados en llamadas a .BR send (2). Los datagramas se reciben generalmente con .BR recvfrom (2), que devuelve el siguiente datagrama con su dirección de retorno. .PP .B SOCK_PACKET es un tipo de conector obsoleto para recibir paquetes crudos directamente desde el manejador de dispositivo. Use .BR packet (7) en su lugar. .PP Una llamada a .BR fcntl (2) con el argumento .B F_SETOWN puede utilizarse para especificar que un grupo de proceso reciba una señal .B SIGURG cuando lleguen los datos fuera-de-banda o la señal .B SIGPIPE cuando una conexión .B SOCK_STREAM se rompa inesperadamente. También puede usarse para configurar el proceso o grupo de procesos que recibirán la E/S y la notificación asíncrona de los eventos de E/S a través de .BR SIGIO . Usar .B F_SETOWN es equivalente a una llamada a .BR ioctl (2) con el argumento .B FIOSETOWN o .B SIOCSPGRP. .PP Cuando la red señala una condición de error al módulo del protocolo (por ejemplo, usando un mensaje ICMP para IP) se activa la bandera de error pendiente para el conector. La siguiente operación sobre ese conector devolverá el código de error del error pendiente. Para algunos protocolos es posible habilitar una cola de error por conector para obtener información detallada del error. Vea .B IP_RECVERR en .BR ip (7) . .PP La operación de los conectores se controla por .I opciones en el nivel de los conectores. Estas opciones se definen en .IR . Las funciones .BR setsockopt (2) y .BR getsockopt (2) se emplean para establecer y obtener opciones, respectivamente. .SH "VALOR DEVUELTO" Se devuelve un \-1 si ocurre un error; en otro caso el valor devuelto es un descriptor para referenciar el conector. .SH ERRORES .TP .B EPROTONOSUPPORT El tipo de protocolo, o el protocolo especificado, no es reconocido dentro de este dominio. .TP .B EAFNOSUPPORT La implementación no soporta la familia de direcciones especificada. .TP .B ENFILE No hay suficiente memoria en el núcleo para reservar una nueva estructura de conector. .TP .B EMFILE Se ha desbordado la tabla de ficheros del proceso. .TP .B EACCES Se deniega el permiso para crear un conector del tipo o protocolo especificado. .TP .B ENOBUFS " o " ENOMEM No hay suficiente memoria disponible. El conector no puede crearse hasta que no queden libres los recursos suficientes. .TP .B EINVAL Protocolo desconocido o familia de protocolo no disponible. .PP Los módulos de los protocolos subyacentes pueden generar otros errores. .SH "CONFORME A" 4.4BSD (la llamada a función .B socket apareció en 4.2BSD). Generalmente transportable a o desde sistemas no BSD que admitan clones de la capa de conectores de BSD (incluyendo variantes System V). .SH NOTA Las constantes evidentes usadas en BSD 4.* para las familias de protocolos son PF_UNIX, PF_INET, etc., mientras que AF_UNIX, etc. se usan para las familias de direcciones. Sin embargo, ya la página de manual BSD promete: "La familia de protocolos generalmente es la misma que la familia de direcciones" y los estándares subsiguientes usan AF_* en todas partes. .SH FALLOS .B SOCK_UUCP todavía no está implementado. .SH "VÉASE TAMBIÉN" .BR accept (2), .BR bind (2), .BR connect (2), .BR fcntl (2), .BR getpeername (2), .BR getsockname (2), .BR getsockopt (2), .BR ioctl (2), .BR listen (2), .BR read (2), .BR recv (2), .BR select (2), .BR send (2), .BR shutdown (2), .BR socketpair (2), .BR write (2), .BR getprotoent (3), .BR ip (7), .BR socket (7), .BR tcp (7), .BR udp (7), .BR unix (7) .PP \(lqAn Introductory 4.3 BSD Interprocess Communication Tutorial\(rq está reimpreso en .I UNIX Programmer's Supplementary Documents Volume 1. .PP \(lqBSD Interprocess Communication Tutorial\(rq está reimpreso en .I UNIX Programmer's Supplementary Documents Volume 1.