ICTLs de Winsock
En esta sección se describen los controles de entrada y salida (IOCTLs) de Winsock Socket para varias ediciones de sistemas operativos Windows. Use la función WSAIoctl o WSPIoctl para emitir un IOCTL de Winsock para controlar el modo de un socket, el protocolo de transporte o el subsistema de comunicaciones.
Algunos IOCTL de Winsock requieren más explicación de lo que puede transmitir esta tabla; estas opciones contienen vínculos a temas adicionales.
Es posible adoptar un esquema de codificación que conserva los códigos de operación ioctlsocket definidos actualmente, al tiempo que proporciona una manera cómoda de particionar el espacio del identificador de código de operación en tanto el parámetro dwIoControlCode es ahora una entidad de 32 bits. El parámetro dwIoControlCode se crea para permitir la independencia del protocolo y del proveedor al agregar nuevos códigos de control mientras se conserva la compatibilidad con versiones anteriores con los códigos de control de Windows Sockets 1.1 y Unix. El parámetro dwIoControlCode tiene el siguiente formato.
I | O | V | T | Familia de proveedores y direcciones | Código |
---|---|---|---|---|---|
3 | 3 | 2 | 2 2 | 2 2 2 2 2 2 2 1 1 1 1 | 1 1 1 1 1 1 |
1 | 0 | 9 | 8 7 | 6 5 4 3 2 1 0 9 8 7 6 | 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 |
Nota
Los bits del parámetro dwIoControlCode que se muestra en la tabla deben leerse verticalmente de arriba a abajo por columna. Por lo tanto, el bit más a la izquierda es el bit 31, el siguiente bit es 30 y el bit más a la derecha es 0.
Se establece si el búfer de entrada es válido para el código, como con IOC_IN.
O se establece si el búfer de salida es válido para el código, como con IOC_OUT. Los códigos de control que usan los búferes de entrada y salida establecen E y O.
V se establece si no hay parámetros para el código, como con IOC_VOID.
T es una cantidad de 2 bits que define el tipo del IOCTL. Se definen los valores siguientes:
0 El IOCTL es un código IOCTL estándar de Unix, como con FIONREAD y FIONBIO.
1 El IOCTL es un código IOCTL genérico de Windows Sockets 2. Los nuevos códigos IOCTL definidos para Windows Sockets 2 tendrán T == 1.
2 El IOCTL se aplica únicamente a una familia de direcciones específica.
3 El IOCTL solo se aplica a un proveedor específico, como con IOC_VENDOR. Este tipo permite a las empresas asignar un número de proveedor que aparece en el parámetro familia Vendor/Address . A continuación, el proveedor puede definir nuevas ICTL específicas de ese proveedor sin tener que registrar el IOCTL con un centro de compensación, lo que proporciona flexibilidad y privacidad del proveedor.
Familia de proveedores y direcciones Cantidad de 11 bits que define al proveedor que posee el código (si T == 3) o que contiene la familia de direcciones a la que se aplica el código (si T == 2). Si se trata de un código IOCTL de Unix (T == 0), este parámetro tiene el mismo valor que el código en Unix. Si se trata de un IOCTL genérico de Windows Sockets 2 (T == 1), este parámetro se puede usar como extensión del parámetro de código para proporcionar valores de código adicionales.
Código Cantidad de 16 bits que contiene el código IOCTL específico para la operación.
Códigos IOCTL de Unix
Se admiten los siguientes códigos IOCTL de Unix (comandos).
FIONBIO
Habilite o deshabilite el modo de no bloqueo en los sockets. El parámetro lpvInBuffer apunta a un long sin signo (QoS), que es distinto de cero si el modo de no bloqueo se va a habilitar y cero si se va a deshabilitar. Cuando se crea un socket, funciona en modo de bloqueo (es decir, el modo de no bloqueo está deshabilitado). Esto es coherente con los sockets BSD.
La rutina WSAAsyncSelect o WSAEventSelect establece automáticamente un socket en modo sin bloqueo. Si se ha emitido WSAAsyncSelect o WSAEventSelect en un socket, cualquier intento de usar WSAIoctl para establecer el socket en modo de bloqueo producirá un error con WSAEINVAL. Para volver al modo de bloqueo del socket, una aplicación primero debe deshabilitar WSAAsyncSelect llamando a WSAAsyncSelect con el parámetro lEvent igual a cero o deshabilitar WSAEventSelect llamando a WSAEventSelect con el parámetro lNetworkEvents igual a cero.
FIONREAD
Determine la cantidad de datos que se pueden leer atómicamente desde sockets s. El parámetro lpvOutBuffer apunta a un long sin signo en el que WSAIoctl almacena el resultado.
Si el socket pasado en el parámetro s está orientado a flujos (por ejemplo, tipo SOCK_STREAM), FIONREAD devuelve la cantidad total de datos que se pueden leer en una sola operación de recepción; normalmente es igual que la cantidad total de datos en cola en el socket (ya que un flujo de datos está orientado a bytes, esto no está garantizado).
Si el socket pasado en el parámetro s está orientado a mensajes (por ejemplo, tipo SOCK_DGRAM), FIONREAD devuelve el número total de bytes disponibles para leer, no el tamaño del primer datagrama (mensaje) en cola en el socket.
SIOCATMARK
Determine si se han leído o no todos los datos de OOB. Esto solo se aplica a un socket de estilo de flujo (por ejemplo, tipo SOCK_STREAM) que se ha configurado para la recepción insertada de cualquier dato OOB (SO_OOBINLINE). Si no hay datos de OOB en espera de leerse, la operación devuelve TRUE. De lo contrario, devuelve FALSE y la siguiente operación de recepción realizada en el socket recuperará algunos o todos los datos anteriores a la marca; la aplicación debe usar la operación SIOCATMARK para determinar si queda alguna. Si hay datos normales que preceden a los datos urgentes (fuera de banda), se recibirán en orden. (Tenga en cuenta que las operaciones de recv nunca mezclarán OOB y los datos normales en la misma llamada). lpvOutBuffer apunta a un BOOL en el que WSAIoctl almacena el resultado.
Comandos de Windows Sockets 2
Se admiten los siguientes comandos de Windows Sockets 2.
SIO_ACQUIRE_PORT_RESERVATION (configuración de código de operación: I, T==3)
Solicite una reserva en tiempo de ejecución para un bloque de puertos TCP o UDP. En el caso de las reservas de puertos en tiempo de ejecución, el grupo de puertos requiere que las reservas se consuman desde el proceso en cuyo socket se concedió la reserva. Las reservas de puertos en tiempo de ejecución duran solo mientras dure el socket en el que se llamó al SIO_ACQUIRE_PORT_RESERVATION IOCTL. En cambio, las reservas de puertos persistentes creadas mediante la función CreatePersistentTcpPortReservation o CreatePersistentUdpPortReservation pueden consumir cualquier proceso con la capacidad de obtener reservas persistentes.
Para obtener información más detallada, consulte la referencia de SIO_ACQUIRE_PORT_RESERVATION .
SIO_ACQUIRE_PORT_RESERVATION se admite en Windows Vista y versiones posteriores del sistema operativo.
SIO_ADDRESS_LIST_CHANGE (configuración de código de operación: V, T==1)
Para recibir notificaciones de cambios en la lista de direcciones de transporte locales de la familia de protocolos del socket al que se puede enlazar la aplicación. No se proporcionará información de salida tras la finalización de este IOCTL; la finalización simplemente indica que la lista de direcciones locales disponibles ha cambiado y debe consultarse de nuevo a través de SIO_ADDRESS_LIST_QUERY.
Se supone (aunque no es necesario) que la aplicación usa E/S superpuesta para recibir una notificación de cambio al completar SIO_ADDRESS_LIST_CHANGE solicitud. Como alternativa, si el SIO_ADDRESS_LIST_CHANGE IOCTL se emite en un socket sin bloqueo y sin parámetros superpuestos (lpOverlapped/ lpCompletionRoutine se establece en NULL), se completará inmediatamente con el error WSAEWOULDBLOCK. A continuación, la aplicación puede esperar eventos de cambio de lista de direcciones a través de una llamada a WSAEventSelect o WSAAsyncSelect con FD_ADDRESS_LIST_CHANGE bit establecido en la máscara de bits del evento de red.
SIO_ADDRESS_LIST_QUERY (configuración de código de operación: O, T==1)
Obtiene una lista de direcciones de transporte locales de la familia de protocolos del socket al que la aplicación puede enlazar. La lista de direcciones varía en función de la familia de direcciones y algunas direcciones se excluyen de la lista.
Nota
En entornos de Windows Plug-n-Play, las direcciones se pueden agregar y quitar dinámicamente. Por lo tanto, las aplicaciones no pueden confiar en la información devuelta por SIO_ADDRESS_LIST_QUERY ser persistente. Las aplicaciones pueden registrarse para recibir notificaciones de cambio de dirección a través del SIO_ADDRESS_LIST_CHANGE IOCTL, que proporciona notificaciones a través de E/S superpuestas o FD_ADDRESS_LIST_CHANGE evento. La siguiente secuencia de acciones se puede usar para garantizar que la aplicación siempre tiene información de la lista de direcciones actual:
- Problema SIO_ADDRESS_LIST_CHANGE IOCTL
- Problema SIO_ADDRESS_LIST_QUERY IOCTL
- Cada vez que SIO_ADDRESS_LIST_CHANGE IOCTL notifica al cambio de la aplicación de la lista de direcciones (ya sea a través de E/S superpuestas o mediante la señalización FD_ADDRESS_LIST_CHANGE evento), se debe repetir toda la secuencia de acciones.
Para obtener información más detallada, consulte la referencia de SIO_ADDRESS_LIST_QUERY . SIO_ADDRESS_LIST_QUERY se admite en Windows 2000 y versiones posteriores.
SIO_APPLY_TRANSPORT_SETTING (configuración de código de operación: I, T==3)
Aplica una configuración de transporte a un socket. La configuración de transporte que se aplica se basa en el TRANSPORT_SETTING_ID pasado en el parámetro lpvInBuffer .
La única configuración de transporte que define actualmente es para la funcionalidad REAL_TIME_NOTIFICATION_CAPABILITY en un socket TCP.
Si el TRANSPORT_SETTING_ID pasado tiene establecido el miembro Guid en REAL_TIME_NOTIFICATION_CAPABILITY, se trata de una solicitud para aplicar la configuración de notificación en tiempo real para el socket TCP usado con controlChannelTrigger para recibir notificaciones de red en segundo plano en una aplicación de la Tienda Windows.
Para obtener información más detallada, consulte la referencia de SIO_APPLY_TRANSPORT_SETTING . SIO_APPLY_TRANSPORT_SETTING se admite en Windows 8, Windows Server 2012 y versiones posteriores.
SIO_ASSOCIATE_HANDLE (configuración de código de operación: I, T==1)
Asocie este socket al identificador (handle) especificado de la interfaz correspondiente. El búfer de entrada contiene el valor entero correspondiente a la constante de manifiesto de la interfaz complementaria (por ejemplo, TH_NETDEV y TH_TAPI.), seguido de un valor que es un identificador de la interfaz complementaria especificada, junto con cualquier otra información necesaria. Consulte la sección correspondiente de los anexos de Winsock para obtener detalles específicos de una interfaz complementaria determinada. El tamaño total se refleja en la longitud del búfer de entrada. No se requiere ningún búfer de salida. El código de error WSAENOPROTOOPT se indica para los proveedores de servicios que no admiten este IOCTL. El identificador asociado a este IOCTL se puede recuperar mediante SIO_TRANSLATE_HANDLE.
Se puede usar una interfaz complementaria, por ejemplo, si un proveedor determinado proporciona (1) una gran cantidad de controles adicionales sobre el comportamiento de un socket y (2) los controles son lo suficientemente específicos del proveedor que no se asignan a las funciones existentes de Windows Socket o a las que probablemente se definan en el futuro. Se recomienda usar el Modelo de objetos componentes (COM) en lugar de este IOCTL para detectar y realizar un seguimiento de otras interfaces que podrían ser compatibles con un socket. Este IOCTL está presente para la compatibilidad (inversa) con sistemas en los que COM no está disponible o no se puede usar por algún otro motivo.
SIO_ASSOCIATE_PORT_RESERVATION (configuración de opcode: I, T==3)
Asocie un socket a una reserva persistente o en tiempo de ejecución para un bloque de puertos TCP o UDP identificados por el token de reserva de puerto. El SIO_ASSOCIATE_PORT_RESERVATION IOCTL debe emitirse antes de que el socket esté enlazado. Si y cuando el socket está enlazado, el puerto asignado a él se seleccionará de la reserva de puertos identificada por el token especificado. Si no hay ningún puerto disponible en la reserva especificada, se producirá un error en la llamada a la función bind .
Para obtener información más detallada, consulte la referencia de SIO_ASSOCIATE_PORT_RESERVATION .
SIO_ASSOCIATE_PORT_RESERVATION se admite en Windows Vista y versiones posteriores del sistema operativo.
SIO_BASE_HANDLE (configuración de opcode: O, T==1)
Recupera el identificador del proveedor de servicios base para un socket determinado. El valor devuelto es un SOCKET.
Un proveedor de servicios en capas nunca interceptaría este IOCTL, ya que el valor devuelto debe ser el identificador de socket del proveedor de servicios base.
Si el búfer de salida no es lo suficientemente grande para un identificador de socket ( cbOutBuffer es menor que el tamaño de un SOCKET) o el parámetro lpvOutBuffer es un puntero NULL , SOCKET_ERROR se devuelve como resultado de este IOCTL y WSAGetLastError devuelve WSAEFAULT.
SIO_BASE_HANDLE se define en el archivo de encabezado Mswsock.h y se admite en Windows Vista y versiones posteriores.
SIO_BSP_HANDLE (configuración de código de operación: O, T==1)
Recupera el identificador del proveedor de servicios base para un socket usado por la función WSASendMsg . El valor devuelto es un SOCKET.
Este Ioctl lo usa un proveedor de servicios en capas para garantizar que el proveedor intercepte la función WSASendMsg .
Si el búfer de salida no es lo suficientemente grande para un identificador de socket ( cbOutBuffer es menor que el tamaño de un SOCKET) o el parámetro lpvOutBuffer es un puntero NULL , SOCKET_ERROR se devuelve como resultado de este IOCTL y WSAGetLastError devuelve WSAEFAULT.
SIO_BSP_HANDLE se define en el archivo de encabezado Mswsock.h y se admite en Windows Vista y versiones posteriores.
SIO_BSP_HANDLE_SELECT (configuración de opcode: O, T==1)
Recupera el identificador del proveedor de servicios base para un socket usado por la función select . El valor devuelto es un SOCKET.
Este Ioctl lo usa un proveedor de servicios en capas para asegurarse de que el proveedor intercepte la función select .
Si el búfer de salida no es lo suficientemente grande para un identificador de socket ( cbOutBuffer es menor que el tamaño de un SOCKET) o el parámetro lpvOutBuffer es un puntero NULL , SOCKET_ERROR se devuelve como resultado de este IOCTL y WSAGetLastError devuelve WSAEFAULT.
SIO_BSP_HANDLE_SELECT se define en el archivo de encabezado Mswsock.h y se admite en Windows Vista y versiones posteriores.
SIO_BSP_HANDLE_POLL (configuración de opcode: O, T==1)
Recupera el identificador del proveedor de servicios base para un socket utilizado por la función WSAPoll . El parámetro lpOverlapped debe ser un puntero NULL . El valor devuelto es un SOCKET.
Este Ioctl lo usa un proveedor de servicios en capas para asegurarse de que el proveedor intercepte la función WSAPoll .
Si el búfer de salida no es lo suficientemente grande para un identificador de socket ( cbOutBuffer es menor que el tamaño de un SOCKET), el parámetro lpvOutBuffer es un puntero NULL o el parámetro lpOverlapped no es un puntero NULL , SOCKET_ERROR se devuelve como resultado de este IOCTL y WSAGetLastError devuelve WSAEFAULT.
SIO_BSP_HANDLE_POLL se define en el archivo de encabezado Mswsock.h y se admite en Windows Vista y versiones posteriores.
SIO_CHK_QOS (configuración de opcode: I, O, T==3)
Recupera información sobre las características del tráfico de QoS. Durante la fase de transición en el sistema de envío entre la configuración de flujo y la recepción de un mensaje RESV (vea Cómo invoca el servicio RSVP TC para obtener más información sobre la fase de transición), el tráfico asociado a un flujo RSVP se forma en función del tipo de servicio (BEST EFFORT, CONTROLLED LOAD o GUARANTEED). Para obtener más información, consulte Uso de SIO_CHK_QOS en la sección Calidad de servicio del SDK de plataforma.
SIO_CPU_AFFINITY (configuración de código de operación: I, T==3)
Habilita el uso compartido de puertos y la paralelización de indicación de recepción. Cuando la aplicación usa esta opción de socket para asociar sockets a distintos procesadores y, a continuación, enlaza los sockets a la misma dirección, las indicaciones de recepción se distribuirán entre los sockets en función del hash de Escalado en lado de recepción (RSS). La configuración rss no cambia, por lo que cualquier flujo determinado (punto de conexión local, par punto de conexión remoto) siempre se indicará en el mismo procesador. Como resultado, todos los paquetes que pertenecen a un flujo determinado se indicarán en el mismo socket. Se debe llamar a este IOCTL antes de enlazar; de lo contrario, se devolverá WSAEINVAL. El búfer de entrada es un índice de procesador (basado en 0) de tipo USHORT. El IOCTL no es compatible con SO_REUSEADDR y SO_REUSE_MULTICASTPORT. Solo se admite para sockets UDP.
Nota
Si el destino es la versión 10.0.19041.0 (Windows 10, versión 2004) de Windows SDK, use el valor 0x98000015
en lugar del nombre SIO_CPU_AFFINITY.
SIO_ENABLE_CIRCULAR_QUEUEING (configuración de código de operación: V, T==1)
Indica al proveedor de servicios orientado a mensajes subyacente que nunca se debe quitar un mensaje recién llegado debido a un desbordamiento de cola de búfer. En su lugar, el mensaje más antiguo de la cola debe eliminarse para dar cabida al mensaje recién llegado. No se requieren búferes de entrada y salida. Tenga en cuenta que este IOCTL solo es válido para los sockets asociados a protocolos no confiables orientados a mensajes. El código de error WSAENOPROTOOPT se indica para los proveedores de servicios que no admiten este IOCTL.
SIO_FIND_ROUTE (configuración de código de operación: O, T==1)
Cuando se emite, este IOCTL solicita que se detecte la ruta a la dirección remota especificada como sockaddr en el búfer de entrada. Si la dirección ya existe en la memoria caché local, se invalida su entrada. En el caso de la IPX de Novell, esta llamada inicia un IPX GetLocalTarget (GLT), que consulta la red para la dirección remota especificada.
SIO_FLUSH (configuración de código de operación: V, T==1)
Descarta el contenido actual de la cola de envío asociada a este socket. No se requieren búferes de entrada y salida. El código de error WSAENOPROTOOPT se indica para los proveedores de servicios que no admiten este IOCTL.
SIO_GET_BROADCAST_ADDRESS (configuración de código de operación: O, T==1)
Este IOCTL rellena el búfer de salida con una estructura sockaddr que contiene una dirección de difusión adecuada para su uso con sendto/ WSASendTo. Este IOCTL no es compatible con sockets IPv6 y devuelve el código de error WSAENOPROTOOPT .
SIO_GET_EXTENSION_FUNCTION_POINTER (configuración de opcode: O, I, T==1)
Recupere un puntero a la función de extensión especificada compatible con el proveedor de servicios asociado. El búfer de entrada contiene un identificador único global (GUID) cuyo valor identifica la función de extensión en cuestión. El puntero a la función deseada se devuelve en el búfer de salida. Los proveedores de proveedores de servicios establecen identificadores de función de extensión y deben incluirse en la documentación del proveedor que describe las funcionalidades y la semántica de las funciones de extensión.
Los valores GUID de las funciones de extensión compatibles con el proveedor de servicios TCP/IP de Windows se definen en el archivo de encabezado Mswsock.h . El valor posible para estos GUID es el siguiente:
Término | Descripción |
---|---|
WSAID_ACCEPTEX |
Función de extensión AcceptEx . |
WSAID_CONNECTEX |
Función de extensión ConnectEx . |
WSAID_DISCONNECTEX |
Función de extensión DisconnectEx . |
WSAID_GETACCEPTEXSOCKADDRS |
La función de extensión GetAcceptExSockaddrs . |
WSAID_TRANSMITFILE |
Función de extensión TransmitFile . |
WSAID_TRANSMITPACKETS |
Función de extensión TransmitPackets . |
WSAID_WSARECVMSG |
La función de extensión LPFN_WSARECVMSG (WSARecvMsg ). |
WSAID_WSASENDMSG |
La función de extensión WSASendMsg . |
SIO_GET_GROUP_QOS (configuración de opcode: O, I, T==1)
Reservado para uso futuro con sockets.
Recupere la estructura de QOS asociada al grupo de sockets al que pertenece este socket. El búfer de entrada es opcional. Algunos protocolos (por ejemplo, RSVP) permiten usar el búfer de entrada para calificar una solicitud de calidad de servicio. La estructura de QOS se copiará en el búfer de salida. Si este socket no pertenece a un grupo de sockets adecuado, los miembros SendingFlowspec y ReceiveingFlowspec de la estructura QOS devuelta se establecen en NULL. El código de error WSAENOPROTOOPT se indica para los proveedores de servicios que no admiten la calidad del servicio.
SIO_GET_INTERFACE_LIST (configuración de opcode: O, T==0)
Devuelve una lista de interfaces IP configuradas y sus parámetros como una matriz de estructuras de INTERFACE_INFO .
Nota
La compatibilidad de este comando es obligatoria para los proveedores de servicios TCP/IP compatibles con Windows Sockets 2.
El parámetro lpvOutBuffer apunta al búfer en el que se va a almacenar la información sobre las interfaces como una matriz de estructuras de INTERFACE_INFO para direcciones IP de unidifusión en las interfaces. El parámetro cbOutBuffer especifica la longitud del búfer de salida. El número de interfaces devueltas (número de estructuras devueltas en el búfer a las que apunta el parámetro lpvOutBuffer ) se puede determinar en función de la longitud real del búfer de salida devuelto en el parámetro lpcbBytesReturned .
Si se llama a la función WSAIoctl con SIO_GET_INTERFACE_LIST y el miembro de nivel del parámetro socket s no se define como IPPROTO_IP, se devuelve WSAEINVAL . Una llamada a la función WSAIoctl con SIO_GET_INTERFACE_LIST devuelve WSAEFAULT si el parámetro cbOutBuffer que especifica la longitud del búfer de salida es demasiado pequeño recibir la lista de interfaces configuradas.
SIO_GET_INTERFACE_LIST se admite en Windows Me/98 y Windows NT 4.0 con SP4 y versiones posteriores.
SIO_GET_INTERFACE_LIST_EX (configuración de opcode: O, T==0)
Reservado para uso futuro con sockets.
Devuelve una lista de interfaces IP configuradas y sus parámetros como una matriz de estructuras de INTERFACE_INFO_EX .
El parámetro lpvOutBuffer apunta al búfer en el que se va a almacenar la información sobre las interfaces como una matriz de estructuras de INTERFACE_INFO_EX para direcciones IP de unidifusión en la interfaz. El parámetro cbOutBuffer especifica la longitud del búfer de salida. El número de interfaces devueltas (número de estructuras devueltas en lpvOutBuffer) se puede determinar en función de la longitud real del búfer de salida devuelto en el parámetro lpcbBytesReturned .
SIO_GET_INTERFACE_LIST_EX no se admite actualmente en Windows.
SIO_GET_QOS (configuración de opcode: O, T==1)
Reservado para uso futuro con sockets. Recupere la estructura de QOS asociada al socket. El búfer de entrada es opcional. Algunos protocolos (por ejemplo, RSVP) permiten usar el búfer de entrada para calificar una solicitud de calidad de servicio. La estructura de QOS se copiará en el búfer de salida. El búfer de salida debe tener un tamaño lo suficientemente grande como para poder contener la estructura completa de QOS . El código de error WSAENOPROTOOPT se indica para los proveedores de servicios que no admiten la calidad del servicio.
Es posible que un remitente no llame a SIO_GET_QOS hasta que el socket esté conectado.
Un receptor puede llamar a SIO_GET_QOS tan pronto como esté enlazado.
SIO_GET_TX_TIMESTAMP
Un IOCTL de socket usado para obtener marcas de tiempo para paquetes transmitidos (TX). Válido solo para sockets de datagramas.
El código de control SIO_GET_TX_TIMESTAMP quita una marca de tiempo de transmisión de la cola de marca de tiempo de transmisión de un socket. Habilite primero la recepción de marca de tiempo mediante el SIO_TIMESTAMPING socket IOCTL. A continuación, recupere tx timestamps by ID mediante una llamada a la función WSAIoctl (o WSPIoctl) con los parámetros siguientes.
Para SIO_GET_TX_TIMESTAMP, la entrada es un identificador de marca de tiempo UINT32 y la salida es un valor de marca de tiempo UINT64 . Si se ejecuta correctamente, la marca de tiempo tx está disponible y se devuelve. Si no hay marcas de tiempo de transmisión disponibles, WSAGetLastError devuelve WSAEWOULDBLOCK.
Nota
No se admiten marcas de tiempo TX al realizar un envío combinado a través de UDP_SEND_MSG_SIZE.
Consulte también marcas de tiempo de Winsock.
SIO_IDEAL_SEND_BACKLOG_CHANGE (configuración de opcode: V, T==0)
Notifica a una aplicación cuando cambia el valor ideal del trabajo pendiente de envío (ISB) para la conexión subyacente.
Al enviar datos a través de una conexión TCP mediante sockets de Windows, es importante mantener una cantidad suficiente de datos pendientes (enviados pero no confirmados todavía) en TCP para lograr el mayor rendimiento. El valor ideal para la cantidad de datos pendientes para lograr el mejor rendimiento para la conexión TCP se denomina tamaño ideal de trabajo pendiente de envío (ISB). El valor de ISB es una función del producto de retraso de ancho de banda de la conexión TCP y la ventana de recepción anunciada del receptor (y en parte la cantidad de congestión en la red).
El valor de ISB por conexión está disponible en la implementación del protocolo TCP en Windows Server 2008, Windows Vista con SP1 y versiones posteriores del sistema operativo. Una aplicación puede usar el SIO_IDEAL_SEND_BACKLOG_CHANGE IOCTL para obtener una notificación cuando el valor de ISB cambia dinámicamente para una conexión.
Para obtener información más detallada, consulte la referencia de SIO_IDEAL_SEND_BACKLOG_CHANGE .
SIO_IDEAL_SEND_BACKLOG_CHANGE se admite en Windows Server 2008, Windows Vista con SP1 y versiones posteriores del sistema operativo.
SIO_IDEAL_SEND_BACKLOG_QUERY (configuración de opcode: O, T==0)
Recupera el valor ideal de trabajo pendiente de envío (ISB) para la conexión subyacente.
Al enviar datos a través de una conexión TCP mediante sockets de Windows, es importante mantener una cantidad suficiente de datos pendientes (enviados pero no confirmados todavía) en TCP para lograr el mayor rendimiento. El valor ideal para la cantidad de datos pendientes para lograr el mejor rendimiento para la conexión TCP se denomina tamaño ideal de trabajo pendiente de envío (ISB). El valor de ISB es una función del producto de retraso de ancho de banda de la conexión TCP y la ventana de recepción anunciada del receptor (y en parte la cantidad de congestión en la red).
El valor de ISB por conexión está disponible en la implementación del protocolo TCP en Windows Server 2008 y versiones posteriores. Una aplicación puede usar el SIO_IDEAL_SEND_BACKLOG_QUERY IOCTL para consultar el valor de ISB de una conexión.
Para obtener información más detallada, consulte la referencia de SIO_IDEAL_SEND_BACKLOG_QUERY .
SIO_IDEAL_SEND_BACKLOG_QUERY se admite en Windows Server 2008, Windows Vista con SP1 y versiones posteriores del sistema operativo.
SIO_KEEPALIVE_VALS (configuración de código de operación: I, T==3)
Habilita o deshabilita la configuración por conexión de la opción keep-alive de TCP que especifica el tiempo de espera y el intervalo de mantenimiento de TCP. Para obtener más información sobre la opción keep-alive, consulte la sección 4.2.3.6 en Requisitos para hosts de Internet: capas de comunicación especificadas en RFC 1122 disponible en el sitio web de IETF. (Este recurso solo puede estar disponible en inglés).
SIO_KEEPALIVE_VALS se puede usar para habilitar o deshabilitar sondeos keep-alive y establecer el tiempo de espera y el intervalo de mantenimiento activo. El tiempo de espera de mantenimiento especifica el tiempo de espera, en milisegundos, sin actividad hasta que se envíe el primer paquete keep-alive. El intervalo keep-alive especifica el intervalo, en milisegundos, entre cuando se envían paquetes keep-alive sucesivos si no se recibe ninguna confirmación.
La opción SO_KEEPALIVE , que es una de las opciones de socket de SOL_SOCKET, también se puede usar para habilitar o deshabilitar el mantenimiento de TCP en una conexión, así como consultar el estado actual de esta opción. Para consultar si TCP keep-alive está habilitado en un socket, se puede llamar a la función getsockopt con la opción SO_KEEPALIVE . Para habilitar o deshabilitar tcp keep-alive, se puede llamar a la función setsockopt con la opción SO_KEEPALIVE . Si TCP keep-alive está habilitado con SO_KEEPALIVE, la configuración de TCP predeterminada se usa para el tiempo de espera de mantenimiento activo y el intervalo, a menos que estos valores se hayan cambiado mediante SIO_KEEPALIVE_VALS.
Para obtener información más detallada, consulte la referencia de SIO_KEEPALIVE_VALS . SIO_KEEPALIVE_VALS se admite en Windows 2000 y versiones posteriores.
SIO_LOOPBACK_FAST_PATH (configuración de código de operación: I, T==3)
Configura un socket TCP para una menor latencia y operaciones más rápidas en la interfaz de bucle invertido. Este IOCTL solicita que la pila TCP/IP use una ruta de acceso rápida especial para las operaciones de bucle invertido en este socket. El SIO_LOOPBACK_FAST_PATH IOCTL solo se puede usar con sockets TCP. Este IOCTL debe usarse en ambos lados de la sesión de bucle invertido. La ruta de acceso rápida de bucle invertido TCP se admite mediante la interfaz de bucle invertido IPv4 o IPv6. De forma predeterminada, SIO_LOOPBACK_FAST_PATH está deshabilitado.
Para obtener información más detallada, consulte la referencia de SIO_LOOPBACK_FAST_PATH . SIO_LOOPBACK_FAST_PATH se admite en Windows 8, Windows Server 2012 y versiones posteriores.
SIO_MULTIPOINT_LOOPBACK (configuración de código de operación: V, T==1)
Controla si los datos enviados por una aplicación en el equipo local (no necesariamente por el mismo socket) de una sesión de multidifusión serán recibidos por un socket unido al grupo de destino de multidifusión en la interfaz de bucle invertido. Un valor true hace que los datos de multidifusión enviados por una aplicación en el equipo local se entreguen a un socket de escucha en la interfaz de bucle invertido. Un valor false impide que los datos de multidifusión enviados por una aplicación en el equipo local se entreguen a un socket de escucha en la interfaz de bucle invertido. De forma predeterminada, SIO_MULTIPOINT_LOOPBACK está habilitado.
SIO_MULTICAST_SCOPE (configuración de código de operación: I, T==1)
Especifica el ámbito en el que se producirán las transmisiones de multidifusión. El ámbito se define como el número de segmentos de red enrutados que se van a cubrir. Un ámbito de cero indicaría que la transmisión de multidifusión no se colocaría en el cable, pero se podría difundir entre sockets dentro del host local. Un valor de ámbito de uno (el valor predeterminado) indica que la transmisión se colocará en el cable, pero no cruzará ningún enrutador. Los valores de ámbito más altos determinan el número de enrutadores que se pueden cruzar. Tenga en cuenta que esto corresponde al parámetro de período de vida (TTL) en multidifusión IP. De forma predeterminada, el ámbito es 1.
SIO_QUERY_RSS_PROCESSOR_INFO (configuración de código de operación: O, T==1)
Consulta la asociación entre un socket y un núcleo de procesador RSS y un nodo NUMA.
El SIO_QUERY_RSS_PROCESSOR_INFO IOCTL devuelve una estructura de SOCKET_PROCESSOR_AFFINITY que contiene el PROCESSOR_NUMBER y el identificador del nodo NUMA. La estructura de PROCESSOR_NUMBER devuelta contiene un número de grupo y un número de procesador relativo dentro del grupo.
Para obtener información más detallada, consulte la referencia de SIO_QUERY_RSS_PROCESSOR_INFO . SIO_QUERY_RSS_PROCESSOR_INFO se admite en Windows 8, Windows Server 2012 y versiones posteriores.
SIO_QUERY_RSS_SCALABILITY_INFO (configuración de código de operación: O, T==3)
Consulta las interfaces de descarga para la funcionalidad de escalado en el lado de recepción (RSS). La estructura de argumentos devuelta para SIO_QUERY_RSS_SCALABILITY_INFO se especifica en la estructura RSS_SCALABILITY_INFO definida en el archivo de encabezado Mstcpip.h . Esta estructura se define de la siguiente manera:
// Scalability info for the transport
typedef struct _RSS_SCALABILITY_INFO {
BOOLEAN RssEnabled;
} RSS_SCALABILITY_INFO, *PRSS_SCALABILITY_INFO;
El valor devuelto en el miembro RssEnabled indica si RSS está habilitado en al menos una interfaz.
Si el búfer de salida no es lo suficientemente grande para la estructura de RSS_SCALABILITY_INFO ( cbOutBuffer es menor que el tamaño de un RSS_SCALABILITY_INFO) o el parámetro lpvOutBuffer es un puntero NULL , SOCKET_ERROR se devuelve como resultado de este IOCTL y WSAGetLastError devuelve WSAEINVAL.
En las redes de alta velocidad en las que residen varias CPU dentro de un único sistema, la capacidad de la pila de protocolos de red para escalar bien en un sistema de varias CPU se impide porque la arquitectura de NDIS 5.1 y versiones anteriores limita el procesamiento del protocolo a una sola CPU. El escalado en el lado de recepción (RSS) resuelve este problema al permitir que la carga de red desde un adaptador de red se equilibre entre varias CPU.
SIO_QUERY_RSS_SCALABILITY_INFO se admite en Windows Vista y versiones posteriores.
SIO_QUERY_TRANSPORT_SETTING (configuración de opcode: I, T==3)
Consulta la configuración de transporte en un socket. La configuración de transporte que se consulta se basa en el TRANSPORT_SETTING_ID pasado en el parámetro lpvInBuffer .
La única configuración de transporte que define actualmente es para la funcionalidad REAL_TIME_NOTIFICATION_CAPABILITY en un socket TCP.
Si el TRANSPORT_SETTING_ID tiene el miembro GUID establecido en REAL_TIME_NOTIFICATION_CAPABILITY, se trata de una solicitud para consultar la configuración de notificación en tiempo real del socket TCP usado con controlChannelTrigger para recibir notificaciones de red en segundo plano en una aplicación de la Tienda Windows. Si la llamada WSAIoctl o WSPIoctl se realiza correctamente, este IOCTL devuelve una estructura de REAL_TIME_NOTIFICATION_SETTING_OUTPUT con el estado actual.
Para obtener información más detallada, consulte la referencia de SIO_QUERY_TRANSPORT_SETTING . SIO_QUERY_TRANSPORT_SETTING se admite en Windows 8, Windows Server 2012 y versiones posteriores.
SIO_QUERY_WFP_ALE_ENDPOINT_HANDLE (configuración de opcode: O, T==3)
Consulta el identificador de punto de conexión de cumplimiento de la capa de aplicación (ALE).
La Plataforma de filtrado de Windows (PMA) admite la inspección y modificación del tráfico de red. En Windows Vista, EL PMA se centra en escenarios en los que la máquina host es el punto de conexión de comunicación. Sin embargo, en Windows Server 2008 hay implementaciones de firewall perimetrales que desean aprovechar la plataforma PMA para inspeccionar y proxy el tráfico de paso a través. El servidor de seguridad y aceleración de Internet (ISA) es un ejemplo de este tipo de dispositivo perimetral.
Hay algunos escenarios de firewall que pueden requerir la capacidad de insertar un paquete entrante en la ruta de acceso de envío asociada a un punto de conexión existente. Debe haber un mecanismo para detectar el identificador de punto de conexión de la capa de transporte asociado al punto de conexión de destino. La aplicación que creó el punto de conexión posee estos puntos de conexión de capa de transporte. Este IOCTL se usa para proporcionar el identificador de socket para la asignación de identificadores de punto de conexión de capa de transporte.
Si el búfer de salida no es lo suficientemente grande como para el identificador del punto de conexión ( cbOutBuffer es menor que el tamaño de un UINT64) o el parámetro lpvOutBuffer es un puntero NULL , SOCKET_ERROR se devuelve como resultado de este IOCTL y WSAGetLastError devuelve WSAEINVAL.
SIO_QUERY_WFP_ALE_ENDPOINT_HANDLE se admite en Windows Vista y versiones posteriores.
SIO_QUERY_WFP_CONNECTION_REDIRECT_CONTEXT (configuración de código de operación: I, T==3)
Consulta el contexto de redireccionamiento de un registro de redireccionamiento usado por un servicio de redirección de la Plataforma de filtrado de Windows (PMA).
El SIO_QUERY_WFP_CONNECTION_REDIRECT_CONTEXT IOCTL se usa para proporcionar un seguimiento de conexiones proxy en conexiones de socket redirigido. Esta característica de PMA facilita el seguimiento de los registros de redirección desde el redireccionamiento inicial de una conexión a la conexión final al destino.
Para obtener información más detallada, consulte la referencia de SIO_QUERY_WFP_CONNECTION_REDIRECT_CONTEXT . SIO_QUERY_WFP_CONNECTION_REDIRECT_CONTEXT se admite en Windows 8, Windows Server 2012 y versiones posteriores.
SIO_QUERY_WFP_CONNECTION_REDIRECT_RECORDS (configuración de código de operación: I, T==3)
Consulta el registro de redireccionamiento de la conexión TCP/IP aceptada para que la use un servicio de redireccionamiento de la Plataforma de filtrado de Windows (PMA).
El SIO_QUERY_WFP_CONNECTION_REDIRECT_RECORDS IOCTL se usa para proporcionar un seguimiento de la conexión proxy en las conexiones de socket redirigidas. Esta característica de PMA facilita el seguimiento de los registros de redirección desde el redireccionamiento inicial de una conexión a la conexión final al destino.
Para obtener información más detallada, consulte la referencia de SIO_QUERY_WFP_CONNECTION_REDIRECT_RECORDS . SIO_QUERY_WFP_CONNECTION_REDIRECT_RECORDS se admite en Windows 8, Windows Server 2012 y versiones posteriores.
SIO_RCVALL (configuración de opcode: I, T==3)
Permite que un socket reciba todos los paquetes IPv4 o IPv6 que pasan a través de una interfaz de red. El identificador de socket pasado a la función WSAIoctl debe ser uno de los siguientes:
- Un socket IPv4 que se creó con la familia de direcciones establecida en AF_INET, el tipo de socket establecido en SOCK_RAW y el protocolo establecido en IPPROTO_IP.
- Un socket IPv6 que se creó con la familia de direcciones establecida en AF_INET6, el tipo de socket establecido en SOCK_RAW y el protocolo establecido en IPPROTO_IPV6.
El socket también debe estar enlazado a una interfaz IPv4 o IPv6 local explícita, lo que significa que no se puede enlazar a INADDR_ANY o in6addr_any.
En Windows Server 2008 y versiones anteriores, la configuración de SIO_RCVALL IOCTL no capturaría los paquetes locales enviados fuera de una interfaz de red. Esto incluía los paquetes recibidos en otra interfaz y reenviaron la interfaz de red especificada para el SIO_RCVALL IOCTL.
En Windows 7 y Windows Server 2008 R2 , esto se cambió para que los paquetes locales enviados fuera de una interfaz de red también se capturen. Esto incluye los paquetes recibidos en otra interfaz y, a continuación, reenvía la interfaz de red enlazada al socket con SIO_RCVALL IOCTL.
Establecer este IOCTL requiere privilegios de administrador en el equipo local.
Esta característica se conoce a veces como modo promiscuo.
Los valores posibles para la opción SIO_RCVALL IOCTL se especifican en la enumeración RCVALL_VALUE definida en el archivo de encabezado Mstcpip.h . Los valores posibles para SIO_RCVALL son los siguientes:
Término | Descripción |
---|---|
RCVALL_OFF |
Deshabilite esta opción para que un socket no reciba todos los paquetes IPv4 o IPv6 de la red. |
RCVALL_ON |
Habilite esta opción para que un socket reciba todos los paquetes IPv4 o IPv6 de la red. Esta opción habilita el modo promiscuo en la tarjeta de interfaz de red (NIC), si la NIC admite el modo promiscuo. En un segmento LAN con un centro de red, una NIC que admita el modo promiscuo capturará todo el tráfico IPv4 o IPv6 en la LAN, incluido el tráfico entre otros equipos del mismo segmento LAN. Todos los paquetes capturados (IPv4 o IPv6, según el socket) se entregarán al socket sin procesar. Esta opción no capturará otros paquetes (paquetes ARP, IPX y NetBEUI, por ejemplo) en la interfaz. Netmon usa el mismo modo para la interfaz de red, pero no usa esta opción para capturar el tráfico. |
RCVALL_SOCKETLEVELONLY |
Esta característica no está implementada actualmente, por lo que establecer esta opción no tiene ningún efecto. |
RCVALL_IPLEVEL |
Habilite esta opción para que un socket IPv4 o IPv6 reciba todos los paquetes en el nivel ip de la red. Esta opción no habilita el modo promiscuo en la tarjeta de interfaz de red. Esta opción solo afecta al procesamiento de paquetes en el nivel de IP. La NIC sigue recibiendo solo paquetes dirigidos a sus direcciones de unidifusión y multidifusión configuradas. Sin embargo, un socket con esta opción habilitada no solo recibirá paquetes dirigidos a direcciones IP específicas, sino que recibirá todos los paquetes IPv4 o IPv6 que recibe la NIC. Esta opción no capturará otros paquetes (paquetes ARP, IPX y NetBEUI, por ejemplo) recibidos en la interfaz. |
Para obtener información más detallada, consulte la referencia de SIO_RCVALL .
SIO_RCVALL se admite en Windows 2000 y versiones posteriores.
SIO_RCVALL_IGMPMCAST (configuración de código de operación: I, T==3)
Permite que un socket reciba todo el tráfico IP de multidifusión IGMP en la red, sin recibir otro tráfico IP de multidifusión. El identificador de socket pasado a la función WSAIoctl debe ser de AF_INET familia de direcciones, SOCK_RAW tipo de socket y protocolo IPPROTO_IGMP. El socket también debe enlazarse a una interfaz local explícita, lo que significa que no se puede enlazar a INADDR_ANY.
Una vez enlazado el socket y el IOCTL establecido, las llamadas a las funciones WSARecv o recv devuelven datagramas IP de multidifusión que pasan por la interfaz especificada. Tenga en cuenta que debe proporcionar un búfer suficientemente grande. Establecer este IOCTL requiere privilegios de administrador en el equipo local.
SIO_RCVALL_IGMPMCAST se admite en Windows 2000 y versiones posteriores.
SIO_RCVALL_MCAST (configuración de código de operación: I, T==3)
Permite que un socket reciba todo el tráfico IP de multidifusión en la red (es decir, todos los paquetes IP destinados a direcciones IP en el intervalo de 224.0.0.0 a 239.255.255.255). El identificador de socket pasado a la función WSAIoctl debe ser de AF_INET familia de direcciones, SOCK_RAW tipo de socket y protocolo IPPROTO_UDP. El socket también debe enlazarse a una interfaz local explícita, lo que significa que no se puede enlazar a INADDR_ANY. El socket debe enlazarse al puerto cero.
Una vez enlazado el socket y el IOCTL establecido, las llamadas a las funciones WSARecv o recv devuelven datagramas IP de multidifusión que pasan por la interfaz especificada. Tenga en cuenta que debe proporcionar un búfer suficientemente grande. Establecer este IOCTL requiere privilegios de administrador en el equipo local.
SIO_RCVALL_MCAST se admite en Windows 2000 y versiones posteriores.
SIO_RELEASE_PORT_RESERVATION (configuración de código de operación: I, T==3)
Libera una reserva en tiempo de ejecución para un bloque de puertos TCP o UDP. La reserva en tiempo de ejecución que se va a liberar debe haberse obtenido del proceso de emisión mediante el SIO_ACQUIRE_PORT_RESERVATION IOCTL.
Para obtener información más detallada, consulte la referencia de SIO_RELEASE_PORT_RESERVATION .
SIO_RELEASE_PORT_RESERVATION se admite en Windows Vista y versiones posteriores del sistema operativo.
SIO_ROUTING_INTERFACE_CHANGE (configuración de código de operación: I, T==1)
Para recibir una notificación de un cambio de interfaz de enrutamiento que se debe usar para llegar a la dirección remota en el búfer de entrada (especificado como una estructura sockaddr ). No se proporcionará información de salida sobre la nueva interfaz de enrutamiento tras la finalización de este IOCTL; la finalización simplemente indica que la interfaz de enrutamiento de un destino determinado ha cambiado y se debe consultar mediante el SIO_ROUTING_INTERFACE_QUERY IOCTL .
Se supone, aunque no es necesario, que la aplicación usa E/S superpuesta para recibir una notificación del cambio de interfaz de enrutamiento mediante la finalización de SIO_ROUTING_INTERFACE_CHANGE solicitud. Como alternativa, si el SIO_ROUTING_INTERFACE_CHANGE IOCTL se emite en un socket sin bloqueo con los parámetros lpOverlapped y lpCompletionRoutine establecidos en NULL), se completará inmediatamente devolviendo y WSAEWOULDBLOCK como un error, y la aplicación puede esperar a que se enrutan los eventos de cambio a través de la llamada a WSAEventSelect o WSAAsyncSelect con FD_ROUTING_INTERFACE_CHANGE bit establecido en la máscara de bits del evento de red.
Se reconoce que la información de enrutamiento permanece estable en la mayoría de los casos para que la aplicación mantenga varias ICTL pendientes para obtener notificaciones sobre todos los destinos en los que está interesado, así como que el proveedor de servicios realice un seguimiento de estas solicitudes de notificación usará una cantidad significativa de recursos del sistema. Esta situación se puede evitar mediante la extensión del significado de los parámetros de entrada y la relajación de los requisitos del proveedor de servicios de la siguiente manera:
- La aplicación puede especificar una dirección comodín específica de la familia de protocolos (igual que la que se usa en la llamada de enlace al solicitar enlazar a cualquier dirección disponible) para solicitar notificaciones de cualquier cambio de enrutamiento. Esto permite a la aplicación mantener solo un SIO_ROUTING_INTERFACE_CHANGE pendiente para todos los sockets y destinos que tiene y, a continuación, usar SIO_ROUTING_INTERFACE_QUERY para obtener la información de enrutamiento real.
- Un proveedor de servicios tiene la opción de omitir la información especificada por la aplicación en el búfer de entrada del SIO_ROUTING_INTERFACE_CHANGE (como si la aplicación especificara una dirección comodín) y completar el SIO_ROUTING_INTERFACE_CHANGE IOCTL o señal FD_ROUTING_INTERFACE_CHANGE evento en caso de cualquier cambio de información de enrutamiento (no solo la ruta al destino especificado en el búfer de entrada).
SIO_ROUTING_INTERFACE_QUERY (configuración de opcode: I, O, T==1)
Para obtener la dirección de la interfaz local (representada como estructura sockaddr ), que se debe usar para enviar a la dirección remota especificada en el búfer de entrada (como sockaddr). Las direcciones de multidifusión remota se pueden enviar en el búfer de entrada para obtener la dirección de la interfaz preferida para la transmisión de multidifusión. En cualquier caso, la aplicación puede usar la dirección de interfaz devuelta en una solicitud bind() posterior.
Tenga en cuenta que las rutas están sujetas a cambios. Por lo tanto, las aplicaciones no pueden confiar en la información devuelta por SIO_ROUTING_INTERFACE_QUERY que sean persistentes. Las aplicaciones pueden registrarse para enrutar las notificaciones de cambios a través del SIO_ROUTING_INTERFACE_CHANGE IOCTL, que proporciona notificaciones a través de E/S superpuestas o un evento de FD_ROUTING_INTERFACE_CHANGE. La siguiente secuencia de acciones se puede usar para garantizar que la aplicación siempre tiene información de interfaz de enrutamiento actual para un destino determinado:
- Problema SIO_ROUTING_INTERFACE_CHANGE IOCTL
- Problema SIO_ROUTING_INTERFACE_QUERY IOCTL
- Siempre que SIO_ROUTING_INTERFACE_CHANGE IOCTL notifica a la aplicación del cambio de enrutamiento (ya sea a través de E/S superpuesta o mediante la señalización FD_ROUTING_INTERFACE_CHANGE evento), se debe repetir toda la secuencia de acciones.
Si el búfer de salida no es lo suficientemente grande como para contener la dirección de la interfaz, SOCKET_ERROR se devuelve como resultado de este IOCTL y WSAGetLastError devuelve WSAEFAULT. El tamaño necesario del búfer de salida se devolverá en lpcbBytesReturned en este caso. Tenga en cuenta que el código de error WSAEFAULT también se devuelve si el parámetro lpvInBuffer, lpvOutBuffer o lpcbBytesReturned no está totalmente incluido en una parte válida del espacio de direcciones del usuario.
Si no se puede acceder a la dirección de destino especificada en el búfer de entrada a través de ninguna de las interfaces disponibles, SOCKET_ERROR se devuelve como resultado de este IOCTL y WSAGetLastError devuelve WSAENETUNREACH o incluso WSAENETDOWN si se pierde toda la conectividad de red.
SIO_SET_COMPATIBILITY_MODE (configuración de opcode: I, T==3)
Solicita cómo la pila de redes debe controlar determinados comportamientos para los que la forma predeterminada de controlar el comportamiento puede diferir en todas las versiones de Windows. La estructura de argumentos para SIO_SET_COMPATIBILITY_MODE se especifica en la estructura de WSA_COMPATIBILITY_MODE definida en el archivo de encabezado Mswsockdef.h . Esta estructura se define de la siguiente manera:
/* Argument structure for SIO_SET_COMPATIBILITY_MODE */
typedef struct _WSA_COMPATIBILITY_MODE {
WSA_COMPATIBILITY_BEHAVIOR_ID BehaviorId;
ULONG TargetOsVersion;
} WSA_COMPATIBILITY_MODE, *PWSA_COMPATIBILITY_MODE;
El valor especificado en el miembro BehaviorId indica el comportamiento solicitado. El valor especificado en el miembro TargetOsVersion indica la versión de Windows que se solicita para el comportamiento.
El miembro BehaviorId puede ser uno de los valores del tipo de enumeración WSA_COMPATIBILITY_BEHAVIOR_ID definido en el archivo de encabezado Mswsockdef.h . Los valores posibles para el miembro BehaviorId son los siguientes.
Término | Descripción |
---|---|
WsaBehaviorAll |
Esto equivale a solicitar todos los posibles comportamientos compatibles definidos para WSA_COMPATIBILITY_BEHAVIOR_ID. |
WsaBehaviorReceiveBuffering |
Cuando el miembro TargetOsVersion se establece en un valor para Windows Vista o posterior, se permiten reducciones en el tamaño del búfer de recepción TCP en este socket mediante la opción de socket SO_RCVBUF incluso después de que se haya establecido una conexión TCP. Cuando el miembro TargetOsVersion se establece en un valor anterior a Windows Vista, no se permiten reducciones en el tamaño del búfer de recepción TCP en este socket mediante la opción de socket SO_RCVBUF después del establecimiento de la conexión. |
WsaBehaviorAutoTuning |
Cuando el miembro TargetOsVersion se establece en un valor para Windows Vista o posterior, se habilita el ajuste automático de la ventana de recepción y el factor de escala de ventanas TCP se reduce a 2 del valor predeterminado de 8. Cuando TargetOsVersion se establece en un valor anterior a Windows Vista, se deshabilita el ajuste automático de la ventana de recepción. La opción de escalado de ventanas TCP también está deshabilitada y el tamaño máximo real de la ventana de recepción está limitado a 65 535 bytes. La opción de escalado de ventanas TCP no se puede negociar en la conexión incluso si se llamó a la opción de socket SO_RCVBUF en este socket especificando un valor superior a 65 535 bytes antes de establecer la conexión. |
Para obtener información más detallada, consulte la referencia de SIO_SET_COMPATIBILITY_MODE .
SIO_SET_COMPATIBILITY_MODE se admite en Windows Vista y versiones posteriores.
SIO_SET_GROUP_QOS (configuración de opcode: I, T==1)
Reservado.
SIO_SET_PRIORITY_HINT (configuración de opcode: I, T==3)
Proporciona una sugerencia al protocolo de transporte subyacente para tratar el tráfico en este socket con una prioridad específica. LpvInBuffer debe apuntar a una variable de tipo PRIORITY_HINT con cbInBuffer establecido en sizeof(PRIORITY_HINT). Los parámetros lpvOutBuffer y cbOutBuffer deben ser NULL y 0, respectivamente. La implementación tcp de Microsoft Windows admite este IOCTL a partir de Windows 10, versión 1809 (10.0; Compilación 17763) y versiones posteriores como se indica a continuación: cuando el valor de prioridad solicitado se establece en IoPriorityHintVeryLow, TCP usa una versión modificada del algoritmo LEDBAT (definido en RFC 6817) para controlar la tasa de tráfico saliente en el socket. El tráfico entrante no se ve afectado por este IOCTL. LEDBAT es un algoritmo scavenger y su objetivo es mantener baja la latencia y evitar cualquier efecto adverso en el tráfico de prioridad normal al salir del camino cuando el tráfico de prioridad normal está presente.
Consulte también RFC 6817.
SIO_SET_PRIORITY_HINT se admite en Windows 10, versión 1809 (10.0; Compilación 17763) y versiones posteriores.
SIO_SET_QOS (configuración de código de operación: I, T==1)
Asocie la estructura de QOS especificada al socket. No se requiere ningún búfer de salida, la estructura de QOS se obtendrá del búfer de entrada. El código de error WSAENOPROTOOPT se indica para los proveedores de servicios que no admiten la calidad del servicio.
SIO_TCP_INITIAL_RTO (configuración de código de operación: I, T==3)
Controla las características de retransmisión iniciales (SYN/SYN+ACK) de un socket TCP mediante la configuración de parámetros de tiempo de espera de retransmisión inicial (RTO). Los parámetros de configuración se especifican en una estructura de TCP_INITIAL_RTO_PARAMETERS .
Para obtener información más detallada, consulte la referencia de SIO_TCP_INITIAL_RTO . SIO_TCP_INITIAL_RTO se admite en Windows 8, Windows Server 2012 y versiones posteriores.
SIO_TIMESTAMPING
Un IOCTL de socket utilizado para configurar la recepción de marcas de tiempo de transmisión/recepción de sockets. Válido solo para sockets de datagramas. El tipo de entrada de SIO_TIMESTAMPING es la estructura TIMESTAMPING_CONFIG .
Consulte también marcas de tiempo de Winsock.
SIO_TRANSLATE_HANDLE (configuración de opcode: I, O, T==1)
Para obtener un identificador correspondiente para los sockets que son válidos en el contexto de una interfaz complementaria (por ejemplo, TH_NETDEV y TH_TAPI). Una constante de manifiesto que identifica la interfaz complementaria junto con cualquier otro parámetro necesario se especifica en el búfer de entrada. El identificador correspondiente estará disponible en el búfer de salida tras la finalización de esta función. Consulte la sección correspondiente de los anexos de Winsock para obtener detalles específicos de una interfaz complementaria determinada. El código de error WSAENOPROTOOPT se indica para los proveedores de servicios que no admiten este IOCTL para la interfaz complementaria especificada. Este IOCTL recupera el identificador asociado mediante SIO_TRANSLATE_HANDLE.
Se recomienda usar el Modelo de objetos componentes (COM) en lugar de este IOCTL para detectar y realizar un seguimiento de otras interfaces que podrían ser compatibles con un socket. Este IOCTL está presente para la compatibilidad con versiones anteriores con sistemas en los que COM no está disponible o no se puede usar por alguna otra razón.
SIO_UDP_CONNRESET (configuración de opcode: I, T==3)
Windows XP: Controla si se notifican mensajes de PORT_UNREACHABLE UDP. Establézcalo en TRUE para habilitar los informes. Establézcalo en FALSE para deshabilitar los informes.
SIO_SET_WFP_CONNECTION_REDIRECT_RECORDS (configuración de código de operación: I, T==3)
Establece el registro de redireccionamiento en el nuevo socket TCP que se usa para conectarse al destino final para que lo use un servicio de redireccionamiento de la Plataforma de filtrado de Windows (PMA).
El SIO_SET_WFP_CONNECTION_REDIRECT_RECORDS IOCTL se usa como parte del seguimiento de conexiones proxy en conexiones de socket redirigido. Esta característica de PMA facilita el seguimiento de los registros de redirección desde el redireccionamiento inicial de una conexión a la conexión final al destino.
Para obtener información más detallada, consulte la referencia de SIO_SET_WFP_CONNECTION_REDIRECT_RECORDS . SIO_SET_WFP_CONNECTION_REDIRECT_RECORDS se admite en Windows 8, Windows Server 2012 y versiones posteriores.
SIO_TCP_INFO (configuración de código de operación: I, O, T==3)
Recupera las estadísticas tcp de un socket. Las estadísticas TCP se proporcionan en una estructura de TCP_INFO_v0 .
A diferencia de la recuperación de estadísticas TCP con la función GetPerTcpConnectionEStats , la recuperación de estadísticas TCP con este código de control no requiere que el código de usuario cargue, almacene y filtre la tabla de conexiones TCP y no requiera privilegios elevados para su uso.
Para obtener más información, consulte SIO_TCP_INFO. SIO_TCP_INFO se admite en Windows 10, versión 1703, Windows Server 2016 y versiones posteriores.
Observaciones
Los Ioctl de Winsock se definen en varios archivos de encabezado diferentes. Estos incluyen el archivo de encabezado Winsock2.h, Mswsock.h y Mstcpip.h .
En el Kit de desarrollo de software (SDK) de Microsoft Windows publicado para Windows Vista y versiones posteriores, la organización de archivos de encabezado ha cambiado y también se definen varios Ioctl de Winsock en los archivos de encabezado Ws2def.h, Ws2ipdef.h y Mswsockdef.h . El archivo de encabezado Ws2def.h se incluye automáticamente en el archivo de encabezado Winsock2.h . El archivo de encabezado Ws2ipdef.h se incluye automáticamente en el archivo de encabezado Ws2tcpip.h . El archivo de encabezado Mswsockdef.h se incluye automáticamente en el archivo de encabezado Mswsockdef.h .
Requisitos
Requisito | Value |
---|---|
Encabezado |
|