Winsock

En informática, la API de Windows Sockets (WSA), más tarde abreviada como Winsock, es una interfaz de programación de aplicaciones (API) que define cómo el software de aplicación de red de Windows debe acceder a los servicios de red, especialmente TCP/IP. Define una interfaz estándar entre una aplicación de cliente TCP/IP de Windows (como un cliente FTP o un navegador web) y la pila de protocolo TCP/IP subyacente. La nomenclatura se basa en la API de sockets de Berkeley utilizada en BSD para las comunicaciones entre programas.

Antecedentes

Los primeros sistemas operativos de Microsoft, tanto MS-DOS como Microsoft Windows, ofrecían una capacidad de red limitada, principalmente basada en NetBIOS. En particular, Microsoft no ofreció soporte para la pila de protocolos TCP/IP en ese momento. Varios grupos universitarios y proveedores comerciales, incluido el grupo PC/IP del MIT, FTP Software, Sun Microsystems, Ungermann-Bass y Excelan, introdujeron productos TCP/IP para MS-DOS, a menudo como parte de un paquete de hardware/software.. Cuando se lanzó Windows 2.0, estos proveedores se unieron a otros como Distinct y NetManage para ofrecer TCP/IP para Windows.

El inconveniente al que se enfrentaban todos estos proveedores era que cada uno de ellos utilizaba su propia API (interfaz de programación de aplicaciones). Sin un único modelo de programación estándar, era difícil persuadir a los desarrolladores de software independientes para que crearan aplicaciones de red que funcionaran con la implementación subyacente de TCP/IP de cualquier proveedor. Agregue a esto el hecho de que los usuarios finales desconfiaban de quedarse encerrados en un solo proveedor y quedó claro que se necesitaba cierta estandarización.

El proyecto Windows Sockets tuvo su origen en una sesión de Birds Of A Feather celebrada en Interop '91 en San José el 10 de octubre de 1991. Se basa en especificaciones de socket creadas por NetManage y que puso a disposición del público. en esta reunión. En ese momento, el socket NetManage era el único producto de subprocesos múltiples 100% basado en DLL para Windows 3.0 disponible. La primera edición de la especificación fue escrita por Martin Hall, Mark Towfiq de Microdyne (más tarde Sun Microsystems), Geoff Arnold de Sun Microsystems y Henry Sanders y J Allard de Microsoft, con la ayuda de muchos otros. Hubo cierta discusión sobre la mejor manera de abordar los derechos de autor, la propiedad intelectual y los posibles problemas antimonopolio, y se consideró trabajar a través del IETF o establecer una fundación sin fines de lucro. Al final, se decidió que la especificación sería registrada por los cinco autores como individuos (no afiliados).

Todos los desarrolladores participantes se resistieron durante mucho tiempo a acortar el nombre a Winsock simple, ya que había mucha confusión entre los usuarios entre la API y el archivo de biblioteca DLL (winsock.dll) que solo exponía las interfaces WSA comunes a las aplicaciones. sobre eso. Los usuarios comúnmente creerían que solo asegurarse de que el archivo DLL esté presente en un sistema proporcionaría soporte completo para el protocolo TCP/IP.

Tecnología

La especificación API de Windows Sockets define dos interfaces: la API utilizada por los desarrolladores de aplicaciones y la SPI, que proporciona un medio para que los desarrolladores de software de red agreguen nuevos módulos de protocolo al sistema. Cada interfaz representa un contrato. La API garantiza que una aplicación conforme funcionará correctamente con una implementación de protocolo conforme de cualquier proveedor de software de red. El contrato SPI garantiza que se puede agregar un módulo de protocolo conforme a Windows y, por lo tanto, podrá ser utilizado por una aplicación compatible con API. Aunque estos contratos eran importantes cuando se lanzó por primera vez Windows Sockets, dado que los entornos de red requerían soporte multiprotocolo (ver arriba), ahora son solo de interés académico. En la versión 2.0 de la API de Windows Sockets se incluyen funciones para usar IPX/SPX, aunque el protocolo ya estaba casi obsoleto en el momento en que se envió WSA 2.0. Microsoft ha enviado la pila de protocolos TCP/IP con todas las versiones recientes de Windows y no existen alternativas independientes significativas. Tampoco ha habido un interés significativo en implementar protocolos distintos a TCP/IP.

