RECV(2)

NOMBRE
recv, recvfrom, recvmsg - reciben un mensaje desde un zócalo

SINOPSIS
#include <sys/types.h>
#include <sys/socket.h>

int recv(int s, void *buf, int lon, unsigned int flags);

int recvfrom(int s, void *buf, int lon, unsigned int flags , struct sockaddr *desde, int *londesde);

int recvmsg(int s, struct msghdr *msg, unsigned int flags);

DESCRIPCIÓN
Las primitivas recvfrom y recvmsg se emplean para recibir mensajes desde un zócalo (``socket''), y pueden utilizarse para recibir datos de un zócalo sea orientado a conexión o no. Si desde no es nulo, y el zócalo no es orientado a conexión, la dirección fuente del mensaje se llena. Londesde es un parámetro por referencia, inicializado al tamaño del búfer asociado con desde, y modificado cuando la función regresa para indicar el tamaño real de la dirección guardada ahí. La llamada a recv se utiliza normalmente sólo en un zócalo conectado (vea connect(2)) y es idéntica a recvfrom con un parámetro desde nulo. Como es redundante, puede que en futuras distribuciones no esté mantenida. Las tres rutinas devuelven la longitud del mensaje cuando terminan bien. Si un mensaje es demasiado largo como para caber en el búfer suministrado, los bytes que sobran pueden descartarse dependiendo del tipo de zócalo del que se reciba el mensaje (vea socket(2)). Si no hay mensajes disponibles en el zócalo, la llamada de recepción espera que llegue un mensaje, a menos que el zócalo sea no bloqueante (vea fcntl(2)) en cuyo caso se devuelve el valor -1 y la variable externa errno toma el valor EWOULDBLOCK. Las llamadas de recepción devuelven normalmente cualquier dato disponible, hasta la cantidad pedida, en vez de esperar la recepción de la cantidad pedida completa; este comportamiento se ve afectado por las opciones del nivel de zócalos SO_RCVLOWAT y SO_RCVTIMEO descritas en getsockopt(2). La llamada select(2) puede emplearse para determinar cuándo llegan más datos. El argumento flags de una llamada a recv se forma aplicando el operador de bits OR a uno o más de los valores:

MSG_OOB
    procesar datos fuera-de-banda

MSG_PEEK
    mirar el mensaje entrante

MSG_WAITALL
    esperar a que se complete la petición u ocurra un error La opción MSG_OOB pide la recepción de datos fuera-de-banda que no se recibirían en el flujo de datos normal. Algunos protocolos ponen datos despachados con prontitud en la cabeza de la cola de datos normales, y así, esta opción no puede emplearse con tales protocolos. La opción MSG_PEEK hace que la operación de recepción devuelva datos del principio de la cola de recepción sin quitarlos de allí. Así, una próxima llamada de recepción devolverá los mismos datos. La opción MSG_WAITALL pide que la operación se bloquee hasta que se satisfaga la petición completamente. Sin embargo, la llamada puede aún devolver menos datos de los pedidos si se captura una señal, si ocurre un error o una desconexión, o si los próximos datos que se van a recibir son de un tipo diferente del que se ha devuelto. La llamada recvmsg utiliza una estructura msghdr para minimizar el número de parámetros suministrados directamente. Esta estructura tiene la forma siguiente, según se define en sys/socket.h:
    struct msghdr {
    	caddr_t	msg_name;	/* dirección opcional */
    	u_int	msg_namelen;	/* tamaño de dirección */
    	struct	iovec *msg_iov;	/* vector disperso/reunido */
    	u_int	msg_iovlen;	/* Nº de elementos en msg_iov */
    	caddr_t	msg_control;	/* datos auxiliares, vea abajo */
    	u_int	msg_controllen; /* long. búfer datos auxiliares */
    	int	msg_flags;	/* opciones en mensaje recibido */
    };
Aquí msg_name y msg_namelen especifican la dirección de destino si el zócalo está desconectado; msg_name puede darse como un puntero nulo si no se desean o requieren nombres. Msg_iov y msg_iovlen describen localizaciones recogidas dispersas, como se discute en readv(2). Msg_control, que tiene de longitud msg_controllen, apunta a un búfer para otros mensajes relacionados con control de protocolo o para otros datos auxiliares diversos. Los mensajes son de la forma:
    struct cmsghdr {
    	u_int	cmsg_len;	/* Nº de byte de datos, incluye cab. */
    	int	cmsg_level;	/* protocolo originante */
    	int	cmsg_type;	/* tipo específico del protocolo */
    /* seguido por
    	u_char	cmsg_data[]; */
    };
Como ejemplo, uno podría usar esto para saber los cambios en el flujo de datos en XNS/SSP, o en ISO, para obtener datos de petición-de-conexión-de-usuario mediante la llamada a recvmsg sin proporcionar un búfer de datos, inmediatamente tras una llamada a accepct. Los descriptores de ficheros abiertos se pasan ya como datos auxiliares para zócalos de dominio AF_UNIX, con cmsg_level puesto a SOL_SOCKET y cmsg_type puesto a SCM_RIGHTS. El campo msg_flags toma un valor al regresar dependiendo del mensaje recibido. MSG_EOR indica fin-de-registro; los datos devueltos completaron un registro (generalmente empleado con zócalos del tipo SOCK_SEQPACKET). MSG_TRUNC indica que la porción trasera de un datagrama ha sido descartada porque el datagrama era más grande que el búfer suministrado. MSG_CTRUNC indica que algún dato de control ha sido descartado debido a la falta de espacio en el búfer para datos auxiliares. MSG_OOB se devuelve para indicar que se han recibido datos despachados prontamente o fuera-de-banda.

VALORES DEVUELTOS
Estas llamadas devuelven el número de bytes recibidos, o bien -1 en caso de que ocurriera un error.

ERRORES

EBADF
    El argumento s es un descriptor inválido.

ENOTCONN
    El zócalo está asociado con un protocolo orientado a la conexión y no ha sido conectado (vea connect(2) y accept(2)).

ENOTSOCK
    El argumento s no se refiere a un zócalo.

EWOULDBLOCK
    El zócalo está marcado como no-bloqueante, y la operación de recepción produciría un bloqueo, o se ha puesto un límite de tiempo en la recepción, que ha expirado antes de que se recibieran datos.

EINTR
    La recepción ha sido interrumpida por la llegada de una señal antes de que hubiera algún dato disponible.

EFAULT
    El puntero a búfer de recepción (o punteros) apunta afuera del espacio de direcciones del proceso.

CONFORME CON
4.4BSD (estas funciones aparecieron por primera vez en 4.2BSD).

CONSULTE TAMBIÉN
fcntl(2), read(2), select(2), getsockopt(2), socket(2)