Provided by:
manpages-es_1.55-10_all 
NOMBRE
socket - crea un extremo de una comunicacion
SINOPSIS
#include <sys/types.h>
#include <sys/socket.h>
int socket(int dominio, int tipo, int protocolo);
DESCRIPCI'ON
Socket crea un extremo de una comunicacion y devuelve un descriptor.
El parametro dominio especifica un dominio de comunicaciones. Esto
selecciona la familia de protocol que se usara para la comunicacion.
Estas familias se definen en <sys/socket.h>. Los formatos actualmente
reconocidos incluyen:
Nombre Proposito Pagina de manual
PF_UNIX,PF_LOCAL Comunicacion 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 netlink(7)
usuario del nucleo
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 packet(7)
nivel
El conector tiene el tipo indicado, que especifica la semantica de la
comunicacion. Los tipos definidos en la actualidad son:
SOCK_STREAM
Proporciona flujos de bytes basados en una conexion
bidireccional secuenciada, confiable. Se puede admitir un
mecanismo de transmision de datos fuera-de-banda.
SOCK_DGRAM
Admite datagramas (mensajes no confiables, sin conexion, de una
longitud maxima fija).
SOCK_SEQPACKET
Proporciona un camino de transmision de datos basado en conexion
bidireccional secuenciado, confiable, para datagramas de
longitud maxima 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 deberia 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 esta
implementado para AF_INET.
El protocolo especifica un protocolo particular para ser usado con el
conector. Normalmente solo 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 numero de protocolo a
emplear es especifico al "dominio de comunicacion" en el que la
comunicacion va a tener lugar; vea protocols(5). Consulte
getprotoent(3) para ver como asociar una cadenas con el nombre de un
protocolo a un numero de protocolo.
Los conectores del tipo SOCK_STREAM son flujos de bytes
bidireccionales, similares a tuberias, que no conservan los limites de
registro. Un conector de flujo debe estar en un estado conectado antes
de que cualquier dato pueda ser enviado o recibido en el. Se crea una
conexion con otro conector mediante la llamada connect(2). Una vez
hecha la conexion, los datos pueden transferirse utilizando llamadas
read(2) y write(2) o alguna variante de las llamadas send(2) y recv(2).
Cuando una sesion se ha completado, se puede efectuar un close(2). Los
datos fuera-de-banda pueden transmitirse tambien como se describe en
send(2) y recibirse segun 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 bufer no
puede ser transmitido satisfactoriamente en un periodo razonable de
tiempo, entonces la conexion se considera muerta. Cuando se activa
SO_KEEPALIVE en el conector el protocolo comprueba de una manera
especifica del protocolo si el otro extremo todavia esta vivo. Se lanza
una senal SIGPIPE si un proceso envia o recibe en un flujo roto; esto
provoca que procesos simples, que no manejan la senal, acaben. Los
conectores SOCK_SEQPACKET emplean las mismas llamadas al sistema que
los SOCK_STREAM. La unica diferencia es que las llamadas a read(2)
devolveran solamente la cantidad de datos pedidos, y los que queden en
el paquete que llega se perderan. Tambien se conservaran todos los
limites de mensaje en los datagramas que lleguen.
Los conectores SOCK_DGRAM y SOCK_RAW permiten el envio 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 direccion 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 senal SIGURG cuando
lleguen los datos fuera-de-banda o la senal SIGPIPE cuando una conexion
SOCK_STREAM se rompa inesperadamente. Tambien puede usarse para
configurar el proceso o grupo de procesos que recibiran la E/S y la
notificacion asincrona de los eventos de E/S a traves de SIGIO. Usar
F_SETOWN es equivalente a una llamada a ioctl(2) con el argumento
FIOSETOWN o SIOCSPGRP.
Cuando la red senala una condicion de error al modulo del protocolo
(por ejemplo, usando un mensaje ICMP para IP) se activa la bandera de
error pendiente para el conector. La siguiente operacion sobre ese
conector devolvera el codigo de error del error pendiente. Para algunos
protocolos es posible habilitar una cola de error por conector para
obtener informacion detallada del error. Vea IP_RECVERR en ip(7).
La operacion 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 implementacion no soporta la familia de direcciones
especificada.
ENFILE No hay suficiente memoria en el nucleo 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 modulos de los protocolos subyacentes pueden generar otros errores.
CONFORME A
4.4BSD (la llamada a funcion socket aparecio 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 pagina de
manual BSD promete: "La familia de protocolos generalmente es la misma
que la familia de direcciones" y los estandares subsiguientes usan AF_*
en todas partes.
FALLOS
SOCK_UUCP todavia no esta implementado.
V'EASE TAMBI'EN
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" esta
reimpreso en UNIX Programmer's Supplementary Documents Volume 1.
"BSD Interprocess Communication Tutorial" esta reimpreso en UNIX
Programmer's Supplementary Documents Volume 1.
Pagina man de Linux 24 abril 1999 SOCKET(2)