El código y el diseño de Windows Sockets se basan en sockets BSD, pero proporciona funcionalidad adicional para permitir que la API cumpla con el modelo de programación normal de Windows. La API de Windows Sockets cubría casi todas las características de la API de sockets BSD, pero había algunos obstáculos inevitables que surgían principalmente de las diferencias fundamentales entre Windows y Unix (aunque Windows Sockets difería menos de los sockets BSD que estos últimos de STREAMS). Todas las llamadas a funciones en la API comienzan con el nombre WSA, p. WSASend() para enviar datos en un socket conectado.

Sin embargo, un objetivo de diseño de Windows Sockets era que fuera relativamente fácil para los desarrolladores migrar aplicaciones basadas en sockets de Unix a Windows. No se consideró suficiente crear una API que solo fuera útil para los programas de Windows recién escritos. Por esta razón, Windows Sockets incluye una serie de elementos que fueron diseñados para facilitar la migración. Por ejemplo, las aplicaciones de Unix pudieron usar la misma variable errno para registrar tanto los errores de red como los errores detectados dentro de las funciones estándar de la biblioteca C. Dado que esto no era posible en Windows, Windows Sockets introdujo una función dedicada, WSAGetLastError(), para recuperar información de errores. Dichos mecanismos fueron útiles, pero la portabilidad de aplicaciones siguió siendo extremadamente compleja. Muchas aplicaciones TCP/IP originales se habían implementado mediante el uso de características del sistema específicas de Unix, como pseudo terminales y la llamada al sistema de bifurcación, y la reproducción de dicha funcionalidad en Windows era problemática. En un tiempo relativamente corto, la migración dio paso al desarrollo de aplicaciones dedicadas de Windows.

Especificaciones

• La versión 1.0 (junio de 1992) definió la operación básica de Winsock. Se mantuvo muy cerca de la interfaz existente de las tomas de Berkeley para simplificar el porteo de las aplicaciones existentes. Se agregaron algunas extensiones específicas de Windows, principalmente para operaciones asincrónicas con notificaciones basadas en mensajes.

Aunque el documento no limitó el apoyo a TCP/IP, TCP y UDP fueron los únicos protocolos explícitamente mencionados. La mayoría de los proveedores sólo entregaron soporte TCP/IP, aunque Winsock de DEC también incluía soporte de DECNet.

• En la versión 1.1 (enero de 1993) se hicieron muchas correcciones y aclaraciones menores de la especificación. El cambio más significativo fue la inclusión de la gethostname() función.
• Winsock 2 era una extensión compatible atrasada de Winsock 1.1. Añadió apoyo para la resolución de nombres dependientes de protocolos, operaciones asincrónicas con notificaciones basadas en eventos y rutinas de terminación, implementaciones de protocolos en capas, multicasting y calidad de servicio. También formalizó el soporte para múltiples protocolos, incluyendo IPX/SPX y DECnet. La nueva especificación permitió que las tomas de corriente se compartieran opcionalmente entre los procesos, las solicitudes de conexión entrantes fueran aceptadas condicionalmente y ciertas operaciones se realizaran en grupos de tomas en lugar de enchufes individuales. Aunque la nueva especificación difiere sustancialmente de Winsock 1, proporcionó compatibilidad de nivel fuente y binario con la API Winsock 1.1. Una de las adiciones menos conocidas fue la interfaz de proveedor de servicios (SPI) API y proveedores de servicios de capa.
• Las versiones 2.0.x (mayo de 1994 en adelante) tenían un proyecto de estatuto interno y no se anunciaron como normas públicas.
• La versión 2.1.0 (enero de 1996) fue la primera publicación pública de la especificación Winsock 2.
• En la versión 2.2.0 (mayo de 1996) se incluyeron muchas correcciones menores, aclaraciones y recomendaciones sobre el uso. También fue la primera versión para eliminar el soporte para aplicaciones de Windows de 16 bits.
• La versión 2.2.1 (mayo de 1997) y la versión 2.2.2 (agosto de 1997) introdujeron mejoras de funcionalidad menores. Se agregaron mecanismos para solicitar y recibir notificación de cambios en la configuración de redes y sistemas.
• La vista técnica IPv6 para Windows 2000 (diciembre de 2000) vio la primera implementación de RFC 2553 (marzo de 1999, más tarde obsoleto por RFC 3493), una API independiente de protocolo para la resolución de nombre, que se convertiría en parte de Winsock en Windows XP.

