Calcetín Winsock

This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Winsock" – news · newspapers · books · scholar · JSTOR (July 2010) (Learn how and when to remove this message)

En informática , la API de Windows Sockets ( WSA ), posteriormente 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 cliente TCP/IP de Windows (como un cliente FTP o un navegador web ) y la pila de protocolos TCP/IP subyacente . La nomenclatura se basa en la API de sockets de Berkeley utilizada en BSD para las comunicaciones entre programas.

Los primeros sistemas operativos de Microsoft, tanto MS-DOS como Microsoft Windows, ofrecían una capacidad de red limitada, basada principalmente en NetBIOS . En particular, Microsoft no ofrecía 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 , a estos proveedores se unieron 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 modelo de programación estándar único, era difícil convencer a los desarrolladores de software independientes para que crearan aplicaciones de red que funcionaran con la implementación TCP/IP subyacente de cualquier proveedor. Si a esto le añadimos el hecho de que los usuarios finales temían quedar limitados a un único proveedor, quedó claro que era necesaria 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. ^[1] Se basa en especificaciones de socket creadas por NetManage y que se pusieron en el dominio público en esta reunión. En ese momento, el socket de NetManage era el único producto multiproceso basado en 100% 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. ^{[ cita requerida ]} Hubo cierta discusión sobre la mejor manera de abordar los problemas de derechos de autor, propiedad intelectual y 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 simplemente estaría protegida por derechos de autor de los cinco autores como individuos (no afiliados).

Todos los desarrolladores participantes se resistieron a acortar el nombre a Winsock durante mucho tiempo, ^{[ cita requerida ]} ya que había mucha confusión entre los usuarios entre la API y el archivo de la biblioteca DLL (winsock.dll) que solo exponía las interfaces comunes de WSA a las aplicaciones superiores. Los usuarios creían comúnmente que solo asegurarse de que el archivo DLL estuviera presente en un sistema proporcionaría soporte completo para el protocolo TCP/IP. ^{[ cita requerida ]}

La especificación de la 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 pueda agregar un módulo de protocolo conforme a Windows y, por lo tanto, será utilizable por una aplicación compatible con la API. Aunque estos contratos fueron importantes cuando se lanzó por primera vez Windows Sockets, dado que los entornos de red requerían compatibilidad con múltiples protocolos (ver más arriba), ahora solo tienen 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 prácticamente obsoleto en el momento en que se lanzó 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 de TCP/IP.

El código y el diseño de Windows Sockets se basan en los sockets BSD , pero proporciona una funcionalidad adicional para permitir que la API cumpla con el modelo de programación regular 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 se diferenciaba menos de los sockets BSD que estos últimos de STREAMS ). Todas las llamadas a funciones en la API comienzan con el apodo WSA , por ejemplo, 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 portar aplicaciones basadas en sockets de Unix a Windows. No se consideró suficiente crear una API que solo fuera útil para programas Windows recién escritos. Por esta razón, Windows Sockets incluyó una serie de elementos que fueron diseñados para facilitar la portabilidad. Por ejemplo, las aplicaciones de Unix podían usar la misma variable errno para registrar errores de red y errores detectados dentro de las funciones de la biblioteca estándar de C. Como esto no era posible en Windows, Windows Sockets introdujo una función dedicada, WSAGetLastError() , para recuperar información de errores. Estos mecanismos fueron útiles, pero la portabilidad de aplicaciones siguió siendo extremadamente compleja. Muchas aplicaciones TCP/IP originales se habían implementado utilizando características del sistema específicas de Unix , como pseudoterminales y la llamada al sistema fork , y reproducir dicha funcionalidad en Windows era problemático. En un tiempo relativamente corto, la portabilidad dio paso al desarrollo de aplicaciones dedicadas de Windows.

• La versión 1.0 (junio de 1992) definió el funcionamiento básico de Winsock. Se mantuvo muy similar a la interfaz existente de los sockets Berkeley para simplificar la portabilidad 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 limitaba la compatibilidad a TCP/IP, TCP y UDP eran los únicos protocolos mencionados explícitamente. La mayoría de los proveedores solo ofrecían compatibilidad con TCP/IP, aunque Winsock de DEC también incluía compatibilidad con DECNet .

