Introduction à Winsock, y compris le contexte et la technologie

Introduction Winsock Including Background Technology

Cet article parle principalement de l'API Windows Sockets, qui peut être abrégée en WSA et Winsock. Après avoir lu cet article, vous pourrez connaître sa définition, son contexte, sa technologie ainsi que ses implémentations.

Sur cette page :

Définition à Winsock
Contexte de Winsock
Technologie de Winsock
Implémentations de Winsock

Définition à Winsock

Qu’est-ce que Winsock ? En informatique, Winsock est une spécification technique utilisée pour définir comment le logiciel réseau Windows doit accéder aux services réseau, notamment TCP/IP. Il s'appelle Winsock car il s'agit d'une adaptation de l'interface socket Berkeley UNIX à Windows. Un socket est un accord spécial utilisé pour se connecter et échanger des données entre deux processus de programme sur le même ordinateur ou réseau.

utiliser la commande Winsock

Conseil: Si vous souhaitez en savoir plus sur les autres protocoles Internet, il est alors recommandé de vous rendre sur le site MiniTool.

Winsock est l'abréviation de l'API Windows Sockets (WSA). Il définit l'interface standard entre les applications clientes Windows TCP/IP (telles que les clients FTP ou les navigateurs Web) et la pile de protocoles TCP/IP de base.

Article similaire: Utilisez la commande Netsh Winsock Reset pour résoudre le problème de réseau Windows 10

Contexte de Winsock

L'API Windows Sockets a été proposée par Martin Hall de JSB Software (plus tard Stardust Technologies) lors de la discussion BoF (Bird of a Feather) sur le réseau CompuServe BBS en octobre 1991.

La première version de la spécification a été écrite par Martin Hall, Mark Towfiq de Microdyne (plus tard Sun Microsystems), Geoff Arnold de Sun Microsystems, ainsi que Henry Sanders et J Allard de Microsoft avec l'aide de nombreux autres.

Des discussions ont eu lieu sur la meilleure manière de résoudre les problèmes de droit d'auteur, de propriété intellectuelle et d'éventuels problèmes antitrust, ainsi que sur l'examen des travaux menés par l'IETF ou la création de fondations à but non lucratif. En fin de compte, il a été décidé que la spécification ne devrait être protégée que par cinq auteurs (non affiliés).

Tous les développeurs participants ont longtemps refusé d'abréger le nom en simplement Winsock car il y avait beaucoup de confusion entre l'API et le fichier de bibliothèque DLL (winsock.dll), qui exposait uniquement l'interface générale WSA à l'application située au-dessus. On pense généralement que seule la garantie que le fichier DLL existe sur le système peut fournir une prise en charge complète du protocole TCP/IP.

Technologie de Winsock

La spécification de l'API Windows Socket définit deux interfaces : l'API utilisée par les développeurs d'applications et SPI qui fournit une méthode permettant aux développeurs de logiciels réseau d'ajouter de nouveaux modules de protocole au système. Chaque interface représente un contrat.

L’API garantit que les applications conformes peuvent fonctionner normalement avec l’implémentation de protocole conforme de n’importe quel fournisseur de logiciel réseau. Le contrat SPI garantit que des modules de protocole conformes peuvent être ajoutés à Windows afin qu'ils puissent être utilisés par des applications compatibles API.

Bien que ces contrats aient été importants lors de la première sortie de Windows Sockets, ils n'ont désormais qu'une signification académique car l'environnement réseau nécessite une prise en charge multi-protocoles. L'API Windows Sockets version 2.0 inclut la fonction d'utilisation d'IPX/SPX, bien que ce protocole soit presque obsolète lorsque WSA 2.0 a quitté l'usine.

Le code et la conception de Windows Sockets sont basés sur les sockets BSD, mais des fonctionnalités supplémentaires sont fournies pour permettre à l'API de se conformer au modèle de programmation Windows conventionnel.

L'API Windows Sockets couvrait presque toutes les fonctionnalités de l'API des sockets BSD, mais il existe des obstacles inévitables, principalement causés par les différences fondamentales entre Windows et Unix (bien que la différence entre les sockets Windows et les sockets BSD soit inférieure à la différence entre ce dernier et STREAMS).

Cependant, l'objectif de conception des sockets Windows était de permettre aux développeurs de porter relativement facilement des applications basées sur des sockets d'Unix vers Windows. Il ne suffisait pas de créer des API utiles uniquement pour les programmes Windows nouvellement écrits.

Par conséquent, Windows Sockets contenait de nombreux éléments conçus pour faciliter le portage. Par exemple, les applications Unix pourraient utiliser la même variable errno pour enregistrer les erreurs réseau et les erreurs détectées dans les fonctions standard de la bibliothèque C.

Comme il ne peut pas être implémenté sous Windows, les Windows Sockets ont introduit une fonction spéciale, WSAGetLastError(), pour récupérer les informations sur les erreurs. Un tel mécanisme était très utile, mais le portage des applications restait extrêmement compliqué.

De nombreuses applications TCP/IP primitives ont été implémentées en utilisant des fonctionnalités système spécifiques à Unix (telles que des pseudo-terminaux et des appels système fork), et il était problématique de reproduire cette fonction sous Windows. En relativement peu de temps, le portage a cédé la place au développement d'applications Windows dédiées.

Implémentations de Winsock

Microsoft n'a pas fourni d'implémentation de Winsock 1.0.
La version 1.1 de Winsock a été fournie dans un package complémentaire (appelé Wolverine) pour Windows for Workgroups (code nommé Snowball).
Winsock version 2.1 a été fourni dans un package complémentaire pour Windows 95.
La dernière version de Winsock 2.x a été fournie avec la nouvelle version de Windows ou dans le cadre d'un service pack.
Winsock 2 peut être étendu via un mécanisme appelé Layered Service Provider (LSP).