mit Java implementiert (Java 2 Standard Edition)

mit Java implementiert (Java 2 Standard Edition)
P2P Seminar – JXTA im Detail mit Java implementiert (Java 2 Standard Edition) Nicole Hänelt, Mike Rohland, Julia Schenk, Rafael Grote

Definition Welche Protokolle gibt es? Peer Discovery Protocol API
P2P – JXTA – Überblick Definition Welche Protokolle gibt es? Peer Discovery Protocol API Peer Resolver Protocol API Peer Membership Protocol API Peer Information Protocol API Pipe Binding Protocol API Peer Endpoint Protocol API Beispiel

P2P – JXTA – Definition Ein Protokoll ist ein wieder verwendbares Verfahren um die Datenübertragung zwischen Computern zu regeln. (JXTA: Java P2P Programming; 22. March 2002) Ein Protokoll (engl.: protocol) enthält Standards für die kontrollierte Übermittlung von Daten ( gesehen am )

Welche Protokolle gibt es?

Welche Protokolle gibt es?
P2P – JXTA – Protokolle Welche Protokolle gibt es? Grundservices, die in einem P2P-Netzwerk ausgeführt werden können müssen: Discovery Membership Communication Pipe Binding Protocol Endpoint Protocol Resolver Protocol Peer Information Protocol

P2P – JXTA – Protokolle (JXTA: Java P2P Programming; 22. March 2002)

Peer Discovery Protocol API

P2P – JXTA – Peer Discovery API
Advertisements Dienen zur generellen Beschreibung einer jeden Resource, die im P2P-Netz bereitgestellt wird Werden in XML-Dokumente gefasst Es gibt keine DTDs oder Schemata für Advertisments, es reicht wenn ein Advertisment wohlgeformt ist von JXTA vorgegebene Lebensdauer Löschen flushAdvertisements( String id, int type ) throws IOException;

Peer Group Advertisement
P2P – JXTA – Peer Discovery API Peer Group Advertisement 1 <?xml version="1.0"?> 2 <!DOCTYPE jxta:PGA> 3 <jxta:PGA xmlns:jxta=" <GID> urn:jxta:uuid-AAA AAAAAAA 6 </GID> 7 <MSID> urn:jxta:uuid-DEADBEEFDEAFBABAFEEDBABE 9 </MSID> 10 <Name> Test 12 </Name> 13 <Desc> Wir testen…. 15 </Desc> 16 </jxta:PGA>

Discovery Query Message
P2P – JXTA – Peer Discovery API Discovery Query Message <?xml version=“1.0“ encoding=“UTF-8“?> <jxta:DiscoveryQuery> <Type>2</Type> <Threshold>1</Threshold> <Attr>Name</Attr> <Value>*pader*</Value> <PeerAdv> <?xml version=“1.0.“?> <!DOCTYPE jxta:PA> <jxta:PA xmlns=jxta=“ <PID>urn:jxta: C</PID> </jxta:PA> </PeerAdv> </jxta:DiscoveryQuery>

Discovery Response Message
P2P – JXTA – Peer Discovery API Discovery Response Message <?xml version=“1.0“ encoding=“UTF-8“?> <jxta:DiscoveryResponse> <Type>2</Type> <Count>1</Count> <Attr>Name</Attr> <Value>*pader*</Value> <PeerAdv> <?xml version=“1.0.“?> <!DOCTYPE jxta:PA> <jxta:PA xmlns=jxta=“ <PID>urn:jxta: DE4</PID> </jxta:PA> </PeerAdv> <Response Expiration=“ “> <?xml version=“1.0“?> <!DOCTYPE jxta:PipeAdvertisement> <jxta:PipeAdvertisement xmlns=“ <Id>urn:jxta:uuid AB...EF56A468375</Id> <Type>JxtaUnicastSecure</Type> <Name>Jxta.webcam.paderborn</Name> </jxta:PipeAdvertisement> </Response> </jxta:DiscoveryResponse>

(JXTA: Java P2P Programming; 22. March 2002)

Local Discovery P2P – JXTA – Peer Discovery API
Veröffentlichung von Advertisements publish(Advertisement adv, int type); Im lokalen Cache (Cache Management Ordner) nach Advertisements suchen getLocalAdvertisements(int type, String attribute, String value); Suche nach einem Peer „Bla“ getLocalAdvertisements(DiscoveryService.PEER, „Name“, „Bla“);

Mögliche Implementierung 1 private void findLocalAdvertisements ( ) { 2 System.out.println( ”looking local: ” ); 3 try { Enumeration enu = discoveryService.getLocalAdvertisements(DiscoveryService.ADV, null ,null); if ((enu != null) && enu.hasMoreElements( )) { 6 System.out.println(”found local Advertisement: ”); 7 while (enu.hasMoreElements( )) { 8 Advertisement adv = (Advertisement)enu.nextElement( ); 9 try { Document doc = adv.getDocument(new MimeMediaType (”text/xml”)); doc.sendToStream(System.out); 12 } 13 catch (IOException e) { e.printStackTrace(System.err); 15 } 16 } } 18 } 19 catch (IOException e) { 20 e.printStackTrace(System.err); 21 } 22 } (Oliver Steinhauer: JXTA Seminar, FU Gießen-Friedberg, SS03)

