GETSOCKOPT(2)

NOMBRE
getsockopt, setsockopt - obtiene y pone opciones en zócalos (sockets)

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

int getsockopt(int s, int nivel, int nomopc, void *valopc, int *lonopc);

int setsockopt(int s, int nivel, int nomopc, const void *valopc, int lonopc);

DESCRIPTION
Getsockopt y setsockopt manipulan las opciones asociadas a un zócalo. Éstas pueden existir en múltiples niveles de protocolo; siempre están presentes en el nivel más alto de zócalo. Al manipular opciones de zócalo, deben especificarse el nivel en el que reside la opción, y su nombre. Para manipular opciones en el nivel de zócalo, nivel se especifica como SOL_SOCKET. Para manipular opciones a cualquier otro nivel, se suministra el número de protocolo del apropiado que controle la opción. Por ejemplo, para indicar que una opción ha de ser interpretada por el protocolo TCP , nivel debe ponerse como el número de protocolo de TCP; vea getprotoent(3). Los parámetros valopc y lonopc se emplean para acceder a valores de opciones de setsockopt. Para getsockopt identifican a un búfer en el que se pondrá el valor para la opción pedida (u opciones). Para getsockopt, lonopc es un parámetro por referencia, que contiene inicialmente el tamaño del búfer apuntado por optval, y que se modifica al acabar la función para contener el tamaño real del valor devuelto. Si no se va a suministrar o devolver un valor de opción, valopc puede ser NULL. Nomopc y cualesquiera opciones especificadas se pasan sin interpretar al módulo de protocolo apropiado para su interpretación. El fichero de cabecera <sys/socket.h> contiene definiciones para opciones de nivel de zócalo, descritas más abajo. Las opciones a otros niveles de protocolo varían en formato y nombre; consulte las páginas apropiadas de la sección 4 del Manual. La mayoría de las opciones de nivel-zócalo utilizan un parámetro int para valopc. Para setsockopt, el parámetro debe ser distinto de cero para permitir una opción booleana, o cero si la opción va a ser deshabilitada. SO_LINGER emplea un parámetro struct linger , definido en <linux/socket.h>, que especifica el estado deseado de la opción y el intervalo de retardo (vea más adelante). SO_SNDTIMEO y SO_RCVTIMEO emplean un parámetro struct timeval , definido en <sys/time.h>. Se reconocen las opciones siguientes en el nivel de zócalo. Salvo que se diga otra cosa, cada una puede ser examinada con getsockopt y puede ser puesta con setsockopt.

SO_DEBUG
    permite la grabación de información de depuración

SO_REUSEADDR
    permite reutilización de dirección local

SO_KEEPALIVE
    permite mantener vivas las conexiones

SO_DONTROUTE
    permite salto por encima de encaminamiento para mensajes salientes

SO_LINGER
    retardo al cerrar si hay datos presentes

SO_BROADCAST
    da permiso para transmitir mensajes de difusión

SO_OOBINLINE
    permite recepción de datos fuera-de-banda en banda

SO_SNDBUF
    pone el tamaño del búfer de salida

SO_RCVBUF
    pone el tamaño del búfer de entrada

SO_SNDLOWAT
    pone la cuenta mínima para la salida

SO_RCVLOWAT
    pone la cuenta mínima para la entrada

SO_SNDTIMEO
    obtiene el valor del tiempo de espera para la salida (sólo obtiene)

SO_RCVTIMEO
    obtiene el valor del tiempo de espera para la entrada (sólo obtiene)

SO_TYPE
    obtiene el tipo del zócalo (sólo obtiene)

SO_ERROR
    obtiene y limpia el estado de error del zócalo (sólo obtiene)

SO_DEBUG permite depuración en los módulos de protocolo subyacentes. SO_REUSEADDR indica que las reglas empleadas en la validación de direcciones suministradas en una llamada a bind(2) deben permitir reutilización de direcciones locales. SO_KEEPALIVE permite la transmisión periódica de mensajes en un zócalo conectado. Si el vecino conectado fallara en responder a estos mensajes, la conexión se considerará rota, y cuando los procesos que utilicen el zócalo intentaran enviar datos se les notificaría de aquel hecho mediante uan señal SIGPIPE . SO_DONTROUTE indica que los mensajes salientes deben saltar sobre las facilidades normales de encaminamiento. En vez de eso, los mensajes se redirigen a la interfaz de red apropiada según la porción de red de la dirección de destino. SO_LINGER controla la acción tomada cuando mensajes no enviados se ponen en cola en el zócalo y se ejecuta un close(2). Si el zócalo promete la entrega confiable de datos y SO_LINGER está activado, el sistema bloqueará el proceso en el intento close hasta que sea capaz de transmitir los datos o hasta que decida que es incapaz de entregar la información (un período de espera, nombrado como el intervalo de retardo, se especifica en la llamada a setsockopt cuando SO_LINGER ha sido requerido). Si SO_LINGER está inhabilitado y se ha llamado a close , el sistema procesará el cierre de tal manera que permita al proceso continuar tan rápidamente como sea posible. La estructura linger se define en <linux/socket.h> de la siguiente forma:

    struct linger {
            int  l_onoff;   /* Retardo activo */
            int  l_linger;  /* por cuánto tiempo */
    };