Actualizaciones en Windows 8

Windows 8 incluye el "RIO" (IO registrado) extensiones para Winsock. Estas extensiones están diseñadas para reducir la sobrecarga de la transición del usuario al modo kernel para la ruta de datos de red y la ruta de notificación, pero usan el resto de la pila TCP y UDP normal de Windows (y usa las tarjetas de red existentes). La ruta de configuración (por ejemplo, la función "conectar") no cambia con respecto a la ruta normal de Winsock.

Implementaciones

Implementaciones de Microsoft

• Microsoft no proporcionó una implementación de Winsock 1.0.
• Versión 1.1 de Winsock fue suministrado en un paquete adicional (llamado Wolverine) para Windows para grupos de trabajo (código llamado Snowball). Fue un componente integral de Windows 95 y Windows NT de las versiones 3.5 y en adelante (la versión inicial disponible comercialmente de Windows NT, versión 3.1, incluía sólo una implementación patentada y bastante incompleta de TCP/IP basada en la API de sistema de UNIX del sistema V "STREAMS".
• La versión 2.1 de Winsock fue suministrada en un paquete add-on para Windows 95. Fue un componente integral de Windows 98, Windows NT 4.0, y todas las versiones posteriores de Windows. (Microsoft no proporcionó implementaciones de Winsock 2 para Windows 3.x o Windows NT 3.x.)
• Las versiones recientes de Winsock 2.x han sido entregadas con nuevas versiones de Windows o como parte de paquetes de servicio.
• Winsock 2 es extensible por un mecanismo conocido como proveedor de servicios de capa (LSP). Winsock Los LSP están disponibles para una amplia gama de propósitos útiles, incluyendo controles parentales de Internet, filtración de contenidos web, QoS etc. El orden de capa de todos los proveedores se mantiene en el catálogo Winsock. En versiones anteriores de Windows, la eliminación de un buggy LSP podría resultar en la corrupción del catálogo Winsock en el registro, lo que podría dar lugar a una pérdida de toda la conectividad de red. Winsock en Windows XP Service Pack 2, Windows Server 2003 Service Pack 1 y todos los sistemas operativos Windows posteriores tienen la capacidad de auto-sanar después de que un usuario desinstale tal LSP.

Otras implementaciones

• Entre los otros proveedores que ofrecen pilas TCP/IP compatibles con Winsock y UDP/IP (alfabéticamente) 3Com, Beame & Whiteside, DEC, Distinct, FTP Software, Frontier, IBM, Microdyne, NetManage, Novell, Sun Microsystems y Trumpet Software International.
• Trumpet Winsock de Peter Tattam fue una de las pocas implementaciones Winsock 1.0 que podrían instalarse bajo Windows 3.0, que no tenían apoyo incorporado para Winsock. Trumpet también fue la implementación de shareware más popular de Winsock para Windows 3.x. Trumpet Winsock 5.0 está disponible para Windows 95/98 y Windows NT e incluye una pila IPv6 compatible con Winsock 1.1 para estos sistemas operativos.
• El proyecto Wine contiene una fuente y una implementación binaria compatible de Winsock en la parte superior de la API de tomas BSD.