Remote Discovery P2P – JXTA – Peer Discovery API
Veröffentlichung von Advertisements remotePublish(Advertisement adv, int type); Eine Anfrage an alle RendezvousPeers senden um ihre lokale DB zu durchsuchen getRemoteAdvertisements( String peerid, int type, String attribute, String value, int threshold ); Problem: Der Peer weiß nicht, wann die Advertisements gefunden wurden.

Remote Discovery mit Listener
P2P – JXTA – Peer Discovery API Remote Discovery mit Listener getRemoteAdvertisements( String peerid, int type, String attribute, String value, int threshold, DiscoveryListener listener ); Bei jeder Antwort wird der DiscoveryListener aufgerufen. discoveryEvent(DiscoveryEvent discoveryEvent); // behandelt // Event vom Discovery Service Das DiscoveryEvent Objekt getResponse(); // liefter DiscoveryResponseMsg DiscoveryResponseMsg getResponses(); // liefert Aufzählung der Advertisements zurück

Peer Resolver Protocol API
P2P – JXTA – Überblick Einführung Welche Protokolle gibt es? Peer Discovery Protocol API Peer Resolver Protocol API Peer Membership Protocol API Peer Information Protocol API Pipe Binding Protocol API Peer Endpoint Protocol API Beispiel

Peer Resolver API und Antworten (response) empfangen
P2P – JXTA – Peer Resolver API Peer Resolver API wird zur Suche im P2P Netz benutzt dazu werden Anfragen (query) an andere Peers versendet und Antworten (response) empfangen keine Übermittlungsgarantien Rendezvous Peers können Übermittlung ablehnen oder dabei ausfallen keine Antwortgarantien weder wenn keine Antworten vorhanden noch Antworten vorhanden Peer Resolver API benutzt zur Suche(allgemein, alles was response request braucht) schlechter Name da TCP/IP Resolver = resolve(=auflösen)  xml messages (querys) mittels Rendezvous peers versendet empfangen (responses) Rendezvous Peer ausfallen (Traffic, Hack…) ablehnen (SourcePeer nicht in PeerGroup)  keine Übermittlungsgarantien keine Antwortgarantien da schon keine Übermittlungsgarantien keine Antwortgarantien da keine Mitteilung über nicht vorhandene Antworten

Resolver API Classes P2P – JXTA – Peer Resolver API
ResolverInterface – Interface zur Implementierung des ResolverServices ResolverService – Interface definiert QueryHandler Verwaltung GenericResolver – Interface definiert senden von Messages QueryHandler – Interface zur Message Verarbeitung ResolverQuery – Standardimplementierung ResolverResponse – Standardimplementierung Jetzt werden die ResolverAPI Klassen in Kürze vorgestellt ResolverInterface: implentiert die gesammte Funktionalität der Revolver API (Handler an-abmelden, query/response verarbeiten) Resolver Service:Interface, stellt Methoden zur Verfügung um QueryHandler(verarbeiten Query/response) an und abzumelden GenericResolver:Interface, komplettiert ResolverService, enthält Methoden query/response zu verarbeiten QueryHandler: Interface, implementierende Klasse entscheidend, da sie die Querys verarbeitet und entsprechende Responses sendet. ResolverQuery: Interface repräsentiert QueryXMLMessage ResolverResponse: Interface repräsentiert ResponseXMLMessage

QueryHandler im Detail
P2P – JXTA – Peer Resolver API QueryHandler im Detail int processQuery(ResolverQuery query) Ablaufsteuerung mittels Rückgabewert: ResolverService.OK ResolverService.Repropagate void processResponse (ResolverResponse response); keine weitere Ablaufsteuerung da Endpunkt QueryHandler 2 Methoden: processQuery, processResponse processQuery verarbeitet erhaltenden query und! muss evtl. Response selbstständig! zurücksenden int Rückgabe: Constanten: OK Repropagate – Query innerhalb des restliche P2P Netzwerks weiterleiten (keine Exceptions verwandt, da zu Resourcenverbrauchend (Runtime anhalten etc.)) processResponse: peer erhält response und verarbeitet diese ohne Rückgabe da Verbindungsendpunkt

I Benutzen des ResolverServices
P2P – JXTA – Peer Resolver API I Benutzen des ResolverServices Starten: ResolverServiceImpl resolver; resolver = (ResolverServiceImpl)group. getResolverService(); TestQueryHandler handler = new TestQueryHandler(handlerName,credential); resolver.registerHandler(handlerName, handler); ResolverService befindet sich immer in jeweiliger PeerGroup erstellen/registrieren eines speziellen QueryHandlers jeder einzelne query sollte eindeutigen handlerName erhalten um gleichzeitig mehrere Querys zu starten Credential == ID des Peers innerhalb der PeerGroup, später mehr rechtzeitig den QueryHandler wieder ungültig machen, sofern keine weiteren Antworten erwartet/erwünscht, (da so unnötige Unterbrechungen des Peers vermieden werden) Beenden: resolver.unregisterHandler(handlerName);

