In der Computerwissenschaft ist Windows Sockets API (WSA), die später zu Winsock verkürzt wurde, eine technische Spezifizierung, die definiert, wie Windows-Netzsoftware auf Netzdienste, besonders TCP/IP zugreifen sollte. Es definiert einen Normanschluss zwischen Windows TCP/IP Client-Anwendung (wie ein FTP Kunde oder ein WWW-Browser) und dem zu Grunde liegenden TCP/IP Protokoll-Stapel. Die Nomenklatur basiert auf dem Steckdose-API-Modell von Berkeley, das in BSD für Kommunikationen zwischen Programmen verwendet ist. Am Anfang sind alle teilnehmenden Entwickler der Kürzung des Namens zu Winsock seit langem widerstanden, seitdem es viel Verwirrung unter Benutzern zwischen der API und der DLL Bibliotheksdatei (winsock.dll) gab, die nur die allgemeinen WSA-Schnittstellen zu Anwendungen darüber ausgestellt hat. Benutzer würden allgemein glauben, dass nur sich überzeugend die DLL Datei auf einem System da gewesen ist, würde volle TCP/IP Protokoll-Unterstützung zur Verfügung stellen.

Hintergrund

Frühes Microsoft Betriebssysteme, sowohl MS-DOS als auch Windows von Microsoft, hat beschränkten Netzwerkanschluss der Fähigkeit angeboten, die hauptsächlich auf NetBIOS gestützt ist.

Insbesondere Microsoft hat Unterstützung für den TCP/IP Protokoll-Stapel damals nicht angeboten. Mehrere Universitätsgruppen und kommerzielle Verkäufer, einschließlich der PC/IP Gruppe an MIT, FTP Software, Sonne-Mikrosystemen, Ungermann-Bass, und Excelan, eingeführten TCP/IP Produkten für das MS-DOS, häufig als ein Teil eines Bündels der Hardware/Software.

Als Windows 2.0 von Microsoft veröffentlicht wurde, wurden diese Verkäufer durch andere solcher als Verschieden und NetManage im Angebot von TCP/IP für Windows angeschlossen. Der von allen diesen Verkäufern gesehene Nachteil bestand darin, dass jeder von ihnen ihre eigene API (Anwendung verwendet hat, Schnittstelle Programmierend). Ohne ein einzelnes Standardprogrammiermodell war es schwierig, unabhängige Softwareentwickler zu überzeugen, Netzwerkanschlussanwendungen zu schaffen, die mit der zu Grunde liegenden TCP/IP Durchführung jedes Verkäufers arbeiten würden. Fügen Sie dazu die Tatsache hinzu, dass Endbenutzer davon vorsichtig waren, in einem einzelnen Verkäufer geschlossen zu werden, und es klar geworden ist, dass etwas Standardisierung erforderlich war.

Die Windows-Steckdose-API wurde von Martin Hall von JSB Software (später Stardust Technologies) in BoF (Vögel einer Feder) Diskussion über CompuServe BBS Netz im Oktober 1991 vorgeschlagen. Die Erstausgabe der Spezifizierung war authored durch Martin Hall, Mark Towfiq von Mikrodyn (später Sonne-Mikrosysteme), Geoff Arnold von Sonne-Mikrosystemen, und Henry Sanders und J Allard von Microsoft, mit der Hilfe von vielen anderen. Es gab etwas Diskussion darüber, wie man am besten das Copyright, das geistige Eigentum und die potenziellen Kartellprobleme richtet, und Rücksicht dem Arbeiten durch den IETF oder Herstellen eines gemeinnützigen Fundaments gegeben wurde. Schließlich wurde es entschieden, dass die Spezifizierung einfach von den fünf Autoren als (unangeschlossene) Personen urheberrechtlich geschützt würde.

Technologie

