Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
El Ws2_32.dll carga el archivo DLL de interfaz del proveedor de servicios en el sistema mediante los mecanismos de carga de la biblioteca dinámica estándar de Microsoft Windows e inicializa mediante una llamada a WSPStartup. Normalmente, esto se desencadena mediante una aplicación que llama a socket o WSASocket para crear un nuevo socket que se asociará a un proveedor de servicios cuyo archivo DLL de interfaz no está cargado actualmente en memoria. El Ws2_32.dll almacena la ruta de acceso a la DLL de interfaz de cada proveedor de servicios en el momento en que se instala el proveedor de servicios. Consulte funciones de instalación y configuración para obtener más información.
Con el tiempo, pueden existir diferentes versiones para los archivos DLL, aplicaciones y proveedores de servicios de Winsock. Las nuevas versiones pueden definir nuevas características y nuevos parámetros para estructuras de datos y parámetros de bits, etc. Por lo tanto, los números de versión indican cómo interpretar varias estructuras de datos.
Para permitir una combinación óptima y coincidencia de diferentes versiones de aplicaciones, versiones del propio Ws2_32.dll y versiones de proveedores de servicios por diferentes proveedores, el SPI proporciona un mecanismo de negociación de versiones para su uso entre el Ws2_32.dll y los proveedores de servicios. Esta negociación de versiones se controla mediante WSPStartup. Básicamente, el Ws2_32.dll pasa al proveedor de servicios los números de versión más altos con los que es compatible. El proveedor de servicios lo compara con su propio intervalo de números de versión admitidos. Si estos intervalos se superponen, el proveedor de servicios devuelve un valor dentro de la parte superpuesta del intervalo como resultado de la negociación. Normalmente, debe ser el valor más alto posible. Si los intervalos no se superponen, las dos partes son incompatibles y la función devuelve un error.
WSPStartup deben llamarse al menos una vez por cada proceso de cliente y pueden llamarse varias veces por Ws2_32.dll u otras entidades. Se debe llamar a unWSPCleanup coincidente para cada llamada WSPStartup correcta. El proveedor de servicios debe mantener un recuento de referencias por proceso. En cada llamada WSPStartup, el autor de la llamada puede especificar cualquier número de versión compatible con el archivo DLL de SP.
Un proveedor de servicios debe almacenar el puntero a la tabla de distribución de llamadas ascendentes del cliente que se recibe como un parámetro WSPStartup por proceso. Si un proceso determinado llama a WSPStartup varias veces, el proveedor de servicios debe usar solo el puntero de tabla de distribución proporcionado más recientemente.
Como parte del proceso de inicialización del proveedor de servicios El Ws2_32.dll recupera la tabla de distribución del proveedor de servicios a través del parámetro lpProcTable para obtener puntos de entrada al resto de las funciones SPI especificadas en este documento.
El uso de una tabla de distribución (en lugar de los mecanismos de DLL habituales para acceder a los puntos de entrada) sirve para dos propósitos:
- Es más conveniente para el Ws2_32.dll, ya que se puede realizar una sola llamada para detectar todo el conjunto de puntos de entrada.
- Permite que los proveedores de servicios en capas formados en cadenas de protocolo funcionen de forma más eficaz.
Inicialización de cadenas de protocolo
En el momento en que se instala la estructura de WSAPROTOCOL_INFO para una cadena de protocolos, también se especifica la ruta de acceso al primer proveedor en capas de la cadena. Cuando se inicializa una cadena de protocolos, el Ws2_32.dll usa esta ruta de acceso para cargar el archivo DLL del proveedor y, a continuación, invoca WSPStartup. Dado que WSPStartup incluye un puntero a la estructura WSAPROTOCOL_INFO de la cadena como uno de sus parámetros, los proveedores en capas pueden determinar en qué tipo de cadena se inicializan y la identidad de la siguiente capa inferior de la cadena en la cadena. A continuación, un proveedor en capas cargaría a su vez el siguiente proveedor de protocolos en la cadena e inicializaría con una llamada a WSPStartup, etc. Cada vez que la siguiente capa inferior es otro proveedor en capas, se debe hacer referencia a la estructura WSAPROTOCOL_INFO de la cadena en la llamada WSPStartup. Cuando la siguiente capa inferior es un protocolo base (que significa el final de la cadena), la estructura WSAPROTOCOL_INFO de la cadena ya no se propaga hacia abajo. En su lugar, la capa actual debe hacer referencia a una estructura de WSAPROTOCOL_INFO que corresponda al protocolo que debe usar el proveedor base. Por lo tanto, el proveedor base no tiene ninguna noción de estar involucrado en una cadena de protocolos.
La tabla de distribución proporcionada por cualquier proveedor en capas determinada duplicará, en muchos casos, los puntos de entrada de un proveedor subyacente. El proveedor en capas solo insertaría sus propios puntos de entrada para las funciones en las que debía participar directamente. Sin embargo, tenga en cuenta que es imperativo que un proveedor en capas no modifique el contenido de la tabla upcall que recibió al llamar a WSPStartup en la siguiente capa inferior de una cadena de protocolos. Estas llamadas ascendentes deben realizarse directamente en el archivo DLL de Windows Sockets 2.