Protokół rozpoznawania nazw równorzędnych

Peer Name Resolution Protocol ( PNRP ) to protokół peer-to-peer zaprojektowany przez firmę Microsoft . Protokół PNRP umożliwia dynamiczną publikację i rozpoznawanie nazw oraz wymaga protokołu IPv6 .

Po raz pierwszy wspomniano o protokole PNRP podczas prezentacji na konferencji P2P w listopadzie 2001 r. Pojawił się on w lipcu 2003 r. w pakiecie Advanced Networking Pack dla systemu Windows XP , a później został dołączony do dodatku Service Pack 2 dla systemu Windows XP. Protokół PNRP 2.0 został wprowadzony w systemie Windows Vista i jest dostępny do pobrania dla użytkowników systemu Windows XP z dodatkiem Service Pack 2. Protokół PNRP 2.1 jest zawarty w dla systemów Windows Vista , Windows Server 2008 i Windows XP SP3. Protokół PNRP v2 nie jest dostępny dla systemu Windows XP Professional x64 Edition ani żadnej innej wersji Windows Serwer 2003 .

Pomoc zdalna systemu Windows w systemie Windows 7 używa PNRP, Teredo i IPv6 podczas łączenia za pomocą opcji Easy Connect .

Projekt PNRP jest objęty patentem USA nr 7 065 587, wydanym 20 czerwca 2006 r.

Obsługa protokołu PNRP została usunięta w systemie Windows 10 w wersji 1909 .

usługi PNRP

PNRP to rozproszony protokół rozpoznawania nazw, umożliwiający hostom internetowym publikowanie „nazw równorzędnych” i odpowiadających im adresów IPv6 oraz opcjonalnie innych informacji. Inne hosty mogą następnie rozpoznać nazwę elementu równorzędnego, pobrać odpowiednie adresy i inne informacje oraz ustanowić połączenia peer-to-peer.

W przypadku protokołu PNRP nazwy elementów równorzędnych składają się z „autorytetu” i „kwalifikatora”. Urząd jest identyfikowany przez bezpieczny skrót powiązanego klucza publicznego lub przez symbol zastępczy (liczbę zero), jeśli nazwa równorzędna jest „niezabezpieczona”. Kwalifikator jest łańcuchem , który pozwala organowi mieć różne nazwy elementów równorzędnych dla różnych usług.

Jeśli nazwa elementu równorzędnego jest bezpieczna, rekordy nazw PNRP są podpisywane przez organ publikujący i można je zweryfikować przy użyciu jego klucza publicznego. Niezabezpieczone nazwy peerów mogą być publikowane przez każdego, bez możliwości weryfikacji.

Wiele podmiotów może publikować tę samą nazwę elementu równorzędnego. Na przykład, jeśli nazwa elementu równorzędnego jest powiązana z grupą, każdy członek grupy może publikować adresy dla nazwy elementu równorzędnego.

Nazwy elementów równorzędnych są publikowane i rozstrzygane w określonym zakresie. Zasięg może obejmować łącze lokalne, witrynę (np. kampus) lub cały Internet.

PNRP i rozproszone tablice skrótów

Wewnętrznie PNRP wykorzystuje architekturę podobną do rozproszonych systemów tablic mieszających, takich jak Chord lub Pastry . Nazwa elementu równorzędnego jest mieszana w celu utworzenia 128-bitowego identyfikatora elementu równorzędnego, a algorytm podobny do DHT jest używany do pobierania lokalizacji hosta publikującego ten identyfikator. Istnieją jednak pewne istotne różnice.

Systemy DHT, takie jak Chord lub Pastry, przechowują indeksy obiektów (hash) w węźle, którego identyfikator jest najbliższy hashowi, a algorytm routingu ma na celu znalezienie tego węzła. Natomiast PNRP zawsze przechowuje skrót w węźle, który publikuje identyfikator. Węzeł będzie miał zatem tyle wpisów w systemie trasowania, ile identyfikatorów publikuje. Projekt PNRP prawdopodobnie wymienia zwiększone bezpieczeństwo i solidność na wyższe koszty trasowania.

Większość systemów DHT zakłada, że ​​tylko jeden węzeł publikuje określony indeks. Natomiast PNRP pozwala wielu hostom na publikowanie tej samej nazwy. Indeks wewnętrzny składa się w rzeczywistości ze 128-bitowego skrótu nazwy peera i 128-bitowego identyfikatora lokalizacji, pochodzącego z adresu IPv6 węzła.

Protokół PNRP nie korzysta z tablicy routingu, lecz z pamięci podręcznej wpisów PNRP. Nowe wpisy w pamięci podręcznej są pozyskiwane jako efekt uboczny bieżącego ruchu. Algorytm utrzymania pamięci podręcznej zapewnia, że ​​każdy węzeł utrzymuje odpowiednią wiedzę o „chmurze”. Został zaprojektowany w taki sposób, aby czas rozwiązania żądania był różny w zależności od logarytmu rozmiaru chmury.

Zobacz też

Linki zewnętrzne