Die Windows-Steckdose-API-Spezifizierung definiert zwei Schnittstellen: Die API, die von Anwendungsentwicklern und dem SPI verwendet ist, der ein Mittel für Netzsoftwareentwickler zur Verfügung stellt, neue Protokoll-Module zum System hinzuzufügen. Jede Schnittstelle vertritt einen Vertrag. Die API versichert, dass eine übereinstimmende Anwendung richtig mit einer übereinstimmenden Protokoll-Durchführung von jedem Netzsoftwareverkäufer fungieren wird. Der SPI-Vertrag versichert, dass ein übereinstimmendes Protokoll-Modul zu Windows hinzugefügt werden kann und durch eine mit der API entgegenkommende Anwendung dadurch verwendbar sein wird. Obwohl diese Verträge wichtig waren, als Windows-Steckdosen zuerst veröffentlicht wurden, seitdem Netzumgebungen Mehrprotokoll-Unterstützung verlangt haben (sieh oben) sie sind jetzt von nur dem akademischen Interesse. Eingeschlossen in die Windows-Steckdose-API-Version 2.0 sind Funktionen, IPX/SPX zu verwenden, aber, wie man bekannt, besteht keine kommerzielle Anwendung, der diesen Transport verwertet, seitdem das Protokoll fast bereits zurzeit WSA 2.0 verladene veraltet war. Microsoft hat den TCP/IP Protokoll-Stapel mit allen neuen Versionen von Windows verladen, und es gibt keine bedeutenden unabhängigen Alternativen. Noch es hat bedeutendes Interesse am Einführen von Protokollen außer TCP/IP gegeben.

Windows-Steckdose-Code und Design basieren auf BSD Steckdosen, aber stellt zusätzliche Funktionalität zur Verfügung, um der API zu erlauben, das regelmäßige Windows-Programmiermodell zu erfüllen. Die Windows-Steckdose-API hat fast alle Eigenschaften der BSD Steckdose-API bedeckt, aber es gab einige unvermeidliche Hindernisse, die größtenteils aus grundsätzlichen Unterschieden zwischen Windows und Unix entstanden sind (obwohl man schöne Windows-Steckdosen unterschieden weniger von BSD Steckdosen ist, als die Letzteren von STRÖMEN getan haben). Die ganze Funktion ruft die API herbei beginnen mit dem Namen z.B, um Daten auf einer verbundenen Steckdose zu senden.

Jedoch war es eine Designabsicht von Windows-Steckdosen, dass es für Entwickler relativ leicht sein sollte, Steckdose-basierte Anwendungen von Unix bis Windows zu tragen. Es wurde genügend nicht betrachtet, eine API zu schaffen, die nur für kürzlich geschriebene Windows-Programme nützlich war. Deshalb haben Windows-Steckdosen mehrere Elemente eingeschlossen, die entworfen wurden, um Halten nach Backbord zu erleichtern. Zum Beispiel sind Anwendungen von Unix im Stande gewesen, dieselbe Variable zu verwenden, um sowohl Netzwerkanschlussfehler als auch Fehler zu registrieren, die innerhalb des Standards C Bibliotheksfunktionen entdeckt sind. Seitdem das in Windows nicht möglich war, haben Windows-Steckdosen eine hingebungsvolle Funktion eingeführt, um Fehlerinformation wiederzubekommen. Solche Mechanismen waren nützlich, aber Anwendungshalten nach Backbord ist äußerst kompliziert geblieben. Viele ursprüngliche TCP/IP Anwendungen waren durch das Verwenden von Systemeigenschaften durchgeführt worden, die zu Unix wie Pseudoterminals spezifisch sind, und der Gabel-Systemanruf und das Reproduzieren solcher Funktionalität in Windows waren problematisch. Innerhalb einer relativ kurzen Zeit hat Halten nach Backbord zur Entwicklung von hingebungsvollen Windows-Anwendungen nachgegeben.

Spezifizierungen