II Benutzen des ResolverServices
P2P – JXTA – Peer Resolver API II Benutzen des ResolverServices Abfragen: // xml AbfrageDokument erstellen StructuredTextDocument doc = null; doc = (…)StructuredDocumentFactory. newStructuredDocument( new MimeMediaType("text/xml"),"Pong"); Element e = doc.createElement("timestamp 1", format.format(new Date(now))); doc.appendChild(e); String credential = „p2pSeminar"; mittels jxta.util Klassen wird ein StructuredTextDocument erstellt, welches als QueryDokument dient dieses wird mit der aktuellen Zeit als DummyQuery gefüllt

III Benutzen des ResolverServices
P2P – JXTA – Peer Resolver API III Benutzen des ResolverServices // Query erstellen ResolverQueryMsg message = null; String xml = serializeDoc(doc); message = new ResolverQuery(handlerName , credential , group.getPeerID().toString() , xml , 1); // und versenden; löst eine RunTimeException // aus, sofern der Peer nicht vorhanden resolver.sendQuery(peerID, message); dieses Dokument wird serialisiert und als String zusammen mit dem Namen des registrierten QueryHandlers des eigenen credentials der eigenen peerID (bezogen aus der gruppe) und einer eindeutigen queryId an einen Peer über den resolver gesendet. QueryHandler ist völlig transparent dabei. Das versenden von Responses verläuft äquivalent dazu.

Peer Membership Protocol API

Peer Membership API P2P – JXTA – Peer Membership API
Mechanismus um PeerGroup beizutreten nicht zum Management einer PeerGroup gedacht Peer muss Anforderungen des Membership Protokolls erfüllen im Erfolgsfall wird ein credential vergeben kein zentrales Verzeichnis aller Gruppenmitglieder Membership Protokoll nur! zum Beitritt keinerlei Managementfunktionen wie erstellen neuer Gruppen, abändern der beitritts Möglichkeiten Implementierung festgelegt bei Erstellung der PeerGroup Peer muss Anforderungen erfüllen, können unterschiedlich sein (Fragenkatalog / Votingverfahren aller anderen peer…) Im erfolgsfall wird berechtigungsnachweis an peer ausgehändigt da P2P kein zentraler Server der alle Member enthält, daher credential (unsicher!)

AuthenticationCredential und Credential
P2P – JXTA – Peer Membership API AuthenticationCredential und Credential Credential -> Berechtigungsnachweis (dict.leo.org; gesehen am ) AuthenticationCredential enthält: Authentifizierungsmethode anfängliche Identifizierungsinformationen Credential enthält: Identifizierungsinformationen AuthCred bestimmt die Authenitfizierungsmethode mit der der Peer sich anmelden muss mehrere methoden möglich: peerGroup mit Ärtzten und Patienten, Ätzte höhere Sicherheit notwendig enthält zusätzliche Identifizierungsinformationen wie evtl. schon vorhandene PeerGroup Zugehörigkeiten (Ärzte müssen in der Kassenärtztlichen Vereinigung PeerGroup sein) Credential nur als kurzer Nachweis das die Authentifizierung geklappt hat keinerlei Sicherheit (kann abgehört werden etc.)

MembershipService P2P – JXTA – Peer Membership API Service
Apply nimmt ein erstelltes AuthenticationCredential. Prüft ob der MembershipService die Authentifizierungsmethode unterstützt und erstellt passenden Authenticator getAuthCredentials()  gibt alle AuthCred dieses Peers zurück getCurrentCred()  gibt alle cred dieses peers zurück join führt eigentliche anmeldung durch wird erst aufgerufen wenn alle Bedingungen des AuthenticatorObjekts erfüllt sind makeCred()  erstellt Credential aus XML String resign()  Membership annulieren Zur einfachen Erstellung von Anwendungen existiert NullMembershipService Join gibt immer ein gültiges Credential aus Für Gruppen die keinerlei Authentifizierung benötigen

I Ablauf eines PeerGroup Beitritts
P2P – JXTA – Peer Membership API I Ablauf eines PeerGroup Beitritts // 1. MembershipService von der PeerGroup // empfangen MembershipService membership; membership = (MembershipService) newGroup.getMembershipService(); // 2. AuthenticationCredential erstellen AuthenticationCredential authCred authCred = new AuthenticationCredential (newGroup,authenticationMethod); 1.: Spezieller MembershipService wird von der PeerGroup empfangen 2.: AuthenticationCredential erstellen Enthält die Gruppe bei der angemeldet werden soll Und die Methode mit der angemeldet werden soll

II Ablauf eines PeerGroup Beitritts
P2P – JXTA – Peer Membership API II Ablauf eines PeerGroup Beitritts // 3. Authenticator vom MembershipService // empfangen Authenticator authenticator = (Authenticator)membership.apply(authCred); // 4. Authenticator Objekt ausfüllen authenticator.methodXYZ(valueABC); Sofern die Methode in dieser Implementation des MembershipService existiert wird mittels apply der Authenticator empfangen In diesem findet die eigentliche Authentifizierung statt indem Die entsprechenden Methoden aufgerufen werden (kann auch ein Voting durch die Peers auslösen etc.)

