Wprowadzenie do Winsock, w tym tło i technologia

Introduction Winsock Including Background Technology

Wypróbuj Nasz Instrument Do Eliminowania Problemów

Wybierz System Operacyjny Windows 10 Windows 8 Windows 7 Windows Vista Windows XP macOS Big Sur Ubuntu Debian Fedora CentOS Arch Linux Linux Mint FreeBSD OpenSUSE Manjaro Wybierz Program Projekcji (Opcjonalnie) - Python JavaScript Java C# C++ Ruby Swift PHP Go TypeScript Kotlin Rust Scala Perl

Opisz Swój Problem

Dostać Odpowiedź

Wyślij Mi E -Mail Pokaż Na Stronie

Ten post dotyczy głównie interfejsu API Windows Sockets, który można skrócić do WSA i Winsock. Po przeczytaniu tego wpisu możesz poznać jego definicję, tło, technologię, a także wdrożenia.

Na tej stronie :

• Definicja Winsock
• Tło Winsock
• Technologia Winsock
• Implementacje Winsock

Definicja Winsock

Co to jest Winsock? W informatyce Winsock to specyfikacja techniczna używana do definiowania, w jaki sposób oprogramowanie sieciowe systemu Windows powinno uzyskiwać dostęp do usług sieciowych, zwłaszcza protokołu TCP/IP. Nazywa się Winsock, ponieważ jest adaptacją interfejsu gniazda Berkeley UNIX dla systemu Windows. Gniazdo to specjalna umowa używana do łączenia się i wymiany danych pomiędzy dwoma procesami programu w tym samym komputerze lub sieci.

Wskazówka: Jeśli chcesz dowiedzieć się więcej o innych protokołach internetowych, polecamy odwiedzić stronę MiniTool.

Winsock to skrót od Windows Sockets API (WSA). Definiuje standardowy interfejs pomiędzy aplikacjami klienckimi Windows TCP/IP (takimi jak klienci FTP lub przeglądarki internetowe) a podstawowym stosem protokołów TCP/IP.

Powiązany post: Użyj polecenia resetowania Netsh Winsock, aby naprawić problem z siecią Windows 10

Tło Winsock

Interfejs API gniazd systemu Windows został zaproponowany przez Martina Halla z JSB Software (później Stardust Technologies) w dyskusji BoF (Bird of a Feather) w sieci CompuServe BBS w październiku 1991 r.

Pierwszą wersję specyfikacji napisali Martin Hall, Mark Towfiq z Microdyne (później Sun Microsystems), Geoff Arnold z Sun Microsystems oraz Henry Sanders i J Allard z Microsoft przy pomocy wielu innych osób.

Odbyło się kilka dyskusji na temat najlepszego rozwiązania problemów związanych z prawami autorskimi, własnością intelektualną i potencjalnymi kwestiami antymonopolowymi, a także rozważono pracę w ramach IETF lub utworzenie fundacji non-profit. Ostatecznie zdecydowano, że prawa autorskie do specyfikacji powinny posiadać jedynie pięciu (niezrzeszonych) autorów.

Wszyscy uczestniczący programiści przez długi czas odmawiali skracania nazwy do po prostu Winsock, ponieważ istniało duże zamieszanie między interfejsem API a plikiem biblioteki DLL (winsock.dll), co jedynie ujawniło ogólny interfejs WSA dla aplikacji znajdującej się nad nim. Powszechnie uważa się, że jedynie zapewnienie istnienia pliku DLL w systemie może zapewnić pełną obsługę protokołu TCP/IP.

Technologia Winsock

Specyfikacja Windows Socket API definiuje dwa interfejsy: API używany przez twórców aplikacji oraz SPI, który zapewnia twórcom oprogramowania sieciowego metodę dodawania nowych modułów protokołów do systemu. Każdy interfejs reprezentuje kontrakt.

Interfejs API gwarantuje, że zgodne aplikacje będą mogły działać normalnie przy implementacji protokołu zgodnego z wymaganiami dowolnego dostawcy oprogramowania sieciowego. Umowa SPI gwarantuje, że do systemu Windows można dodać zgodne moduły protokołów, aby mogły być używane przez aplikacje zgodne z API.

Chociaż umowy te były ważne w momencie wypuszczenia Windows Sockets, obecnie mają one jedynie znaczenie akademickie, ponieważ środowisko sieciowe wymaga obsługi wielu protokołów. Interfejs Windows Sockets API w wersji 2.0 zawiera funkcję korzystania z protokołu IPX/SPX, chociaż protokół ten był prawie przestarzały, gdy WSA 2.0 opuścił fabrykę.

Kod i konstrukcja gniazd systemu Windows są oparte na gniazdach BSD, ale zapewniono dodatkowe funkcje umożliwiające interfejsowi API zgodność z konwencjonalnym modelem programowania systemu Windows.

Windows Sockets API pokrywało prawie wszystkie funkcje API gniazd BSD, ale istnieją pewne nieuniknione przeszkody, które były spowodowane głównie fundamentalnymi różnicami między Windows i Unixem (chociaż różnica między gniazdami Windows i gniazdami BSD była mniejsza niż różnica między ten ostatni i STRUMIEŃ).

Jednak celem projektu gniazd Windows było ułatwienie programistom przenoszenia aplikacji opartych na gniazdach z systemu Unix do systemu Windows. Nie wystarczyło stworzyć API, które były przydatne tylko dla nowo pisanych programów Windows.

Dlatego gniazda systemu Windows zawierały wiele elementów zaprojektowanych w celu ułatwienia przenoszenia. Na przykład aplikacje uniksowe mogą używać tej samej zmiennej errno do rejestrowania błędów sieciowych i błędów wykrytych w standardowych funkcjach biblioteki C.

Ponieważ nie można tego zaimplementować w systemie Windows, w gniazdach systemu Windows wprowadzono specjalną funkcję WSAGetLastError() służącą do pobierania informacji o błędach. Taki mechanizm był bardzo pomocny, jednak przenoszenie aplikacji nadal było niezwykle skomplikowane.

Wiele prymitywnych aplikacji TCP/IP zostało zaimplementowanych przy użyciu funkcji systemowych specyficznych dla Uniksa (takich jak pseudoterminale i wywołania systemowe typu fork), a odtworzenie tej funkcji w systemie Windows było problematyczne. W stosunkowo krótkim czasie portowanie ustąpiło miejsca rozwojowi dedykowanych aplikacji Windows.

Implementacje Winsock

• Firma Microsoft nie zapewniła implementacji Winsock 1.0.
• Wersja 1.1 Winsock została dostarczona w pakiecie dodatków (zwanym Wolverine) dla Windows for Workgroups (kod o nazwie Snowball).
• Winsock w wersji 2.1 został dostarczony w pakiecie dodatkowym dla systemu Windows 95.
• Najnowsza wersja Winsock 2.x została dostarczona z nową wersją systemu Windows lub jako część dodatku Service Pack.
• Winsock 2 można rozszerzyć poprzez mechanizm zwany Layered Service Provider (LSP).