• Version 1.0 (Juni 1992) hat die grundlegende Operation von Winsock definiert. Es wurde sehr in der Nähe von der vorhandenen Schnittstelle von Steckdosen von Berkeley behalten, um Halten nach Backbord von vorhandenen Anwendungen zu vereinfachen. Einige mit Windows spezifische Erweiterungen wurden hauptsächlich für asynchrone Operationen mit nachrichtenbasierten Ankündigungen hinzugefügt.

: Obwohl das Dokument Unterstützung zu TCP/IP nicht beschränkt hat, waren TCP und UDP die einzigen ausführlich erwähnten Protokolle. Die meisten Verkäufer haben nur TCP/IP-Unterstützung geliefert, obwohl Winsock vom DEZ DECNet-Unterstützung ebenso eingeschlossen hat.

• Version 1.1 (Januar 1993) hat ausgebessert und Erläuterungen der Spezifizierung. Die bedeutendste Änderung war die Einschließung der Funktion.
• Winsock 2 war eine umgekehrt vereinbare Erweiterung von Winsock 1.1. Es hat Unterstützung für die mit dem Protokoll unabhängige Namenentschlossenheit, asynchronen Operationen mit Ereignis-basierten Ankündigungen und Vollziehungsroutinen, layered Protokoll-Durchführungen, Mehrgussteil und Qualität des Dienstes hinzugefügt. Es hat auch Unterstützung für vielfache Protokolle, einschließlich IPX/SPX und DECnet formalisiert. Die neue Spezifizierung hat Steckdosen erlaubt, zwischen Prozessen fakultativ geteilt zu werden, eingehende Verbindung bittet, und bestimmte Operationen bedingt akzeptiert zu werden, die auf Steckdose-Gruppen aber nicht individuellen Steckdosen durchzuführen sind. Obwohl sich die neue Spezifizierung wesentlich von Winsock 1 unterschieden hat, hat es Quelle - und Vereinbarkeit des binären Niveaus mit Winsock 1.1 API zur Verfügung gestellt. Eine der kleineren bekannten Hinzufügungen war die API von Service Provider Interface (SPI) und Layered Dienstleister.
• Versionen 2.0.x (Mai 1994 vorwärts) hatten inneren Draftstatus, und wurden als öffentliche Standards nicht bekannt gegeben.
• Version 2.1.0 (Januar 1996) war die erste öffentliche Ausgabe von Winsock 2 Spezifizierung.
• Version 2.2.0 (Mai 1996) hat viele geringe Korrekturen, Erläuterungen und Gebrauch-Empfehlungen eingeschlossen. Es war auch die erste Version, um Unterstützung für 16-Bit-Windows-Anwendungen zu entfernen.
• Version 2.2.1 (Mai 1997) und Version 2.2.2 (August 1997) hat geringe Funktionalitätserhöhungen eingeführt. Mechanismen wurden hinzugefügt, um Ankündigung von Änderungen im Netz und der Anlagenkonfiguration zu fragen und zu erhalten.
• Die IPv6 Technische Vorschau für Windows 2000 (Dezember 2000) hat die erste Durchführung (März 1999, später obsoleted durch), eine mit dem Protokoll unabhängige API für die Namenentschlossenheit gesehen, die ein Teil von Winsock in Windows XP werden würde.

Aktualisierungen in Windows 8

Windows 8 schließt "RIO" (Eingetragener IO) Erweiterungen für Winsock ein.

Diese Erweiterungen werden entworfen, um die Gemeinkosten des Benutzers zum Kernweise-Übergang für den Netzdatenpfad und den Ankündigungspfad zu reduzieren, aber den Rest regelmäßigen Windows TCP und UDP-Stapel zu verwenden (und verwendet vorhandene Netzkarten). Der Einstellungspfad (zum Beispiel, die "verbinden" Funktion) ist vom regelmäßigen Pfad von Winsock unverändert.

Durchführungen

Durchführungen von Microsoft