III Ablauf eines PeerGroup Beitritts
P2P – JXTA – Peer Membership API III Ablauf eines PeerGroup Beitritts /* 5. Authenticator mittels isReadyForJoin() testen und 6. mit Authenticator beim MembershipService anmelden */ if( authenticator.isReadyForJoin()) { finalCredential = membership.join(authenticator); }  Credential empfangen Zum Schluss mittels isReadyForJoin() abfragen ob die Bedingungen des MembershipService hinreichend erfüllt sind Und mit join und dem authenticator beim MembershipService anmelden Ist alles gut gegangen, so erhält man ein credential

Peer Information Protocol API

Protokollhierarchie von JXTA
P2P – JXTA – Peer Information API Protokollhierarchie von JXTA Peer Discovery Protokoll (Standard) Pipe Binding Protokoll (Standard) Peer Information Protokoll (Standard) Peer Resolver Protokoll (Core) Peer Endpoint Protokoll (Core) Rendezvous Protokoll (Standard) Da man nicht weiss, wie lange es dauern wird bis ma ndie Informationen erhalten wird, nutzt die API einen Listener um die Anwendung zu benachrichtigen wenn die Information verfügbar ist. (PeerInfoListener) Core - required components and behaviours for all JXTA implementations Standard – optional but recommended

Peer Information Protokoll
P2P – JXTA – Peer Information API Peer Information Protokoll - Sobald ein Peer lokalisiert ist, ist es interessant seinen Status und seine Fähigkeiten abzufragen  PIP - Zwei Nachrichtentypen: - Peer Info Query Message (Status des Remote Peers abfragen) - Peer Info Response Message (Seinen Status einem anderen Peer zugänglich machen) - Spezielle Implementation des Peer Resolver Protokolls - Peer publiziert seine PeerAdvertisement  andere Peers lokalisieren diese und ziehen daraus Informationen über den zugehörigen Peer - Dient dem Standard JXTA Service PeerInfoService (optional aber empfohlen) - Wird von einem Peer genutzt um Informationen über einen andern Peer zu erhalte, z.B. soetwas wie Status, Betriebszeit (uptime), Verkehrsbelastung( traffic load), Fähigkeiten --> Das PIP bietet dazu eine Menge von Messages um Statusinformationen eines Peers zu erhalten -Damit bietet es auch die zwei Nachrichtentypen um Informationen zu bekommen und zu senden: Peer Info Query Message (Status des Remote Peers abfragen) Peer Info Response Message (Seinen Statue einem anderen Peer zugänglich machen) Ausserdem ist es mit dem PIP auch möglich im lokalen Zwischenspeicher nach Peer Informationen anderer Peers zu suchen - Spezielle Implementation des Peer Resolver Protokolls, ist also eine Schicht über dem Peer Resolver Protokoll angesiedelt Wenn ein Peer das erste Mal initialisiert wird publiziert er seine 'PeerAdvertisement', welche von mind. Einem Redevous aufgenommen wird. Wenn nun eine Anfrage nach den Informationen eines speziellen Peers gemacht wird, dann wird eine Anfrage gestartet, um die PeerAdvertisement zu lokalisierren und daraus Informationen über denn Peer zu ziehen um diesen zu kontaktieren Über den endpoint wird ein Peer direkt kontaktiert um dessen Informationen zu erhalten

P2P – JXTA – Peer Information API
PIP Query Message <xs:element name="PeerInfoQueryMessage" type="jxta:PeerInfoQueryMessage"/> <xs:complexType name="PeerInfoQueryMessage"> <xs:sequence> <xs:element name="sourcePid" type="jxta:JXTAID"/> <xs:element name="targetPid" type="jxta:JXTAID"/>  <xs:element name="request" type="xs:anyType" minOccurs="0"/> </xs:sequence> </xs:complexType> request Feld kann genutzt werden um einen speziellen Request zu bezeichenen, wenn nicht  Anfrage liefert default Set von Informationen The PIP Query Message provides a request field that may be used to encode a specific request. PIP does not dictate the format of the request field and it is left up to the consumer to do so. Higher-level services may utilize the request field to offer expanded capabilities. request Feld kann genutzt werden um einen speziellen Request zu bezeichenen, wenn nicht → Anfrage liefert default Set von Informationen (Betriebszeit, Nachrichtenzähler, etc.) <sourcePid> The peer id of the requesting peer. <targetPid> The peer id of the peer being queried. <request> An optional Request structure.

