Model rozpoznawania nazw
przestrzeni nazw odnosi się do niektórych możliwości kojarzenia (co najmniej) protokołu i adresowania atrybutów usługi sieciowej z co najmniej jedną przyjazną nazwą. Wiele przestrzeni nazw jest obecnie szeroko używanych, w tym internetowego systemu nazw domen (DNS), usług Active Directory Domain Services, bindery, NetWare Directory Services (NDS) firmy Novell i X.500. Te przestrzenie nazw różnią się znacznie w sposobie ich organizowania i wdrażania. Niektóre z ich właściwości są szczególnie ważne, aby zrozumieć z perspektywy rozpoznawania nazw Winsock.
Typy przestrzeni nazw
Istnieją trzy różne typy przestrzeni nazw, w których można zarejestrować usługę:
- Dynamiczny
- Statyczny
- Uporczywy
Dynamiczne przestrzenie nazw umożliwiają usługom rejestrowanie w przestrzeni nazw na bieżąco oraz odnajdywanie dostępnych usług w czasie wykonywania przez klientów. Dynamiczne przestrzenie nazw często polegają na emisjach, aby wskazać ciągłą dostępność usługi sieciowej. Starsze przykłady dynamicznych przestrzeni nazw obejmują przestrzeń nazw protokołu Service Advertising Protocol (SAP) używaną w środowisku NetWare oraz przestrzeń nazw Protokołu powiązań nazw (NBP) używana przez usługę AppleTalk. Przestrzeń nazw protokołu PNRP (Peer Name Resolution Protocol) używana w systemie Windows jest nowszym przykładem dynamicznej przestrzeni nazw.
Statyczne przestrzenie nazw wymagają, aby wszystkie usługi zostały zarejestrowane przed upływem czasu, czyli po utworzeniu przestrzeni nazw. Przykładem statycznej przestrzeni nazw są hosty , protokołui usług używanych przez większość implementacji protokołu TCP/IP. W systemie Windows te pliki znajdują się zazwyczaj w folderze C:\windows\system32\drivers\etc.
Trwałe przestrzenie nazw umożliwiają usługom rejestrowanie się w przestrzeni nazw na bieżąco. W przeciwieństwie do dynamicznych przestrzeni nazw trwałe przestrzenie nazw zachowują jednak informacje o rejestracji w magazynie nienależącym do miejsca, w którym pozostaje do czasu takiego jak żądania obsługi, które zostaną usunięte. Trwałe przestrzenie nazw są wpisywane przez usługi katalogowe, takie jak X.500 i NDS (NetWare Directory Service). Te środowiska umożliwiają dodawanie, usuwanie i modyfikowanie właściwości usługi. Ponadto obiekt usługi reprezentujący usługę w usłudze katalogowej może mieć różne atrybuty skojarzone z usługą. Najważniejszym atrybutem dla aplikacji klienckich jest adresowanie informacji usługi. DNS to kolejny przykład trwałej przestrzeni nazw. Chociaż istnieje programowy sposób rozpoznawania nazw DNS przy użyciu gniazd systemu Windows, dostawca przestrzeni nazw DNS w systemie Windows nie obsługuje rejestrowania nowych nazw DNS przy użyciu protokołu Winsock. Aby zarejestrować nazwy DNS, należy użyć funkcji DNS bezpośrednio. Aby uzyskać więcej informacji, zobacz dokumentacja DNS.
Organizacja przestrzeni nazw
Wiele przestrzeni nazw jest rozmieszczonych hierarchicznie. Niektóre, takie jak X.500 i NDS, umożliwiają nieograniczone zagnieżdżanie. Inne umożliwiają łączenie usług w jeden poziom hierarchii lub grupy. Jest to zwykle nazywane grupą roboczą. Podczas konstruowania zapytania często konieczne jest ustanowienie punktu kontekstu w hierarchii przestrzeni nazw, z której rozpocznie się wyszukiwanie.
Architektura dostawcy przestrzeni nazw
Oczywiście interfejsy programowe używane do wykonywania zapytań dotyczących różnych typów przestrzeni nazw i rejestrowania informacji w przestrzeni nazw (jeśli są obsługiwane) różnią się znacznie. Dostawca przestrzeni nazw to lokalnie rezydentny element oprogramowania, który wie, jak mapować między przestrzeń nazw Winsock a istniejącą przestrzenią nazw (którą można zaimplementować lokalnie lub uzyskać dostęp za pośrednictwem sieci). Architektura dostawcy przestrzeni nazw jest pokazana w następujący sposób:
architektura dostawcy przestrzeni nazw 
Należy pamiętać, że istnieje możliwość zainstalowania na danym komputerze więcej niż jednego dostawcy przestrzeni nazw dla danej przestrzeni nazw, np. DNS.
Jak wspomniano powyżej, ogólny termin usługi odnosi się do połowy serwera aplikacji klienta/serwera. W usłudze Winsock usługa jest skojarzona z klasą usługi , a każde wystąpienie określonej usługi ma nazwę usługi , która musi być unikatowa w ramach klasy usługi. Przykłady klas usług to FTP Server, SQL Server, XYZ Corp. Employee Info Server itp. W przykładzie podjęto próbę zilustrowania, niektóre klasy usług są dobrze znane, podczas gdy inne są unikatowe i specyficzne dla określonej aplikacji pionowej. W obu przypadkach każda klasa usługi jest reprezentowana zarówno przez nazwę klasy, jak i identyfikator klasy. Nazwa klasy nie musi być unikatowa, ale musi być identyfikatorem klasy. Globalnie unikatowe identyfikatory (GUID) są używane do reprezentowania identyfikatorów klas usług. W przypadku dobrze znanych usług nazwy klas i identyfikatory klas (IDENTYFIKATORY GUID) zostały wstępnie przydzielone, a makra są dostępne do konwersji między, na przykład numerami portów TCP (w kolejności bajtów hosta) i odpowiednimi identyfikatorami GUID identyfikatora klasy. W przypadku innych usług deweloper wybiera nazwę klasy i używa narzędzia Uuidgen.exe do wygenerowania identyfikatora GUID dla identyfikatora klasy.
Pojęcie klasy usługi istnieje, aby umożliwić ustanowienie zestawu atrybutów, które są wspólne dla wszystkich wystąpień określonej usługi. Ten zestaw atrybutów jest udostępniany w czasie, gdy klasa usługi jest zdefiniowana na winsock i jest określana jako informacje o schemacie klasy usługi. Gdy usługa jest zainstalowana i udostępniona na komputerze hosta, ta usługa jest uważana za wystąpienia, a jej nazwa usługi jest używana do odróżnienia określonego wystąpienia usługi od innych wystąpień, które mogą być znane przestrzeni nazw.
Należy pamiętać, że instalacja klasy usługi musi odbywać się tylko na komputerach, na których jest wykonywana usługa, a nie na wszystkich klientach, którzy mogą korzystać z usługi. Jeśli jest to możliwe, Ws2_32.dll dostarcza informacje o schemacie klasy usługi dostawcy przestrzeni nazw w momencie zarejestrowania wystąpienia usługi lub zainicjowania zapytania usługi. Ws2_32.dll nie przechowuje oczywiście tych informacji, ale próbuje pobrać je z dostawcy przestrzeni nazw, który wskazał jego zdolność do dostarczania tych danych. Ponieważ nie ma gwarancji, że Ws2_32.dll może dostarczyć schemat klasy usługi, dostawcy przestrzeni nazw, którzy potrzebują tych informacji, muszą mieć mechanizm rezerwowy, aby uzyskać go za pomocą środków specyficznych dla przestrzeni nazw.
Jak wspomniano powyżej, Internet przyjął to, co można określić jako model usług skoncentrowanych na hoście. Aplikacje, które muszą zlokalizować adres transportu usługi, zazwyczaj muszą najpierw rozpoznać adres określonego hosta znanego do hostowania usługi. W tym adresie dodają dobrze znany numer portu, a tym samym tworzą pełny adres transportu. Aby ułatwić rozpoznawanie nazw hostów, specjalny identyfikator klasy usługi został wstępnie przydzielony (SVCID_HOSTNAME). Zapytanie określające SVCID_HOSTNAME jako klasę usługi i określa nazwę hosta dla nazwy wystąpienia usługi zwróci informacje o adresie hosta, jeśli zapytanie zakończy się pomyślnie.
W systemach Windows Sockets 2 aplikacje niezależne od protokołu powinny unikać konieczności zrozumienia wewnętrznych szczegółów adresu transportu. W związku z tym należy najpierw uzyskać adres hosta, a następnie dodać port jest problematyczny. Aby tego uniknąć, zapytania mogą również zawierać dobrze znaną nazwę określonej usługi i protokół, za pośrednictwem którego działa usługa, na przykład FTP przez TCP. W takim przypadku pomyślne zapytanie zwraca pełny adres transportu dla określonej usługi na wskazanym hoście, a aplikacja nie jest wymagana do sprawdzenia wewnętrznych struktury sockaddr.
System nazw domen w Internecie nie ma dobrze zdefiniowanych metod przechowywania informacji o schemacie klasy usługi. W związku z tym dostawcy przestrzeni nazw DNS dla usługi Winsock mogą obsługiwać tylko dobrze znane usługi TCP/IP, dla których został wstępnie przeniesiony identyfikator GUID klasy usługi.
W praktyce nie jest to poważne ograniczenie, ponieważ identyfikatory GUID klasy usługi zostały wstępnie przypisane dla całego zestawu portów TCP i UDP, a makra są dostępne do pobrania identyfikatora GUID skojarzonego z dowolnym portem TCP lub UDP z portem wyrażonym w kolejności bajtów hosta. W związku z tym wszystkie znane usługi, takie jak HTTP, FTP, Telnet, Whois itp., są dobrze obsługiwane.
Kontynuując przykład klasy usług, nazwy wystąpień usługi FTP mogą mieć wartość "alder.intel.com" lub "ftp.microsoft.com", podczas gdy wystąpienie serwera informacji o pracownikach XYZ Corp może mieć nazwę "XYZ Corp. Employee Info Server Version 3.5".
W pierwszych dwóch przypadkach kombinacja identyfikatora GUID klasy usługi dla protokołu FTP i nazwy komputera (podanej jako nazwa wystąpienia usługi) jednoznacznie identyfikuje żądaną usługę. W trzecim przypadku nazwa hosta, w którym znajduje się usługa, można odnaleźć w czasie zapytania usługi, więc nazwa wystąpienia usługi nie musi zawierać nazwy hosta.
Tematy pokrewne