Peer-to-Peer-Schicht: PNode, SNode, RNode

1. Publishing Node (PNode): bringt einen neuen Datensatz in das Verzeichnis ein 2. Requesting Node (RNode): stellt eine Anfrage nach einem durch eine FileID

iden-tifizierten Datensatz

3. Lookup Node (LNode): erh¨alt eine Lookup-Nachricht und liefert eine Menge von Daten besser passender Knoten

Abbildung 6.10: Top-Level-Modell

4. Storage Node (SNode): speichert einen Datensatz und gibt ihn auf eine entspre-chende Anfrage hin zur¨uck

Ein Knoten, welcher einen Request des Typs FIND_VALUE erh¨alt und den Datensatz zur¨uckliefert, handelt nicht in der Rolle Lookup Node, sondern in der Rolle Storage No-de. Es entscheidet sich also anhand seiner Datenbasis, in welcher der beiden Rollen ein kontaktierter Knoten handelt.

In der gew¨ahlten rollenbasierten Sicht spielt die Wahl eines konkreten Knotens⁵ f¨ur die Speicherung und Anfrage von Datens¨atzen keine Rolle, so dass das Routing-Verfahren zur Auffindung von zust¨andigen Knoten im Rahmen von Kademlia nicht relevant f¨ur das Modell ist. Der Rolle LNode kommt dementsprechend keine Bedeutung zu.

Auch hinsichtlich der Sicherheitsaspekte ist die Rolle LNode nicht notwendig, denn die Fehlverhaltensm¨oglichkeiten sind stark beschr¨ankt:

• Keine Antwort: Ein Knoten liefert keine Antwort auf eine Anfrage. Vom Lookup-Initiator wird dann ein anderer konkreter Knoten kontaktiert. In der rollenbasierten Sicht ist die Wahl der konkreten Instanz einer Rolle aber wie erw¨ahnt unerheblich.

5also einer spezifischen Knoten-Entit¨at mit einer speziellen NodeID und IP-Adresse

Abbildung 6.11: Subpages des Top-Level-Modells

• Falsche Antwort: Ein Knoten liefert falsche oder unpassende Tupel (Knoteninfor-mationen) als Antwort auf eine Anfrage. In diesem Fall stellt der Lookup-Initiator eine Anfrage an einen anderen Knoten in der Rolle LNode, was wie oben keine Entsprechung in der rollenbasierten Sicht hat.

• Falscher Datensatz: Ein Knoten liefert einen falschen Datensatz auf eine Anfrage zur¨uck, obwohl er nicht der zust¨andige Knoten f¨ur diese FileID ist. In diesem Fall agiert der Lookup Node aber in der Rolle eines Speicherknotens, d.h. diese Form des Fehlverhaltens wird automatisch abgedeckt, wenn die R¨uckgabe falscher Antworten in der Rolle SNode untersucht wird.

Diese Rolle wird folglich nicht modelliert. Damit entf¨allt auch die Darstellung der Me-thode FIND_NODE.

Abbildung 6.12 zeigt die drei zentralen Rollen der P2P-Schicht. Die obere Box stellt die Rolle PNode dar. In der Stelle P N In werden Kombinationen von FileIDs und Daten abgelegt, die mittels der Transition ST ORE in der Rolle SNode gespeichert werden.

Anfragen aus der StelleRN In der RolleRNodewerden verwendet, um in der Transition FIND VALUE die gesuchten Datens¨atze zu beziehen und ¨uberRN Out bzw.RN NoData zur¨uck an die entsprechende Methode desP2P-ZuSI-Regelwerks zu ¨ubergeben.

Die StelleSN DataStorerepr¨asentiert den globalen Zustand des P2P-Verzeichnisses, also s¨amtliche auf der Gesamtheit aller Peers gespeicherten Datens¨atze.

6.2.2.1 Subpage ST ORE

Die P2P-Methode STORE wird zwischen PNode und dem Speicherknoten SNode (rechte Box) durchgef¨uhrt. Abbildung 6.13 zeigt die zugeh¨orige SubpageSTORE. Beim Schalten der Transition wird der Datensatz (vom FarbtypP2P_DATA) der Datenbasis hinzugef¨ugt, indem er in die Liste der gespeicherten Datens¨atze (StelleSN DataStoreder RolleSNode) aufgenommen wird. Weiterhin wird mittels einere-Marke inPN StoreOk quittiert, dass die Speicheraufforderung anSNode erfolgreich versandt wurde.

Abbildung 6.12: Peer-to-Peer-Rollen auf Top Level

6.2.2.2 Subpage F IN D V ALU E

Abbildung 6.14 zeigt die Subpage f¨ur die Methode FIND_VALUE, welche zwischen SNode undRNodeausgef¨uhrt wird. Der hier erstmals verwendete Operator#erm¨oglicht die Re-ferenzierung von Bestandteilen zusammengesetzter Farbtypen:#1 tokenliefert beispiels-weise das 1. Element austokenzur¨uck,#1(#2 token)das 1. Element des 2. Elements aus token. So ist die Referenzierung von Elementen in beliebiger Schachtelungstiefe m¨oglich.

AusRN Inwird die FileID f¨ur den gesuchten Datensatz geholt und gegen die gespeicher-ten IDs der Dagespeicher-tens¨atze aus SN DataStore abgeglichen (MethodecontainsFid)⁶. Je nach Anfragemethode (getFirst odergetAll) wird dabei entweder der erste gespei-cherte Datensatz, auf den die FileID passt (ML-Methode getFirstDataWithFid), oder alle Datens¨atze mit passender FileID (Methode getAllDataWithFid) geliefert.

Es ist zu beachten, dass dies eine Vereinfachung darstellt: Die MethodegetFirstkann in der Realit¨at mehrere Datens¨atze auf eine Anfrage zur¨uckgeben, sofern der erste Knoten, der mehrere Datens¨atze mit der gesuchten FileID besitzt, diese auf einen Lookup mit Methode getFirst hin bereitstellt. Im Modell wird aber stets maximal ein Datensatz zur¨uckgegeben.

6Die konkreten ML-Methoden der P2P-Schicht finden sich in Appendix B.4.

Abbildung 6.13: SubpageSTORE

Abbildung 6.14: SubpageF IN D V ALU E

Da der Modellfokus rollenbasiert mit globaler Sicht auf die verteilt gespeicherte Daten-basis ist, kann nicht bekannt sein, wie viele Datens¨atze mit gleicher FileID der erste auf ein getFirstantwortende Knoten gespeichert hat.

Vor dem Hintergrund der folgenden Sicherheitsanalyse (Kapitel 7) ist es f¨ur einen b¨oswil-ligen Speicherknoten sogar sinnvoll, nur eine Antwort zur¨uckzuliefern, n¨amlich den f¨ur sei-ne Zwecke am besten geeigsei-neten (z.B. modifizierten) Datensatz. Die Methode getFirst stellt also gegen¨uber der Realit¨at keine Einschr¨ankung der Angreiferm¨oglichkeiten dar und ist somit eine zul¨assige Vereinfachung.

Die aus SN DataStore extrahierte Antwort auf die Anfrage wird in RN Out abgelegt.

Existiert kein Datensatz mit der gesuchten FileID, so wird als Indikator f¨ur einen nicht vorhandenen Datensatz eine-Token inRN NoData ¨ubertragen.