P2P – JXTA – Peer Information API
PIP Response Message <xs:element name="PeerInfoResponse" type="jxta:PeerInfoResponse"/> <xs:complexType name="PeerInfoResponseMessage"> <xs:sequence> <xs:element name="sourcePid" type="jxta:JXTAID"/> <xs:element name="targetPid" type="jxta:JXTAID"/> <xs:element name="uptime" type="xs:unsignedLong" minOccurs="0"/> <xs:element name="timestamp" type="xs:unsignedLong" minOccurs="0"/> <xs:element name="response" type="xs:anyType" minOccurs="0"/> <xs:element name="traffic" type="jxta:piptraffic" minOccurs="0"/> </xs:sequence> </xs:complexType> <xs:complexType name="piptraffic"> ... <xs:complexType name="piptrafficinfo"> The Peer Information Protocol Response Message provides specific information about the current state of a peer, such as uptime, inbound and outbound message count, time last message received, and time last message sent. <sourcePid> The peer id of the requesting peer. <targetPid> The peer id of the peer being queried. <uptime> The relative time in milliseconds since the responding Peer Information Service began execution. Peers should provide this tag in all responses, but may chose to not implement it if the information is unavailable or would represent a security breach. <timestamp> The absolute time at which this response was generated. Measured in milliseconds since "the epoch", namely January 1, 1970, 00:00:00 GMT. Peers should provide this tag in all responses, but may chose to not implement it if the information is unavailable or would represent a security breach. <response> Potentially contains a response to a previous request from a PIP Query. To match queries to responses the QueryId element of the Peer Resolver Protocol must match. This field can contain any desired content. <traffic> Contains information about the network traffic performed by the target peer. This element is optional.

PeerInfoService Interface
P2P – JXTA – Peer Information API PeerInfoService Interface - Peer Informationen lokalisieren und speichern in Form des PeerInfoAdvertisements. Das PeerInfoService Interface ist sehr simpel. Die einzigen Aufgaben bestehen darin Peers zu lokalisieren und die Informationen zu speichern. Es speichert wie auch der Discovery Service advertisements mit Hilfe des Content Managers. Einziges zwischengespeicherte Advertisement ist das PeerInfoAdvertisement.

PeerInfoAdvertisement
P2P – JXTA – Peer Information API PeerInfoAdvertisement

Pipe Binding Protocol API

P2P – JXTA – Pipe Binding API
JXTA ... Pipes ... - Virtuelle Kommunikationskanäle zwischen Computern, beschrieben durch PipeAdvertisements - Bieten virtuelle Eingangs – und Ausgangsmailboxen, die nicht physisch an eine spezielle Peer Lokation gebunden sind - Eindeutig identifiziert durch Pipe ID - Zwei Enden: - Input Pipe (empfangendes Ende) - Output Pipe (sendendes Ende) - Pipes kann man vergleichen mit Sockets oder Streams, also einem Kanal zwischen zwei Computern um Daten zu übertragen. Der Unterschied ist der, dass man davon ausgeht, dass ein P2P Netzwerk ein paar Dinge hat, die sich von einem normalen Netzwerk unterscheiden. Unter anderem auch, dass man annimmt, dass die Verbindung nicht direkt ist, und dass es viele Protokolle gibt die genutzt werden können. - Eine Pipe kann man ansehen als eine abstrakt benannte Nachrichtenqueue, die create, open/resolve (bind), close (unbind), delete, send und receice Operationen bietet. Aktuelle Pipe Implementationen unterscheiden sich noch häufig, aber alle konformen Implementationen nutzen das PbP um die Pipe an einen Endpoint zu binden.

Pipe Binding Protokoll
P2P – JXTA – Pipe Binding API Pipe Binding Protokoll - Regelt den Aufbau eines virtuellen Kanals zwischen zwei oder mehreren Knoten - JXTA HTTP Transport, JXTA TCP/IP Transport, JXTA TLS Transport - Wird verwendet um die Enden einer Pipe mit den jeweiligen Endpunkten der Knoten zu verbinden - Wird von Applikationen und Services genutzt um miteinander zu kommunizieren. - Angesiedelt über dem Endpoint Protokoll und nutzt viele verschiedene Nachrichtentransporte wie z.B. JXTA HTTP Transport, JXTA TCP/IP Transport, JXTA TLS Transport um Nachrichten zu senden.

PipeAdvertisement - Wird vom Pipe Service genutzt, um die Endpunkte für lokalen Input und Output der Pipe zu erstellen - Enthält Pipe ID - Muss Pipe Type enthalten - JxtaUnicast: unsicher und nicht zuverlässig - JxtaUnicastSecure: Sicher (nutzt TLS) - JxtaPropagate: senden an mehre - Kann optionalen symbolischen Namen enthalten Beschreibt die Pipe JxtaUnicast wird genutzt um one-to-one Nachrichten zu senden JxtaUnicastSecure Erweiterung des JxtaUnicast, ausser das die Daten durch eine virtuelle TLS Verbindung zwischen den Endpunkten geschützt ist JxtaPropagate verteilte Pipes. Sendet one-to-many Nachrichten. Jeder Peer der eine Input Pipe vom Typ Propagate aktiviert hat empfängt Nachrichten die auf diese Pipe geschickt werden.

Pipe Advertisement Schema
P2P – JXTA – Pipe Binding API Pipe Advertisement Schema <xs:element name="PipeAdvertisment" type="jxta:PipeAdvertisment"/> <xs:complexType name="PipeAdvertisement"> <xs:sequence> <xs:element name="Id" type="jxta:JXTAID"/> <xs:element name="Type" type="xs:string"/> <xs:element name="Name" type="xs:string" minOccurs="0"/> </xs:sequence> </xs:complexType> <Id> This is a required element that uniquely identifies the pipe. Each pipe has a unique id. See IDs for description of JXTA Ids. <Type> This is an required element that defines the type of the pipe. The following types are currently defined: JxtaUnicast may not arrive at the destination, may be delivered more than once to the same destination, may arrive in different order. JxtaUnicastSecure may not arrive at the destination, may be delivered more than once to the same destination, may arrive in different order, but is encrypted using TLS. JxtaPropagate one to many pipe. <Name> This is an optional name that can be associated with a pipe. The name is not required to be unique unless the name is obtained from a centralized naming service that guarantee name uniqueness.