• Microsoft hat keine Durchführung von Winsock 1.0 geliefert.
• Die Version 1.1 von Winsock wurde in einem Erweiterungspaket (genannt Vielfraß) für Windows für Workgroups (Code genannt der Schneeball) geliefert. Es war ein integrierter Bestandteil von Windows 95 und Windows NT von Versionen 3.5 und vorwärts (die anfängliche gewerblich verfügbare Version von Windows NT, Version 3.1, hat nur eine ziemlich unvollständige und Eigentumsdurchführung von TCP/IP eingeschlossen, der auf AT&T UNIX System V "Strom"-API gestützt ist).
• Die Version 2.1 von Winsock wurde in einem Erweiterungspaket für Windows 95 geliefert. Es war ein integrierter Bestandteil von Windows 98, Windows NT 4.0, und alle nachfolgenden Windows-Ausgaben. (Microsoft hat Durchführungen von Winsock 2 für Windows 3.x oder Windows NT 3.x nicht geliefert.)
• Neue Versionen von Winsock 2.x sind mit neuen Windows-Ausgaben oder als ein Teil von Dienstsätzen geliefert worden.
• Winsock 2 ist durch einen als Layered Service Provider (LSP) bekannten Mechanismus ausziehbar. Winsock LSPs sind für eine breite Reihe von nützlichen Zwecken, einschließlich des Internets elterliche Steuerungen, Webinhalt-Entstörung, QoS usw. verfügbar. Die layering Ordnung aller Versorger wird im Winsock Katalog behalten. In vorherigen Versionen von Windows, einen verwanzten LSP entfernend, konnte auf Bestechung des Katalogs von Winsock in der Registrierung hinauslaufen, potenziell auf einen Verlust der ganzen Netzkonnektivität hinauslaufend. Winsock in Windows XP Dienstsatz 2, Dienstsatz von Windows Server 2003 1 und ganzem späterem Windows, das Betriebssysteme in der Lage sind, nach einem Benutzer selbstzuheilen, deinstalliert solch einen LSP.

Andere Durchführungen

• Unter den anderen Verkäufern, die Winsock-entgegenkommenden TCP/IP und UDP/IP-Stapel anbieten, waren (alphabetisch) 3Com, Beame & Whiteside, DEZ, Verschieden, FTP Software, Grenze, IBM, Mikrodyn, NetManage, Novell, Sun Microsystems and Trumpet Software International.
• Trompete-Winsock war einer von den wenigen Winsock 1.0 Durchführungen, die unter Windows 3.0 installiert werden konnten, das keine eingebaute Unterstützung für Winsock hatte. Trompete war auch die populärste shareware Durchführung von Winsock für Windows 3.x. Trompeten Sie Winsock 5.0 ist für Windows 95/98 und Windows NT verfügbar und schließt Winsock 1.1 entgegenkommender IPv6-Stapel für diese Betriebssysteme ein.

Siehe auch

• Layered Dienstleister (Winsock LSP)
• Steckdosen von Berkeley

Außenverbindungen

• MSDN - Winsock2 Verweisung
• MSDN - Winsock2 Haus-

Häufig gestellte

• Steckdose-Fragen - häufig gestellte Windows-Steckdose-Fragen
• Kunde / Server-Programmierung mit TCP/IP Steckdosen - Winsock C ++, Programmierend
• Das Halten nach Backbord von Steckdose-Programmen von Berkley zu Winsock
• Windows-Netzentwicklung blog - Entwickler von Microsoft blog Bedeckung von Winsock, WSK, WinINet, Http.sys, WinHttp, QoS und System.Net, mit einem Fokus auf Eigenschaften, die in der Windows-Aussicht einführen werden
• Kurze Geschichte des Microsofts im Web
• Fehler von Winsock codiert Liste mit Beschreibungen
• Entwicklungsinformation von WinSock
• Winsock häufig gestellte Programmierer-Fragen