Winsock

Windows Sockets API (później skrócone do Winsock) – techniczna specyfikacja określająca w jaki sposób program sieciowy napisany dla systemu Windows może uzyskiwać dostęp do usług sieciowych, szczególnie stosu TCP/IP. Definiuje standardowy interfejs między klientem TCP/IP (np. klientem FTP) a systemowym stosem TCP/IP. Zastosowane nazewnictwo bazuje na modelu gniazd BSD użytym w Berkeley UNIX do komunikacji między programami. Początkowo wszyscy twórcy biorący udział w rozwoju Windows Sockets opierali się skracaniu nazwy do samego „Winsock”, ponieważ użytkownicy często utożsamiali całe API z biblioteką DLL (winsock.dll), która jedynie eksponowała funkcje i procedury WSA. Wielu użytkowników było przekonanych, że samo posiadanie tej biblioteki wystarczało do zapewnienia pełnej obsługi TCP/IP.

Rys historyczny

Wczesne systemy operacyjne firmy Microsoft, zarówno MS-DOS jak i Microsoft Windows, zapewniały ograniczone funkcje sieciowe, przeważnie oparte na NetBIOS/NetBEUI. W tym okresie Microsoft kompletnie ignorował stos protokołu TCP/IP. Pewna liczba grup uniwersyteckich i komercyjnych dostawców, w tym grupa PC/IP na MIT, FTP Software, Sun Microsystems, Ungermann-Bass i Excelan, wprowadziły produkty TCP/IP dla systemu MS-DOS, często w komplecie z innym sprzętem/oprogramowaniem.

Gdy wydano Microsoft Windows 2.0, było już jasne że konieczna jest standaryzacja API. Każdy dostawca posiadał własne API, niezgodne z API innych dostawców, co utrudniało wyperswadowanie na producentach dostosowanie swoich aplikacji tak, by działały z implementacjami TCP/IP innych dostawców.

Pierwotna wersja interfejsu API Windows Sockets została zaproponowana w październiku 1991 przez Martina Halla z firmy JSB Software (później Stardust Technologies). Pierwsze wydanie specyfikacji zostało napisane przez Martina Halla, Marka Towfiq z firmy Microdyne (później Sun Microsystems), Geoffa Arnolda z firmy Sun Microsystems, i Henry'ego Sandersa oraz J Allarda z firmy Microsoft, z pomocą wielu innych osób. Dyskusyjnymi okazały się kwestie praw autorskich, własności intelektualnych oraz potencjalnych kwestii antymonopolowych – pod uwagę brano możliwość założenia fundacji non-profit lub współpracę z IETF. Ostatecznie zadecydowano, by specyfikacja była objęta prawami autorskimi pięciu niezależnych, niezrzeszonych autorów.

Technologia

Specyfikacja API Windows Sockets definiuje dwa interfejsy: API używane przez twórców aplikacji oraz SPI (z ang. Service Provider Interface, Interfejs Dostawcy Usług) który umożliwia tworzenie nowych modułów protokołów. Każdy interfejs SPI reprezentuje kontrakt. API gwarantuje, że każda zgodna ze specyfikacją aplikacja będzie funkcjonować prawidłowo ze zgodną implementacją protokołu niezależnie od jego dostawcy. Kontrakt SPI gwarantuje, że zgodny moduł (implementacja) protokołu może być dodany do systemu i będzie używalny przez zgodne z API aplikacje. Choć w czasach pierwszych wydań WSA te kontrakty były istotne ze względu na konieczność obsługi wieloprotokołowych środowisk sieciowych, teraz nie ma to takiego znaczenia. Razem z API Windows Sockets 2.0 dołączono obsługę protokołu IPX/SPX, jednak z czasem traciła ona na popularności. Ponadto, Microsoft, razem z obecnymi wersjami systemu Windows, dostarcza dobrej jakości implementację stosu TCP/IP i nie istnieją znaczące, niezależne alternatywy. Z niewielkim (nieznaczącym) zainteresowaniem spotyka się też implementacja protokołów innych niż TCP/IP.

„Gniazdka Windows” (Windows Sockets) opierają się na gniazdkach BSD, ale dostarczają dodatkową funkcjonalność pokrywającą standardowy model programowania systemu Windows. Choć WSA udostępnia większość cech gniazdek BSD, część nie jest zaimplementowana głównie ze względu na fundamentalne różnice między systemem Windows a rodziną Unix. Wszystkie nazwy funkcji API zaczynają się od przedrostka WSA, np. WSAGetHostByName() dla funkcji znajdującej nazwę hosta. Warto zwrócić uwagę na fakt, że gniazdka Windows rozszerzyły funkcjonalność gniazdek BSD o tzw. „gniazdka nieblokujące” (asynchroniczne) – dostęp do nich uzyskuje się, dodając WSAAsync przed nazwą funkcji, np. WSAAsyncGetHostByName().

Jednym z celów projektowych gniazdek Windows była relatywna łatwość przenoszenia aplikacji sieciowych z systemu Unix na Windows – uważano, iż API przydatne tylko w nowo tworzonych aplikacjach, nie jest wystarczające, w związku z czym gniazdka Windows posiadają dodatkowe elementy pomocne przy przenoszeniu programów. Na przykład, w systemach z rodziny Unix, aplikacje mogą używać tej samej zmiennej errno do odczytu błędów sieciowych, jak i błędów wykrytych w standardowej bibliotece C. Nie jest to możliwe w systemie Windows, wobec czego wprowadzona została funkcja WSAGetLastError() służąca do odczytu kodu ostatniego błędu. Te mechanizmy były pomocne, ale przenoszenie aplikacji pozostało skomplikowanym procesem, gdyż wiele „tradycyjnych” programów było napisanych z wykorzystaniem specyficznych dla danego systemu cech, np. pseudo-terminali i wywołań funkcji fork. Odtwarzanie tej brakującej funkcjonalności w systemie Windows okazało się problematyczne.

