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.