Section: Manual del Programador de Linux (2)
Updated: abril 1999
Index Return to Main
Contents
recv, recvfrom, recvmsg - reciben un mensaje desde un conector
int recv(int s, void *buf, size_t lon, int flags);
int recvfrom(int s, void *buf, size_t lon, int flags, struct sockaddr *desde, socklen_t *londesde);
int recvmsg(int s, struct msghdr *msg, int flags);
Las llamadas recvfrom y recvmsg se emplean para recibir mensajes desde un conector (``socket''), y pueden utilizarse para recibir datos de un conector sea orientado a conexión o no.
Si desde no es NULL y el conector no es orientado a conexión, la dirección fuente del mensaje se llena. El argumento 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 conector conectado (vea connect(2)) y es idéntica a recvfrom con un parámetro desde con valor NULL.
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 conector del que se reciba el mensaje (vea socket(2)).
Si no hay mensajes disponibles en el conector, las llamadas de recepción esperan que llegue un mensaje, a menos que el conector sea no bloqueante (vea fcntl(2)) en cuyo caso se devuelve el valor -1 y la variable externa errno toma el valor EAGAIN. 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.
Las llamadas select(2) o poll(2) pueden emplearse para determinar cuándo llegan más datos.
El argumento flags de una llamada a recv se forma aplicando el operador de bits O-lógico a uno o más de los valores siguientes:
El error se suministra en una estructura sock_extended_err:
#define SO_EE_ORIGIN_NONE 0
#define SO_EE_ORIGIN_LOCAL 1
#define SO_EE_ORIGIN_ICMP 2
#define SO_EE_ORIGIN_ICMP6 3
struct sock_extended_err
{
u_int32_t ee_errno; /* número de error */
u_int8_t ee_origin; /* origen del error */
u_int8_t ee_type; /* tipo */
u_int8_t ee_code; /* código */
u_int8_t ee_pad;
u_int32_t ee_info; /* información adicional */
u_int32_t ee_data; /* otros datos */
/* Pueden ir más datos a continuación .*/
};
struct sockaddr *SOCK_EE_OFFENDER(struct sock_extended_err *);
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 {
void * msg_name; /* dirección opcional */
socklen_t msg_namelen; /* tamaño de la dirección */
struct iovec * msg_iov; /* vector dispersar/agrupar */
size_t msg_iovlen; /* nº de elementos en msg_iov */
void * msg_control; /* datos auxiliares, ver más abajo */
socklen_t msg_controllen; /* long buffer datos auxiliares */
int msg_flags; /* opciones en mensaje recibido */
};
Aquí msg_name y msg_namelen especifican la dirección de destino si el conector está desconectado; msg_name puede darse como un puntero nulo si no se desean o requieren nombres. Los campos msg_iov y msg_iovlen describen localizaciones dispersar/agrupar, como se discute en readv(2). El campo msg_control, que tiene de longitud msg_controllen, apunta a un búfer para otros mensajes relacionados con control de protocolo o para datos auxiliares diversos. Cuando se llama a recvmsg, msg_controllen debe contener la longitud del buffer disponible en msg_control; a la vuelta de una llamada con éxito contendrá la longitud de la secuencia de mensajes de control.
Los mensajes son de la forma:
struct cmsghdr {
socklen_t 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[]; */
};
Los datos auxiliares sólo deberían ser accedidos mediante las macros definidas en cmsg(3).
Como ejemplo, Linux usa este mecanismo de datos auxiliares para pasar errores ampliados, opciones IP o descriptores de fichero mediante conectores Unix.
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 conectores 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. MSG_ERRQUEUE indica que no se ha recibido ningún dato sino un error ampliado de la cola de errores de conectores.
Estas llamadas devuelven el número de bytes recibidos, o bien -1 en caso de que ocurriera un error.
Estos son algunos errores estándares generados por la capa de conectores. Los modulos de los protocolos subyacentes pueden generar y devolver errores adicionales. Consulte sus páginas de manual.
4.4BSD (estas funciones aparecieron por primera vez en 4.2BSD).
Los prototipos datos anteriormente siguen a glibc2. The Single Unix Specification coincide en todo excepto en que el tipo de los valores devueltos es `ssize_t' (mientras que BSD 4.*, libc4 y libc5 tienen `int'). El argumento flags es un `int' en BSD 4.* pero es un `unsigned int' en libc4 y libc5. El argumento lon es un `int' en BSD 4.* pero es un `size_t' en libc4 y libc5. El argumento londesde es un `int' en BSD 4.*, libc4 y libc5. El actual `socklen_t *' fue inventado por POSIX. Vea también accept(2).
(2), read(2), select(2), getsockopt(2), socket(2), cmsg(3)
This document was created by man2html, using
the manual pages.
Time: 06:16:20 GMT, January 22, 2005