• La versión 1.1 (enero de 1993) introdujo muchas correcciones y aclaraciones menores a la especificación. El cambio más significativo fue la inclusión de la función gethostname() .
• Winsock 2 fue una extensión compatible con versiones anteriores de Winsock 1.1. Añadió compatibilidad con resolución de nombres independiente del protocolo, operaciones asincrónicas con notificaciones basadas en eventos y rutinas de finalización, implementaciones de protocolos en capas, multidifusión y calidad de servicio . También formalizó la compatibilidad con múltiples protocolos, incluidos IPX/SPX y DECnet . La nueva especificación permitió que los sockets se compartieran opcionalmente entre procesos, que las solicitudes de conexión entrantes se aceptaran condicionalmente y que ciertas operaciones se realizaran en grupos de sockets en lugar de en sockets individuales. Aunque la nueva especificación difería sustancialmente de Winsock 1, proporcionó compatibilidad a nivel de fuente y binario con la API de Winsock 1.1. Una de las adiciones menos conocidas fue la API de interfaz de proveedor de servicios (SPI) y los proveedores de servicios en capas .
• Las versiones 2.0.x (desde mayo de 1994 en adelante) tenían estatus de borrador interno y no fueron anunciadas como estándares públicos.
• La versión 2.1.0 (enero de 1996) fue el primer lanzamiento público de la especificación Winsock 2.
• La versión 2.2.0 (mayo de 1996) incluía numerosas correcciones menores, aclaraciones y recomendaciones de uso. También fue la primera versión en la que se eliminó la compatibilidad con 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 menores en la funcionalidad. Se agregaron mecanismos para consultar y recibir notificaciones de cambios en la configuración de la red y del sistema.
• La versión preliminar técnica de IPv6 para Windows 2000 (diciembre de 2000) vio la primera implementación de RFC 2553 (marzo de 1999, posteriormente obsoleta por RFC 3493), una API independiente del protocolo para la resolución de nombres, que se convertiría en parte de Winsock en Windows XP .

Windows 8 incluye las extensiones "RIO" (Registered IO) para Winsock. ^[2] 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 utilizan el resto de la pila TCP y UDP normal de Windows (y utilizan 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.

• Microsoft no proporcionó una implementación de Winsock 1.0.
• La versión 1.1 de Winsock se suministraba en un paquete adicional (llamado Wolverine) para Windows para Trabajo en Grupo (cuyo nombre en código era Snowball ). Era un componente integral de Windows 95 y Windows NT a partir de la versión 3.5 (la versión inicial disponible comercialmente de Windows NT, la versión 3.1, incluía únicamente una implementación propietaria y bastante incompleta de TCP/IP basada en la API "STREAMS" de AT&T UNIX System V ^{[ cita requerida ]} ).
• La versión 2.1 de Winsock se suministró en un paquete adicional para Windows 95. Fue un componente integral de Windows 98 , Windows NT 4.0 y todas las versiones posteriores de Windows. (Microsoft no suministró implementaciones de Winsock 2 para Windows 3.x o Windows NT 3.x).
• Las versiones recientes de Winsock 2.x se han entregado con nuevas versiones de Windows o como parte de paquetes de servicio.
• Winsock 2 es extensible mediante un mecanismo conocido como Proveedor de servicios en capas (LSP). Los LSP de Winsock están disponibles para una amplia gama de propósitos útiles, incluidos los controles parentales de Internet, el filtrado de contenido web, la calidad de servicio , etc. El orden de capas de todos los proveedores se mantiene en el Catálogo de Winsock. En versiones anteriores de Windows, la eliminación de un LSP con errores podía provocar la corrupción del catálogo de Winsock en el registro, lo que podría provocar la 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 tiene la capacidad de autocurarse después de que un usuario desinstala dicho LSP.

• Entre los otros proveedores que ofrecían pilas TCP/IP y UDP/IP compatibles con Winsock se encontraban (en orden alfabético) 3Com , Beame & Whiteside, DEC, Distinct, Frontier, FTP Software , IBM , Microdyne, NetManage , Novell , Sun Microsystems y Trumpet Software International.
• Trumpet Winsock de Peter Tattam fue una de las pocas implementaciones de Winsock 1.0 que se podían instalar en Windows 3.0 , que no tenía soporte integrado para Winsock. ^{[3] [4]} Trumpet también fue la implementación 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. ^[5]
• El proyecto Wine contiene una reimplementación compatible con código fuente y binario de Winsock sobre la API de sockets BSD .

• Zócalos Berkeley
• Proveedor de servicios en capas (Winsock LSP)

• MSDN - Referencia de novedades de Windows Socket 2
• MSDN - Página de inicio de Windows Socket 2
• Preguntas frecuentes sobre sockets - Preguntas frecuentes sobre sockets de Windows
• Programación de cliente/servidor con sockets TCP/IP en Wayback Machine (archivado el 3 de marzo de 2016) - Programación Winsock C++
• Cómo trasladar programas de Berkeley Socket a Winsock
• Blog de desarrollo de redes de Windows: blog para desarrolladores de Microsoft que cubre Winsock, WSK, WinINet, Http.sys, WinHttp, QoS y System.Net, con un enfoque en las características que se están introduciendo en Windows Vista
• Breve historia de Microsoft en la Web
• Información de desarrollo de WinSock
• Preguntas frecuentes para programadores de Winsock