Microsofts Peer Name Resolution Protocol

Seite 2: Das Prinzip

Inhaltsverzeichnis

PNRP benutzt die Erkenntnis aus der Realwelt, dass "jeder jeden über fünf Ecken kennt" für das Netzwerk. Es arbeitet wie moderne File-Sharing-Programme mit einer "Distributed Hash Table" (DHT). Jeder Teilnehmer (PNRP-Node) hält einen Teil der Informationen über den Namensraum sowie Referenzen über die benachbarten PNRPNodes bereit.

In mehreren Schritten entsteht aus den bekannten Daten der Wert, mit dessen Hilfe die zugehörige IPv6-Adresse in der Distributed Hash Table nachgeschlagen wird.

Diesen verteilten Cache nennt man bei PNRP eine Wolke (PNRP Cloud), was jedoch nichts mit dem momentan hochgekochten Cloud-Computing zu tun hat. PNRP unterscheidet verschiedene, voneinander unabhängige Wolken, entsprechend der Reichweite der IPv6-Adressen, die innerhalb der Wolke gefunden werden können: Es gibt die globale Wolke und Link-lokale Wolken, eine für jedes Interface mit IPv6-Adresse. Nur Namen in der globalen Wolke sind im ganzen IPv6-Internet sichtbar. Die Link-lokalen Wolken enthalten Namen von Rechnern innerhalb des lokalen Netzwerk-Segments. Da die Site-lokalen IPv6-Adressen schon im September 2004 per RFC 3879 für veraltet erklärt wurden, gibt es die im ersten PNRP-Entwurf vorgesehene Wolke auf dieser Ebene nicht mehr. Allerdings können Netz-Admins an ihrer Stelle mit einigem Fummeln ihre eigenen Wolken aufsetzen.

Eine Anwendung, die PNRP benutzt, ist die Remote-Unterstützung in Windows 7. Der Hilfesuchende kann die Verbindung mittels "Easy Connect" anfordern und sieht dann nur ein 12-stelliges Passwort. Der PC berechnet daraus einen Namen, den er in der globalen PNRP-Wolke bekannt gibt. Das Passwort übermittelt der Hilfesuchende dem Helfer, dessen PC ebenfalls den Namen berechnet und sich mittels PNRP die IPv6- Adresse holt, um die Verbindung aufzubauen.

Um einen Namen aufzulösen, wandelt der PC ihn zunächst in eine Zahl um, die PNRP-ID genannt wird. Nun schaut der Resolver, ob er in seinem lokalen Teil der Hash-Tabelle einen passenden Eintrag hat. Falls nicht, fragt er denjenigen Node aus seiner Liste, dessen PNRP-ID am nächsten an der gesuchten liegt. Er sendet dabei eine Liste der Knoten, die er für diese Anfrage schon einmal kontaktiert hat. Dies verhindert, dass sich eine Namensauflösung im Kreis dreht, oder schon bekannte Referenzen nochmals zurückgegeben werden.

Der Knoten, der eine Anfrage bekommt, erstellt eine Liste der Knoten, deren PNRP-IDs näher an der gesuchten liegen, und sortiert sie nach dem Abstand. Dann löscht er die dem anfragenden Knoten schon bekannten IDs (diese standen ja in der Anfrage) und sendet die verbliebene Liste zurück. Der Fragende baut diese "Next Hop List" in seine ein und fragt beim nunmehr nächstliegenden an.

Es kann vorkommen, dass die verbliebene Liste leer ist, eine Sackgasse in der Auflösung (Dead End). Das kann zweierlei bedeuten: Entweder ist der befragte Knoten schon der gesuchte und die Abfrage war erfolgreich. Oder der Knoten kennt keinen weiteren, der näher am Ziel liegt. Dann versucht es der anfragende Knoten mit dem nächstbesten Eintrag aus seiner Liste.

Dieses iterative Verfahren ist seit der Version 2 der Stand der PNRP-Technik. Version 1 des Protokolls hatte noch ein inkompatibles rekursives Verfahren beschrieben, wie Microsoft es sich unter der Nummer 7 065 587 in den USA patentieren ließ.