l_onoff indica si retardar o no. Si está puesto a 1 entonces l_linger contiene el tiempo en centésimas de segundos que el proceso debe retardarse para completar el close. Si l_onoff está a cero, el proceso regresa inmediatamente. La opción SO_BROADCAST pide permiso para enviar datagramas de difusión en el zócalo. La difusión era una operación privilegiada en anteriores versiones del sistema. Con protocolos que admiten datos fuera-de-banda, la opción SO_OOBINLINE pide que los datos fuera-de-banda se pongan en la cola normal de datos de entrada tal como se reciban; entonces será accesible con llamadas recv o read sin la señal MSG_OOB . Algunos protocolos siempre se comportan como si esta opción estuviera activa. SO_SNDBUF y SO_RCVBUF son opciones para ajustar los tamaños normales de búfer asignados para los búferes de entrada y salida, respectivamente. El tamaño de búfer puede ser incrementado para conexiones de mucho volumen, o decrementado para limitar el posible backlog de datos entrantes. El sistema impone un límite absoluto en estos valores. SO_SNDLOWAT es una opción para establecer la mínima cuenta para operaciones de salida. La mayoría de las operaciones de salida procesan todos los datos suministrados por la llamada, entregando datos al protocolo para su transmisión y bloqueando según convenga para el control de flujo. Las operaciones de salida no bloqueantes procesarán tantos datos como puedan sujetas al control de flujo sin bloqueo, pero no procesarán ningún dato si el control de flujo no permite que sea procesado el valor más pequeño de la marca baja de agua de la petición entera. Una operación select(2) que compruebe la capacidad de escribir en un zócalo devulverá verdadero sólo si la cantidad de la marca baja de agua pudiera procesarse. El valor predeterminado de SO_SNDLOWAT está establecido como un tamaño conveniente para la eficacia de la red, a menudo 1024. SO_RCVLOWAT es una opción para poner la cuenta mínima para operaciones de entrada. En general, las llamadas de recepción se bloquearán hasta que se reciba alguna cantidad (no cero) de datos, entonces regresarán con la menor de las cantidades disponible o pedida. El valor predeterminado de SO_RCVLOWAT es 1. Si SO_RCVLOWAT está puesto a un valor mayor, las llamadas de recepción bloqueantes normalmente esperan hasta que han recibido el valor más pequeño de la marca de agua baja o la cantidad pedida. Las llamadas de recepción pueden aún devolver algo menor que la marca de agua baja si ocurre un error, si se captura una señal, o si el tipo de los datos siguientes de la cola de recepción es diferente del que se ha devuelto. SO_SNDTIMEO es una opción para obtener el valor del tiempo de espera para operaciones de salida. (Puede usarse con getsockopt solamente). Devuelve un parámetro struct timeval con el número de segundos y microsegundos empleados para limitar esperas para que se completen las operaciones de salida. SO_RCVTIMEO es una opción para obtener el valor del tiempo de espera para operaciones de entrada. (Puede emplearse con getsockopt solamente). Devuelve un parámetro struct timeval con el número de segundos y microsegundos empleados para limitar esperas para que se completen las operaciones de entrada. En la implementación actual, este temporizador se pone a cero cada vez que se reciben datos adicionales por el protocolo, y por tanto el límite es en efecto un temporizador de inactividad. Si una operación de recepción ha sido bloqueada durante este tiempo sin recibir datos adicionales, regresa con una cuenta corta o con el error EWOULDBLOCK si no se recibieron datos. Finalmente, también SO_TYPE y SO_ERROR son opciones empleadas sólo con getsockopt. SO_TYPE devuelve el tipo del zócalo, como SOCK_STREAM; es útil para servidores que heredan zócalos en el arranque. SO_ERROR devuelve cualquier error pendiente en el zócalo y limpia el indicador de estado de error. Puede emplearse para comprobar la ocurrencia de errores asíncronos en zócalos de datagramas conectados o de otros tipos de errores asíncronos.

VALOR DE RETORNO
Se devuelve cero en caso de éxito. En caso de error se devuelve -1, y errno toma un valor apropiado.

ERRORES

EBADF
    El argumento s no es un descriptor válido.

ENOTSOCK
    El argumento s es un fichero, no un zócalo.

ENOPROTOOPT
    La opción es desconocida al nivel indicado.

EFAULT
    La dirección apuntada por valopc no está en un sitio válido del espacio de direcciones del proceso. Para getsockopt, este error puede también ser devuelto si lonopc no está en un sitio válido del espacio de direcciones del proceso.

CONFORME CON
SVr4, 4.4BSD (estas primitivas aparecieron por primera vez en 4.2BSD). SVr4 documenta los códigos de error adicionales ENOMEM y ENOSR, pero no documenta las opciones SO_SNDLOWAT, SO_RCVLOWAT, SO_SNDTIMEO ni SO_RCVTIMEO

FALLOS
Algunas de las opciones de zócalo deberían ser manejadas a niveles más bajos del sistema.

VEA
ioctl(2), socket(2), getprotoent(3), protocols(5)