NOMBRE¶
socket - crea un extremo de una comunicación
SINOPSIS¶
#include <sys/types.h>
#include <sys/socket.h>
int socket(int dominio, int tipo, int
protocolo);
DESCRIPCIÓN¶
Socket crea un extremo de una comunicación y devuelve un
descriptor.
El parámetro
dominio especifica un dominio de comunicaciones. Esto
selecciona la familia de protocol que se usará para la
comunicación. Estas familias se definen en
<sys/socket.h>.
Los formatos actualmente reconocidos incluyen:
Nombre |
Propósito |
Página de manual |
"PF_UNIX,PF_LOCAL" |
Comunicación local |
unix (7) |
PF_INET |
Protocolos de Internet IPv4 |
ip (7) |
PF_INET6 |
Protocolos de Internet IPv6 |
|
PF_IPX |
Protocolos IPX - Novell |
|
PF_NETLINK |
Dispositivo de la intefaz de usuario del núcleo |
netlink (7) |
PF_X25 |
Protocolo ITU-T X.25 / ISO-8208 |
x25 (7) |
PF_AX25 |
Protocolo AX.25 de radio para aficionados |
|
PF_ATMPVC |
Acceso directo a PVCs ATM |
|
PF_APPLETALK |
Appletalk |
ddp (7) |
PF_PACKET |
Interfaz de paquetes de bajo nivel |
packet (7) |
El conector tiene el
tipo indicado, que especifica la semántica de
la comunicación. Los tipos definidos en la actualidad son:
- 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.
- SOCK_DGRAM
- Admite datagramas (mensajes no confiables, sin conexión, de una
longitud máxima fija).
- 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.
- SOCK_RAW
- Proporciona acceso directo a los protocolos de red.
- SOCK_RDM
- Proporciona una capa de datagramas fiables que no garantiza el orden.
- SOCK_PACKET
- Obsoleto y no debería utilizarse en programas nuevos. Vea
packet(7).
Algunos tipos de conectores pueden no ser implementados por todas las familias
de protocolos. Por ejemplo,
SOCK_SEQPACKET no está implementado
para
AF_INET.
El
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
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 “dominio de comunicación” en el que
la comunicación va a tener lugar; vea
protocols(5). Consulte
getprotoent(3) para ver cómo asociar una cadenas con el nombre
de un protocolo a un número de protocolo.
Los conectores del tipo
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
conectado antes de que
cualquier dato pueda ser enviado o recibido en él. Se crea una
conexión con otro conector mediante la llamada
connect(2). Una
vez hecha la conexión, los datos pueden transferirse utilizando
llamadas
read(2) y
write(2) o alguna variante de las llamadas
send(2) y
recv(2). Cuando una sesión se ha completado, se
puede efectuar un
close(2). Los datos fuera-de-banda pueden
transmitirse también como se describe en
send(2) y recibirse
según se describe en
recv(2).
Los protocolos de comunicaciones que implementan un
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
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
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
SOCK_SEQPACKET emplean las mismas
llamadas al sistema que los
SOCK_STREAM. La única diferencia es
que las llamadas a
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.
Los conectores
SOCK_DGRAM y
SOCK_RAW permiten el envío de
datagramas a los correspondientes nombrados en llamadas a
send(2). Los
datagramas se reciben generalmente con
recvfrom(2), que devuelve el
siguiente datagrama con su dirección de retorno.
SOCK_PACKET es un tipo de conector obsoleto para recibir paquetes crudos
directamente desde el manejador de dispositivo. Use
packet(7) en su
lugar.
Una llamada a
fcntl(2) con el argumento
F_SETOWN puede utilizarse
para especificar que un grupo de proceso reciba una señal
SIGURG
cuando lleguen los datos fuera-de-banda o la señal
SIGPIPE
cuando una conexión
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
SIGIO. Usar
F_SETOWN es
equivalente a una llamada a
ioctl(2) con el argumento
FIOSETOWN
o
SIOCSPGRP.
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
IP_RECVERR en
ip(7).
La operación de los conectores se controla por
opciones en el
nivel de los conectores. Estas opciones se definen en
<sys/socket.h>. Las funciones
setsockopt(2) y
getsockopt(2) se emplean para establecer y obtener opciones,
respectivamente.
VALOR DEVUELTO¶
Se devuelve un -1 si ocurre un error; en otro caso el valor devuelto es un
descriptor para referenciar el conector.
ERRORES¶
- EPROTONOSUPPORT
- El tipo de protocolo, o el protocolo especificado, no es reconocido dentro
de este dominio.
- EAFNOSUPPORT
- La implementación no soporta la familia de direcciones
especificada.
- ENFILE
- No hay suficiente memoria en el núcleo para reservar una nueva
estructura de conector.
- EMFILE
- Se ha desbordado la tabla de ficheros del proceso.
- EACCES
- Se deniega el permiso para crear un conector del tipo o protocolo
especificado.
- ENOBUFS o ENOMEM
- No hay suficiente memoria disponible. El conector no puede crearse hasta
que no queden libres los recursos suficientes.
- EINVAL
- Protocolo desconocido o familia de protocolo no disponible.
Los módulos de los protocolos subyacentes pueden generar otros errores.
4.4BSD (la llamada a función
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).
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.
FALLOS¶
SOCK_UUCP todavía no está implementado.
VÉASE TAMBIÉN¶
accept(2),
bind(2),
connect(2),
fcntl(2),
getpeername(2),
getsockname(2),
getsockopt(2),
ioctl(2),
listen(2),
read(2),
recv(2),
select(2),
send(2),
shutdown(2),
socketpair(2),
write(2),
getprotoent(3),
ip(7),
socket(7),
tcp(7),
udp(7),
unix(7)
“An Introductory 4.3 BSD Interprocess Communication Tutorial”
está reimpreso en
UNIX Programmer's Supplementary Documents Volume
1.
“BSD Interprocess Communication Tutorial” está reimpreso en
UNIX Programmer's Supplementary Documents Volume 1.