Función WPUModifyIFSHandle (ws2spi.h)

Artículo
03/13/2024

La función WPUModifyIFSHandle recibe un identificador IFS modificado (posiblemente) de Ws2_32.dll.

Sintaxis

SOCKET WPUModifyIFSHandle(
  [in]  DWORD  dwCatalogEntryId,
  [in]  SOCKET ProposedHandle,
  [out] LPINT  lpErrno
);

Parámetros

[in] dwCatalogEntryId

Descriptor que identifica al proveedor de servicios de llamada.

[in] ProposedHandle

Identificador IFS asignado por el proveedor.

[out] lpErrno

Puntero al código de error.

Valor devuelto

Si no se produce ningún error, WPUModifyIFSHandle devuelve el identificador de socket modificado. De lo contrario, devuelve INVALID_SOCKET y hay disponible un código de error específico en lpErrno.

Código de error	Significado
WSAEINVAL	El identificador propuesto no es válido.

Comentarios

El controlador WPUModifyIFSHandle permite que el WS2_32.dll optimice sus operaciones internas devolviendo una versión posiblemente modificada del identificador IFS proporcionado. Se garantiza que el identificador devuelto sea indistinguible del identificador propuesto en lo que respecta al sistema operativo. Los proveedores IFS deben llamar a esta función antes de devolver cualquier descriptor de socket recién creado a un proveedor de servicios. El proveedor de servicios solo usará el identificador modificado para cualquier operación de socket posterior. Esta rutina solo la usan los proveedores IFS cuyos descriptores de socket son identificadores IFS reales.

**Consideraciones del proveedor de servicios superpuestas**

Este procedimiento también puede ser utilizado por un proveedor en capas que se superpone a un proveedor IFS base y quiere exponer los identificadores de socket del proveedor base como propios en lugar de crearlos con una llamada WPUCreateSocketHandle . Un proveedor en capas que desea "pasar por" los identificadores de socket IFS que recibe de la capa siguiente de la cadena puede llamar a WPUModifyIFSHandle, pasando su propio identificador de entrada de catálogo como dwCatalogEntryId. Esto informa al archivo DLL de Windows Sockets de que esta capa, y no la siguiente, debe ser el destino de las llamadas SPI que implican ese identificador de socket.

Hay varias limitaciones que debe observar un proveedor por capas si adopta este enfoque.

El proveedor debe exponer los puntos de entrada del proveedor base para LPWSPSend y LPWSPRecv en la tabla de distribución de procedimientos que devuelve en el momento de WSPStartup para asegurarse de que el acceso del cliente SPI de Windows Sockets a estas funciones sea lo más eficaz posible.
El proveedor no puede confiar en sus funciones LPWSPSend y LPWSPRecv que se invocan para todas las E/S, especialmente en el caso de las funciones del sistema de E/S ReadFile y WriteFile. Estas funciones omitirían el proveedor en capas e invocarían la implementación del proveedor IFS base directamente incluso si el proveedor superpuesta coloca sus propios puntos de entrada para estas funciones en la tabla de distribución de procedimientos.
El proveedor no puede confiar en ninguna capacidad para procesar E/S superpuesta mediante LPWSPSend, LPWSPSendTo, LPWSPRecv, LPWSPRecvFrom o LPWSPIoctl. La notificación posterior al procesamiento puede producirse a través de los puertos de finalización y omitir el proveedor por capas por completo. Un proveedor en capas no tiene ninguna manera de determinar que se usó un puerto de finalización o determinar qué puerto es. El proveedor superpuesta no tiene forma de insertarse en la secuencia de notificaciones.
El proveedor debe pasar todas las solicitudes de E/S superpuestas directamente al proveedor base mediante los parámetros superpuestos originales (por ejemplo, la estructura WSAOVERLAPPED y el puntero de rutina de finalización). El proveedor debe exponer el punto de entrada del proveedor base para WSPGetOverlappedResult. Dado que algunas solicitudes de E/S superpuestas pueden omitir completamente el proveedor en capas, el proveedor en capas no puede marcar de forma confiable las estructuras WSAOVERLAPPED para determinar cuáles pueden notificar los resultados y cuáles tendrían que pasarse al WSPGetOverlappedResult del proveedor subyacente. Esto significa eficazmente que LPWSPIoctl debe ser una operación de paso a través al proveedor subyacente.

Requisitos

Requisito	Value
Cliente mínimo compatible	Windows 2000 Professional [solo aplicaciones de escritorio]
Servidor mínimo compatible	Windows 2000 Server [solo aplicaciones de escritorio]
Plataforma de destino	Windows
Encabezado	ws2spi.h