Specyfikacje

  • Wersja 1.0 (Czerwiec 1992) definiowała podstawowe funkcje Winsock. Była bardzo zbliżona do istniejącego interfejsu gniazdek BSD celem ułatwienia przenoszenia istniejących programów. Kilka specyficznych dla Windows rozszerzeń zostało dodanych, głównie dla operacji asynchronicznych z powiadomieniami via komunikaty.
Chociaż dokument nie ograniczał się do protokołu TCP/IP, jedynie TCP i UDP były jawnie wymieniane. Większość dostawców zapewniała obsługę protokołu TCP/IP, ale np. implementacja Winsock firmy DEC zawierała obsługę protokołu DECNet.
  • Wersja 1.1 (Styczeń 1993) zawierała wiele małych poprawek i wyjaśnień specyfikacji. Najbardziej znaczącą zmianą było załączenie funkcji gethostname().
  • Winsock 2 był wstecznie zgodnym rozszerzeniem Winsock 1.1. Dodał obsługę niezależnego od protokołu rozwiązywania nazw, asynchroniczne operacje z powiadomieniami przez zdarzenia oraz funkcje kończące (?), implementacje warstwowych protokołów, multicasting oraz QoS. Sformalizowana została także obsługa wielu protokołów, w tym IPX/SPX oraz DECnet. Nowa specyfikacja pozwalała na opcjonalne współdzielenie gniazdek między procesami, warunkowe przyjmowanie nadchodzących połączeń i przeprowadzanie pewnych operacji na grupach gniazdek zamiast na każdym z osobna. Choć nowa specyfikacja istotnie się różniła od specyfikacji Winsock 1.x, zapewniała zgodność wsteczną na poziomie binarnym i źródeł.
  • Wersje 2.0.x (od maja 1994) miały status wewnętrznego szkicu i nie zostały ogłoszone jako publiczne standardy.
  • Wersja 2.1.0 (styczeń 1996) była pierwszym publicznym wydaniem specyfikacji Winsock 2.
  • Wersja 2.2.0 (maj 1996) zawierała wiele małych poprawek, wyjaśnień i zaleceń odnośnie do użycia. Była też pierwszą wersją nie obsługującą 16-bitowych aplikacji.
  • Wersja 2.2.1 (maj 1997) i wersja 2.2.2 (sierpień 1997) wprowadziła niewielkie rozszerzenia funkcjonalności. Dodano mechanizmy umożliwiające sprawdzenie i otrzymanie powiadomień o zmianach w konfiguracji systemu i sieci.
  • Testowa wersja implementacji protokołu IPv6 dla Windows 2000 (grudzień 2000) posiadała pierwszą implementację RFC 2553 (marzec 1999), później zastąpione przez RFC 3493 (luty 2003), API dla niezależnego od protokołu rozwiązywania nazw, które stało się częścią WSA w Windows XP.

Implementacje

Implementacje firmy Microsoft

  • Microsoft nie dostarczył swojej implementacji Winsock 1.0.
  • Wersja 1.1 WSA była dostarczona jako dodatek do Windows for Workgroups i jako integralna część Windows 95 oraz Windows NT 3.x.
  • Wersja 2 WSA była dostarczona jako dodatek do Windows 95 i jako integralna część Windows 98, Windows NT 4.0, i wszystkich następnych (nie istnieją implementacje Microsoftu dla Windows 3.x czy Windows NT 3.x.)
  • Najnowsze wersje Winsock 2.x są dostarczane wraz z nowymi wydaniami systemu Windows bądź jako elementy pakietów service pack.
  • Winsock 2 jest rozszerzalny przez mechanizm znany jako Layered Service Provider (LSP, Warstwowany Dostawca Usług). Winsockowe LSP są dostępne dla szerokiej gamy użytecznych zadań, jak kontrola rodzicielska, filtrowanie treści, itp. Porządek warstw jest trzymany w katalogu warstw Winsock. W poprzednich wersjach Windows. usuwanie nieprawidłowo działającego LSP mogło spowodować zniszczenie zawartego w rejestrze katalogu, stanowiąc potencjalne źródło utraty wszelkiej łączności sieciowej. Winsock w Windows XP Service Pack 2, Windows Server 2003 Service Pack 1 i późniejszych posiada zdolność do "uzdrawiania" się po tym, gdy użytkownik deinstaluje takiego LSP.

Inne implementacje

  • Inni dostawcy oferujący stosy TCP/IP zgodne z Winsock to (alfabetycznie) 3Com, Beame & Whiteside, DEC, Distinct, FTP Software, Frontier, IBM, Microdyne, NetManage, Novell, Sun Microsystems i Trumpet Software International
  • Trumpet Winsock była jedną z niewielu implementacji Winsock 1.0 która mogła być zainstalowana w Windows 3.0, które nie posiadało wbudowanej obsługi Winsock. Trumpet była też najpopularniejszą shareware'ową implementacją Winsock dla Windows 3.x. Trumpet Winsock 5.0 był dostępny dla Windows 95/98 i Windows NT i zawierał zgodny z Winsock 1.1 stos IPv6 dla tych systemów operacyjnych.

Linki zewnętrzne