PipeService

Der Pipe Prozess Ich such mir jemanden zum reden Ich hab ein offenes Ohr, wer erzählt mir was Gruppe veröffentlicht Pipe Advertisement Listener Peer erstellt input Pipe aus Advertisement Talk Peer erstellt output Pipe, die an den listener Peer adressiert ist Talk Peer sendet Nachricht auf die Pipe Listener empfängt Nachricht Peer der Information möchte öffnet eine input Pipe Peer der Information möchte veröffentlicht seine Pipe Peer mit Daten öffnet output Pipe zur input Pipe Peer mit output Pipe sendet Daten

Verbinden von Pipes - Blind Pipe - Listener Pipe ist immer blind und akzeptiert Verbindung von jedem Peer - Blind Output Pipe - Blind Output Pipe with Listener - Blind Input Pipe - Blind Input Pipe with Listener - Peer-addressed Pipe - Adressed Output Pipe  Output Pipes können sowohl blind als auch explizit adressiert sein Blind output Pipes: haben als Aufrufparameter das advertisement und das timout, also wie lange sie auf eine Verbindung warten Wenn z.B. der Typ des Advertisements PipeService.UnicastType ist, dann schaut das System einfach nach demselben Pipe Advertisement das von irgendeinem anderen Peer angeboten wird, da ja kein spezieller Endpunkt spezifiziert ist. Wenn der Typ Propagate pipe ist, dann hören alle Peers in der Gruppe mit geöffneten Pipes die Nachrichten. Blind outputPipe with Listener: unterscheidet sich ein wenig von Blind output Pipes Der Hauptunter schied ist, dass wenn Peers gefunden sind, der Listener mit einer neuen output Pipe aufgerufen wird. Blind Input Pipe: unterscheiden sich ein wenig von output pipes, da sie nicht adressiert sind, sie sind also immer lind. Haben als Aufrufparameter nur das entsprechende Advertisement und warten dann auf eine Nachricht. Um eine Verbindung zu bekommen muss man die Methode waitFor Message aufrufen, die so lange blockiert bis eine output pipe oder ein anderer Peer versucht sich zu verbinden Blind Input Pipe with Listener: Die Input Pipe wird erzeugt, nur um auf eine Verbindung zu horchen. Bekommt als Aufrufparameter das Advertisement und den Listener Addressed output pipe: Mit einer adressierten Pipe schaut man nach einem Speziellen Peer. Die create Methode blockiert, bis der adressierte Peer verbunden ist. Wenn dies nicht in einer bestimmten Zeit geschieht misslingt die Aktion.

Pipes, Pipes, Pipes… - Bidirektionale Pipes - Der BidirectionalPipeService ist ein optionaler Service, mit dem (welch Wunder !) bidirektionale Pipes erzeugt werden können - Reliable Pipes - Mit dem ReliablePipeService können Nachrichten zuverlässig über Pipes gesendet werden - Nachrichten werden in der Reihenfolge empfangen in der sie auch gesendet wurden - Die Nachricht erreicht garantiert ihren Empfänger - Können auch verschlüsselt werden

Peer Endpoint Protocol API

Peer Endpoint Protocol
P2P – JXTA – Peer Endpoint API Peer Endpoint Protocol Nachrichtenaustausch zwischen Peers wird hauptsächlich von anderen Protokollen benutzt direkte Benutzung sinnvoll für Implementierung neuer Endpoint-Protokolle Implementierung eigener Pipes Überwachung bzw. Steuerung des Netzes Zugriff über Interface PeerGroup: EndpointService getEndpointService(); schlechter Name da TCP/IP Resolver = resolve  Peer Resolver API benutzt Suche xml messages (querys) mittels Rendezvous peers versendet empfangen (responses) Rendezvous Peer ausfallen (Traffic, Hack…) ablehnen (SourcePeer nicht in PeerGroup) keine Antwortgarantien da nicht garantierte Anfrageweiterleitung keine Antwortgarantien da keine Mitteilung über nicht vorhandene Antworten 48

Filter Listener zum Manipulieren oder Blockieren von Nachrichten
P2P – JXTA – Peer Endpoint API Filter Listener zum Manipulieren oder Blockieren von Nachrichten Registrieren in EndpointService void addIncomingMessageFilterListener( MessageFilterListener listener, String namespace, String name); Interface MessageFilterListener Message filterMessage(Message message, EndpointAddress srcAddr, EndpointAddress dstAddr); schlechter Name da TCP/IP Resolver = resolve  Peer Resolver API benutzt Suche xml messages (querys) mittels Rendezvous peers versendet empfangen (responses) Rendezvous Peer ausfallen (Traffic, Hack…) ablehnen (SourcePeer nicht in PeerGroup) keine Antwortgarantien da nicht garantierte Anfrageweiterleitung keine Antwortgarantien da keine Mitteilung über nicht vorhandene Antworten 49

