SOCKET(2)

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 dentro del cual tendrá lugar la comunicación; esto selecciona la familia de protocolo que deberá emplearse. Estas familias se definen en el fichero de cabecera sys/socket.h. Los formatos actualmente reconocidos son

    AF_UNIX
        (protocolos internos de UNIX)

    AF_INET
        (protocolos de ARPA Internet)

    AF_ISO
        (protocolos ISO)

    AF_NS
        (protocolos de Xerox Network Systems)

    AF_IMPLINK
        (capa de enlace IMP “anfitrión en IMP”)
El zócalo tiene el tipo indicado, que especifica la semántica de la comunicación. Los tipos definidos en la actualidad son:
    SOCK_STREAM
    SOCK_DGRAM
    SOCK_RAW
    SOCK_SEQPACKET
    SOCK_RDM
Un tipo 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. Un zócalo SOCK_DGRAM admite datagramas (mensajes no confiables, sin conexión, de una longitud máxima (normalmente pequeña) fija). Un zócalo SOCK_SEQPACKET puede proporcionar un camino de transmisión de datos basado en conexión bidireccional secuenciado, confiable, para datagramas de longitud máxima fija; se puede requerir un consumidor para leer un paquete entero con cada llamada al sistema de lectura. Esta facilidad es específica del protocolo, y está actualmente implementada solamente para AF_NS. Zócalos SOCK_RAW proporcionan acceso a interfaces y protocolos de red internos. Los tipos SOCK_RAW, que sólo está disponible para el súper-usuario, y SOCK_RDM, que está planificado, pero no aún implementado, no se describen aquí. El protocolo especifica un protocolo particular para ser usado con el zócalo. Normalmente sólo existe un protocolo que admita un tipo particular de zócalo dentro de una familia de protocolos dada. 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 particular al “dominio de comunicación” en el que la comunicación va a tener lugar; vea protocols(5). Los zócalos del tipo SOCK_STREAM son flujos de bytes bidireccionales, similar a tuberías. Un zócalo 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 zócalo 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 usados para implementar 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 rota y las llamadas indicarán un error devolviendo -1 y con el código ETIMEDOUT en la variable global errno. Los protocolos opcionalmente mantienen los zócalos calientes forzando transmisiones más o menos cada minuto en ausencia de otra actividad. Entonces se induce un error si no se descubre una respuesta en una conexión en otro caso inactiva en un período extendido de tiempo (p. ej. 5 minutos). Se lanza una señal SIGPIPE si un proceso envía en un flujo roto; esto provoca que procesos simples, que no manejan la señal, acaben. Los zócalos 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. Los zócalos 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. Una llamada a fcntl(2) puede utilizarse para especificar que un grupo de proceso reciba una señal SIGURG cuando lleguen los datos fuera-de-banda. También puede activar la E/S no bloqueante y la notificación asíncrona de los eventos a través de SIGIO. La operación de los zócalos se controla por opciones en el nivel de los zócalos. Estas opciones se definen en el fichero de cabecera sys/socket.h. Setsockopt(2) y getsockopt(2) se emplean para establecer y obtener opciones, respectivamente.

VALORES DEVUELTOS
Se devuelve un -1 si ocurre un error; en otro caso el valor devuelto es un descriptor para referenciar el zócalo.

ERRORES

EPROTONOSUPPORT
    El tipo de protocolo, o el protocolo especificado, no es reconocido dentro de este dominio.

EMFILE
    La tabla de descriptores por proceso está llena.

ENFILE
    La tabla de ficheros del sistema está llena.

EACCES
    Se deniega el permiso para crear un zócalo del tipo o protocolo especificado.

ENOBUFS
    No hay bastante espacio de búfer. El zócalo no puede crearse hasta que no queden libres los recursos suficientes.

CONFORME CON
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 zócalos de BSD (incluyendo variantes System V).

CONSULTE TAMBIÉN
accept(2), bind(2), connect(2), getprotoent(3), getsockname(2), getsockopt(2), ioctl(2), listen(2), read(2), recv(2), select(2), send(2), shutdown(2), socketpair(2), write(2)

"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