Ping boolean ping(EndpointAddress addr);
P2P – JXTA – Peer Endpoint API Ping boolean ping(EndpointAddress addr); - prüft Erreichbarkeit eines Peers - ist unabhängig vom benutzten Protokoll - unterscheidet sich vom traditionellen Netzwerk-Ping einzige Information: true oder false Verlässlichkeit hängt vom Protokoll ab schlechter Name da TCP/IP Resolver = resolve  Peer Resolver API benutzt Suche xml messages (querys) mittels Rendezvous peers versendet empfangen (responses) Rendezvous Peer ausfallen (Traffic, Hack…) ablehnen (SourcePeer nicht in PeerGroup) keine Antwortgarantien da nicht garantierte Anfrageweiterleitung keine Antwortgarantien da keine Mitteilung über nicht vorhandene Antworten 50

Endpoint Messenger - zum Senden von Nachrichten an einen Endpoint
P2P – JXTA – Peer Endpoint API Endpoint Messenger - zum Senden von Nachrichten an einen Endpoint - Messenger getMessenger(EndpointAddress addr) - Interface Messenger boolean sendMessage(Message msg) throws IOException; void close(); - entspricht OutputPipe (→ Pipe Binding) schlechter Name da TCP/IP Resolver = resolve  Peer Resolver API benutzt Suche xml messages (querys) mittels Rendezvous peers versendet empfangen (responses) Rendezvous Peer ausfallen (Traffic, Hack…) ablehnen (SourcePeer nicht in PeerGroup) keine Antwortgarantien da nicht garantierte Anfrageweiterleitung keine Antwortgarantien da keine Mitteilung über nicht vorhandene Antworten 51

Endpoint Listener - Registrieren in EndpointService
P2P – JXTA – Peer Endpoint API Endpoint Listener - Registrieren in EndpointService boolean addIncomingMessageListener( EndpointListener listener, String serviceName, String serviceParam); - Interface EndpointListener void processIncomingMessage( Message message, EndpointAddress srcAddr, EndpointAddress dstAddr); schlechter Name da TCP/IP Resolver = resolve  Peer Resolver API benutzt Suche xml messages (querys) mittels Rendezvous peers versendet empfangen (responses) Rendezvous Peer ausfallen (Traffic, Hack…) ablehnen (SourcePeer nicht in PeerGroup) keine Antwortgarantien da nicht garantierte Anfrageweiterleitung keine Antwortgarantien da keine Mitteilung über nicht vorhandene Antworten 52

Beispiel Einführung Welche Protokolle gibt es?

Beispielprogramm: Peer Group Discovery
P2P – JXTA – Beispiel: Peer Group Discovery Beispielprogramm: Peer Group Discovery Programmablauf Verbinden mit Rendezvous-Peer Senden einer DiscoveryRequest-Message Auflistung aller Peers der gefundenen PeerGroups Quelle Sun Microsystems, Project JXTA 2.0: Java Programmers Guide, 2003, Seiten 39-43 schlechter Name da TCP/IP Resolver = resolve  Peer Resolver API benutzt Suche xml messages (querys) mittels Rendezvous peers versendet empfangen (responses) Rendezvous Peer ausfallen (Traffic, Hack…) ablehnen (SourcePeer nicht in PeerGroup) keine Antwortgarantien da nicht garantierte Anfrageweiterleitung keine Antwortgarantien da keine Mitteilung über nicht vorhandene Antworten 54

Start JXTA I P2P – JXTA – Beispiel: Peer Group Discovery
public class GroupDiscoveryDemo implements DiscoveryListener { static PeerGroup netPeerGroup = null; private DiscoveryService discovery; private RendezVousService rdv; private void startJxta() { try { netPeerGroup = PeerGroupFactory.newNetPeerGroup(); } catch ( PeerGroupException e) {...} schlechter Name da TCP/IP Resolver = resolve  Peer Resolver API benutzt Suche xml messages (querys) mittels Rendezvous peers versendet empfangen (responses) Rendezvous Peer ausfallen (Traffic, Hack…) ablehnen (SourcePeer nicht in PeerGroup) keine Antwortgarantien da nicht garantierte Anfrageweiterleitung keine Antwortgarantien da keine Mitteilung über nicht vorhandene Antworten 55

Start JXTA II P2P – JXTA – Beispiel: Peer Group Discovery
discovery = netPeerGroup.getDiscoveryService(); rdv = netPeerGroup.getRendezVousService(); //Wait until we connect to a rendezvous peer System.out.print("Waiting to connect..."); while (! rdv.isConnectedToRendezVous()) { try { Thread.sleep(2000); } catch (InterruptedException ex) {} } System.out.println("connected!"); schlechter Name da TCP/IP Resolver = resolve  Peer Resolver API benutzt Suche xml messages (querys) mittels Rendezvous peers versendet empfangen (responses) Rendezvous Peer ausfallen (Traffic, Hack…) ablehnen (SourcePeer nicht in PeerGroup) keine Antwortgarantien da nicht garantierte Anfrageweiterleitung keine Antwortgarantien da keine Mitteilung über nicht vorhandene Antworten 56

Discovery Message P2P – JXTA – Beispiel: Peer Group Discovery
public void run() { try { // Register as a DiscoveryListener discovery.addDiscoveryListener(this); while (true) { System.out.println("Sending a Dis... // look for any peer group discovery.getRemoteAdvertisements(null, DiscoveryService.GROUP,null,null,5); ... // 60 Sekunden warten } schlechter Name da TCP/IP Resolver = resolve  Peer Resolver API benutzt Suche xml messages (querys) mittels Rendezvous peers versendet empfangen (responses) Rendezvous Peer ausfallen (Traffic, Hack…) ablehnen (SourcePeer nicht in PeerGroup) keine Antwortgarantien da nicht garantierte Anfrageweiterleitung keine Antwortgarantien da keine Mitteilung über nicht vorhandene Antworten 57

Discovery Listener I P2P – JXTA – Beispiel: Peer Group Discovery
public void discoveryEvent(DiscoveryEvent ev){ DiscoveryResponseMsg res = ev.getResponse(); String name = "unknown"; // Get the responding peer's advertisement PeerAdvertisement peerAdv = res.getPeerAdvertisement(); // some peers may not respond with peerAdv if (peerAdv!=null) name = peerAdv.getName(); System.out.println (" Got a Di..." + name); schlechter Name da TCP/IP Resolver = resolve  Peer Resolver API benutzt Suche xml messages (querys) mittels Rendezvous peers versendet empfangen (responses) Rendezvous Peer ausfallen (Traffic, Hack…) ablehnen (SourcePeer nicht in PeerGroup) keine Antwortgarantien da nicht garantierte Anfrageweiterleitung keine Antwortgarantien da keine Mitteilung über nicht vorhandene Antworten 58

Discovery Listener II P2P – JXTA – Beispiel: Peer Group Discovery
// now print out each discovered peer group PeerGroupAdvertisement adv = null; Enumeration enum = res.getAdvertisements(); if (enum != null ) { while (enum.hasMoreElements()) { adv = (PeerGroupAdvertisement) enum.nextElement(); System.out.println(...+ adv.getName()); } schlechter Name da TCP/IP Resolver = resolve  Peer Resolver API benutzt Suche xml messages (querys) mittels Rendezvous peers versendet empfangen (responses) Rendezvous Peer ausfallen (Traffic, Hack…) ablehnen (SourcePeer nicht in PeerGroup) keine Antwortgarantien da nicht garantierte Anfrageweiterleitung keine Antwortgarantien da keine Mitteilung über nicht vorhandene Antworten 59

Main P2P – JXTA – Beispiel: Peer Group Discovery
static public void main(String args[]) { GroupDiscoveryDemo myapp = new GroupDiscoveryDemo(); myapp.startJxta(); myapp.run(); } schlechter Name da TCP/IP Resolver = resolve  Peer Resolver API benutzt Suche xml messages (querys) mittels Rendezvous peers versendet empfangen (responses) Rendezvous Peer ausfallen (Traffic, Hack…) ablehnen (SourcePeer nicht in PeerGroup) keine Antwortgarantien da nicht garantierte Anfrageweiterleitung keine Antwortgarantien da keine Mitteilung über nicht vorhandene Antworten 60

Ausgabe P2P – JXTA – Beispiel: Peer Group Discovery
Waiting to connect to rendezvous...connected! Sending a Discovery message Got a Discovery Response [3 elements] from peer : unknown Peer Group = football Peer Group = mygroup Peer Group = baseball Got a Discovery Response [2 elements] from ... Peer Group = testgroup1 Peer Group = soccer schlechter Name da TCP/IP Resolver = resolve  Peer Resolver API benutzt Suche xml messages (querys) mittels Rendezvous peers versendet empfangen (responses) Rendezvous Peer ausfallen (Traffic, Hack…) ablehnen (SourcePeer nicht in PeerGroup) keine Antwortgarantien da nicht garantierte Anfrageweiterleitung keine Antwortgarantien da keine Mitteilung über nicht vorhandene Antworten 61

P2P – JXTA – Quellen Daniel Brookshier, Darren Govoni, Navaneeth Krishnan, Juan Carlos Soto: JXTA: Java™ P2P Programming Sams Publishing, March 22, Oliver Steinhauer: JXTA Seminar, FU Gießen-Friedberg, SS03 Kai Wolter: JXTA, Universität Paderborn, 2002 Brendon J. Wilson, JXTA, New Riders, 2002

Nicole Hänelt, Mike Rohland, Julia Schenk, Rafael Grote
P2P Seminar – JXTA im Detail The End… Nicole Hänelt, Mike Rohland, Julia Schenk, Rafael Grote

mit Java implementiert (Java 2 Standard Edition)

Ähnliche Präsentationen

Präsentation zum Thema: "mit Java implementiert (Java 2 Standard Edition)"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback

Anmelden

Anmeldung über soziales Netzwerk:

mit Java implementiert (Java 2 Standard Edition)

Ähnliche Präsentationen

Präsentation zum Thema: "mit Java implementiert (Java 2 Standard Edition)"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback