Mobile P2P Web 3.0 Anwendungen entwickeln Programmieren mit dem Shark Framework

Transkript

1 Mobile P2P Web 3.0 Anwendungen entwickeln Programmieren mit dem Shark Framework (Version 0.9) Dr. Thomas Schwotzer 31. August 2011

2 2

3 Inhaltsverzeichnis 1 Vorwort 7 2 Grundkonzepte WWW und Shark Einstieg Interesse Wissen Alice und Bob interessieren sich für Java Knowledge Exchange Protocol (KEP) Alle Facetten eines Interesses Semantic Tags Peer Semantic Tags (PST) Time Semantic Tag (TST) Geo Semantic Tag (GST) Semantic Tag Sets Plain Semantic Tag Sets Taxonomien Semantic Net Set Austausch von Interessen und Wissen Programmieren mit Shark Entwicklungsumgebung aufsetzen Hello Alice, hello Bob Alice Bob Der Standard Knowledge Port Die Wissensbasis (SharkKB) Semantic Tags (ST) Peer Semantic Tag (PST) Time Semantic Tag (TST) Geo Semantic Tag (GST) Das Any Semantic Tag Context Coordinates (CC) Context Points (CP)

4 4 INHALTSVERZEICHNIS Informationen Properties Semantic Tag Sets Plain Semantic Tag Set Interesse AnchorSet Hintergrundwissen Die Shark Engine Protokolle zu- und abschalten Distributed Context Space Fragmentierung Fragmentierung von Plain Semantic Tags Sets Fragmentierung von Taxonomien Fragmentierung von Semantic Nets Kontextualisierung von Semantic Tag Sets Interesse: Hintergrundwissen und Anker Fragmentierung von Geo Semantic Tags Fragmentierung von Time Semantic Tags Gemeinsames Interesse ermitteln Wissen extrahieren Die Geometrie des Context Spaces Interface Hierarchie des Context Spaces Knowledge Ports Die Klasse AbstractKP Die Klasse KnowledgePort Aktualisierung des Interests Extraktion von Wissen parametrisieren Assimilation / Lernen parametrisieren Eigene KP implementieren Die Klasse KEPResponse Empfänger des Responses Nutzung eines Relais Die Shark Knowledge Base Listener In-Memo-Implementierung In-Memo Knowledge In-Memo Interesse FS-Implementierung Protokolle Address Strings Protokoll aktivieren Geplante Protokolle

5 INHALTSVERZEICHNIS 5 8 Die Shark Engine KP Verwaltung Protokollverwaltung Sensoren / Environment Peer Sensor Geo Sensor Time Sensor Pseudointeresse erzeugen Plattformspezifische Shark Engines Die J2SE Shark Engine Die Android Shark Engine Die J2ME Shark Engine Regeln für den Bau von Anwendungen 89

6 6 INHALTSVERZEICHNIS

7 Kapitel 1 Vorwort Sie haben das Shark Entwicklerhandbuch in Ihren (virtuellen) Händen. Aber bevor irgendetwas zum Buch und dem Framework gesagt werden soll, will ich etwas vorausschicken: Das Shark Framework und dieses Buch würde es ohne die Förderung des Bundesministeriums für Bildung und Forschung (BMBF) der Bundesrepublik Deutschland nicht geben. Dank einer dreijährigen Förderung ( ) konnte das System realisiert werden. Ich bin dafür sehr sehr dankbar! Ich will nicht auf die Geschichte von Shark eingehen, nur in aller Kürze. Shark ist durch eine Theorie und sogar eine kleine Algebra unterlegt, die ich in meiner Dissertation entwickelt und dargelegt habe. Shark ist ein minimalistisches P2P System: Peers haben nur zwei Datenstrukturen, die sie austauschen können: Interessen und Wissen. Zugegeben, die Strukturen erscheinen auf den ersten Blick komplex, aber wenn man genauer hinschaut, wird man erkennen, dass es einfach nur lang ist, aber nicht komplex. Die Länge ergibt sich aus den semantischen Einfügungen, die notwendig sind, wenn man ein P2P System für spontane Netze bauen will. In meiner Dissertation konnte ich zeigen, dass ich mit dem minimalistischen Konzept einige Klassen von Webanwendungen bauen kann und auf Server verzichten kann. Das geht auch in spontanen und damit mobilen Netzen, die auf Kurzstreckenfunk basieren. Der Gedanke hat mich elektrisiert und nicht mehr losgelassen. Mit diesem P2P Konzept kann ich Social Networks, Blogs, auch sowas wie Twitter, die üblichen Foren, auch Groupware und Dinge wie Dropbox und eine Fülle von ortsbasierten Diensten bauen aber ohne Server. Shark Anwendungen sehen aus wie Webanwendungen, tatsächlich nehmen wir auch HTML für einige Apps. Aber die Daten liegen lokal und die HTML-Seiten werden lokal erzeugt. Shark Apps sehen z.t. aus wie Web Apps, sie sind es aber nicht. Nichts in Shark wird von irgendeiner Websuchmaschine erfasst. Shark hat keinen zentralen Server und kann daher schwerlich abgestellt werden. Es kann genauso gut gehackt werden wie das Internet gar nicht. Es gibt keine Zentrale, als auch keinen Ort, wo alle Daten liegen. Datenmissbrauch und DoS Attacken laufen 7

8 8 KAPITEL 1. VORWORT ins Leere. Das klingt alles wunderbar, aber Wissenschaftler reden viel. Praxis muss her habe ich begonnen, die Theorie zu implementieren und ab 2009 konnte ich mir Hilfe in Form von Mitarbeitern einstellen. Ich muss und will sehr gern Matthias Fischer danken, der das Projekt während seines gesamten Bachelorstudiums begleitet hat und danach als Mitarbeiter weitermachte. Er hat nicht nur viel Code geschrieben, sondern auch meinen Code gelesen und verbessert. Ohne ihn wären das System nicht so wie es ist. Das Programmiermodell war lange nicht so klar wie es jetzt ist und die vielen gemeinsamen Diskussionen und eine gewissen Sturheit von allen hat es fertig werden lassen. Das ist wunderbar. Das Handbuch schreibe ich selber, d.h. alle Fehler sind mir anzukreiden. Aber zum Status des Buches. Es ist momentan in einem ganz guten Zustand, aber nicht fertig. Das Buch ist bis Ende Kapitel 3 mehrfach durchgesehen worden und ich denke, wenigstens bis dahin kann man es nutzen. Die Kapitel 4 und aufwärts sind bisher nur zweimal durch mein eigenes Lektorat gegangen und ich weiß, dass man schwerlich eigenen Text lektorieren kann. Ein echtes Lektorat wird es nach mit der 1.0 dieses Buches gehen. Diese Kapitel sind nicht falsch, auch die Codefragment, die gezeigt werden, funktionieren genau so. Es gibt auch noch und leider Lücken. Ich habe noch Zweifel, ob sich das Buch so gut liest, wie es sein sollte und ich bin mir sicher, dass es viele Sätze ohne Ende und viele dieser kleinen Fehler gibt, die den Lesefluss stören. Und es gibt viel zu viele Redundanzen. Bücher werden aber einem gewissen Arbeitsstand wieder kleiner. Dieser Schritt fehlt hier noch. Die Arbeit an dem Buch werde ich Anfang 2012 wieder aufnehmen. Ab Oktober 2011 mache ich aber erste Schulungen für Shark. Wir haben zwei Pilotkunden. Es entsteht Schulungsmaterial, das ich auch gern zur Verfügung stelle. Dieses Material wird Teil des Buches werden, das ich im März 2012 auf der CeBIT in Hannover verteilen kann. Es gibt seit diesem Sommer ein Release der Software: Ja, mit Shark kann man programmieren und wir tun das. Just in diesem Moment arbeiten wir an zwei Anwendungen für Shark: CommunityNet, eine Mischung aus Social Network und Dropbox und Shark Longitude, einem P2P System, das die eigene Position anderen mitteilt etc. Man kennt das vermutlich. Es arbeitet aber ohne Server, so dass nur die die eigenen Koordinaten empfangen, die sie auch bekommen sollen. Und man kann Daten mit Orten verbinden, d.h. man kann ein Handy wie eine Wünschelroute benutzen und Daten suchen und auch finden, wenn jemand vorher welche hinterlegt hat. Das ist alles sehr positiver Stress. Ich freue mich auch in solchen Zeiten immer über neue Interessenten. Melden Sie sich einfach: Tippen Sie meinen Namen in ihre bevorzugte Suchmaschine und Sie finden Kontaktdaten. Besuchen Sie mich bitte spätestens im März 2012 auf der CeBIT in Hannover. 31. August 2011 in Frankfurt (Oder) Prof. Dr. Thomas Schwotzer

9 Kapitel 2 Grundkonzepte 2.1 WWW und Shark Jeder kennt das WWW. Das Konzept ist denkbar einfach: Ein Dokument wird auf einem Webserver hinterlegt und jeder der Zugriff auf den Webserver hat, kann das Dokument einsehen. Das war der Beginn 1989 und baute auf dem Konzept der damals üblichen und recht sperrig zu bedienenden FTP-Server auf. Dokumente müssen aber nicht statisch sein. Daten können aus Datenbanken abgerufen werden und just in dem Moment, in dem jemand den Webserver anspricht, wird ein aktuelle Dokument mit aktuellen Daten geliefert. Webanwender können auch Daten zum Server senden. Dadurch werden E- Commerce Anwendungen möglich und natürlich Social Networks. Abbildung 2.1 skizziert das Vorgehen. Der Anwender sitzt üblicherweise vor einem WWW-Browser und klickt etwas an. Der Browser sendet ein Request zum Webserver. Dort wird ein Dokument erstellt und das geschieht mittels einer Businesslogik 1. Der Webserver reagiert immer mit einem Response und sendet ein Dokument. Bei Informationsdiensten wird das ein Text sein, den man lesen kann, bei einen Verkaufszenario kommt ggf. nur eine Seite die sich für die Zahlung bedankt. Gerade bei Verkaufsvorgängen ist das Dokument eher ein Seiteneffekt. Das interessante ist, dass der Server eine finanzielle Transaktion durchgeführt hat. Das hat wiederum nichts mit WWW-Technologie zu tun. Wir wollen uns aber nicht mit E-Commerce beschäftigen, sondern mit Systemen zur Informationsverteilung und insbesondere mit Systemen in denen viele Nutzer vielen anderen Nutzern etwas mitteilen wollen. Social Networks sind solche Anwendungen. Auch hier wird in aller Regel WWW-Technologie eingesetzt. Abbildung 2.2 illustriert die grobe Struktur. Es gibt tausende sehr erfolgreiche Anwendungen, die nach diesem Prinzip arbeiten. Es gibt aber auch Kritik 1 Das Wort Businesslogik hat sich als Bezeichnung etabliert und beschreibt den Programmcode, der auf einen Request reagiert und ein Ergebnis produziert. Er kann auch gern um nicht-kommerziellen Zwecken dienen. 9

10 10 KAPITEL 2. GRUNDKONZEPTE Abbildung 2.1: Webserver an dieser Struktur. Die wichtigsten Punkte sollen zusammen gefasst werden: Der Webserver ist ein Bottleneck, ein Single Point of Failure. Ist der Webserver nicht verfügbar, so geht die gesamte Anwendungen nicht mehr. Das ist so unüblich nicht, auch in großen weltweiten Anwendungen. Im Sommer 2011 fielen Server von Amazon in Irland aus, was zum Ausfall einer ganzen Reihe von Cloud-Diensten führte. Zum Beispiel im arabische Frühling nutzten einige Regierungen dieses Prinzip, indem sie den Zugang zu dem Server verhinderten und damit Kommunikationskanäle zu unterbinden. Während der Wahl im Iran 2009 nutzten Demonstranten den Dienst Twitter zu Koordination. Der hatte allerdings Wartungszeiten, die die Kommunikation über Stunden unmöglich machten. Man kennt solche zentralistischen Strukturen: In den 1960er Jahren standen teure Großrechner in den Kellern der Unternehmen. Mitarbeiter könnten über lange Kabel und billige Terminals auf die Rechner zugreifen. Der Großrechner war ein Single Point of Failure. Fällt er aus, geht nichts mehr. Man hatte aber keine Alternativen. Das änderte sich in den folgenden Jahrzehnten und bereits in den 1970er Jahren fasste man den Entschluss, ein dezentrales System zu bauen, das Internet. Aus dieser Perspektive ist die Architektur der meisten Webanwendungen ein Rückfall in die Prä- Internetzeit: Es gibt die gleiche Struktur wie bei den guten alten Großrechnern. Der Server muss in aller Regel Zugriff auf unverschlüsselte Daten haben. In einem Social Network muss er die Interessen und Wünsche der Nutzer analysieren können, um neue Freunde usw. vorschlagen zu können. Man muss dem Betreiber der Server trauen. Auch verschlüsselte Dokumente lassen sich entschlüsseln. In der Kryptoanalyse wissen wir, dass es gut ist, wenn wir viele Dokumente haben, die mit gleichen Schlüsseln verschlüsselt sind, dann kommt man schneller voran. Man muss dem Betreiber eines Servers vertrauen und je wichtiger die Dokumente, umso größer muss das Vertrauen sein. Diese Vertrauen wird in aller Regelmäßigkeit enttäuscht. Die Presse ist nahezu monatlich mit einem neuen Skandal beschäftigt. Sei es, dass Nutzerdaten zweckentfremdet vom Betreiber genutzt wurde, sei es, dass in

11 2.1. WWW UND SHARK 11 Abbildung 2.2: Zentrale Anwendungen mit WWW Server eingebrochen wurde, sei es, dass Nutzer das Kleingedruckte der AGBs dann doch nicht richtig gelesen haben und sich wundern, warum private Bilder plötzlich in gänzlich anderen Zusammenhängen auftauchen. Es hat seinen Grund, dass einige Regierungen ihren Angestellten verbieten bestimmte Dienste zu nutzen, weil die Daten in einem anderen Land verarbeitet werden und man nicht sicher ist, ob Missbrauch betrieben wird. Und dazu gehören auch Gründungsmitglieder der EU. Der Zugriff auf das WWW erscheint kostenlos und immer möglich. In der mobilen Form fällt aber verstärkt auf, dass das nicht stimmt. Man möge in einer Tiefgarage, in einen fahrenden Zug oder auf einer Computermesse einmal versuchen, Webdienste mobil zu nutzen. Das scheitert mit schöner Regelmäßigkeit, weil man kein Netz hat, weil das Handover in schnell beweglichen Systemen ein Problem ist und bleibt oder weil es einfach zu viele Nutzer gibt. Das mobile Netz ist nicht immer da, es hat schwankende Bandbreiten und es ist nicht so redundant ausgelegt, dass man nicht regelmäßig merkt, dass es nicht da ist. Das wird so bleiben, denn eine deutlich verbesserte Ausfallsicherheit, deutlich erhöhte Kapazitäten würden Preise erzeugen, die ein breites Publikum nicht zahlen wird. Das Problem wird aber erst dann sichtbar, wenn man jetzt sofort eine Information braucht, wenn man also synchron auf einen Server zugreifen muss. Die Alternative ist einfach und mit der Einführung des Internet bekannt:

12 12 KAPITEL 2. GRUNDKONZEPTE Daten sollen unterschiedliche Wege gehen können und sich an veränderte Gegebenheiten anpassen können. Shark nimmt die Idee des Internet auf und transportiert sie in die Welt des WWW und die Welt. Das Konzept der Informationsverteilung ist genau umgekehrt: Die Daten bleiben auf dem Maschinen ihrer Nutzer. Anders gesagt, sie bleiben auf den Smartphones, Tablets und PCs der Anwender. Shark erlaubt aber auch zu beschreiben, unter welchen Bedingungen die Daten ausgetauscht werden sollen, direkt von einem Gerät zum anderen. Das ist ein Peer-to-Peer Konzept. Jedes Shark-Peer hält seine eigenen Daten. Ein Shark-Peer ist Software auf einem Handy, einem PC, was auch immer. Peers kommunizieren direkt. Die Programmierung von Shark ist anderes als im WWW:Man programmiert nicht mehr den Austausch der Daten. Das ist mühsame und in der Regel langweilige Arbeit. In Shark definiert man, wann ein Austausch erfolgen soll. Die Businesslogik liegt auf jedem Peer, also z.b. jedem Handy. Shark kann zum Bau vom Pull- und Push-Diensten genutzt werden. Shark hat ein semantisches Datenmodell, mit dem wir uns ausführlich beschäftigen werden. Shark-Peer kommunizieren, verglichen mit HTTP, mit einem deutlich einfacheren Protokoll: Das Shark-Protokoll hat lediglich zwei Methoden, HTTP hat ein Dutzend. KEP Nachrichten wiederum können über beliebige Protokolle verteilt werden. Wir unterstützen TCP, , aber auch HTTP und Bluetooth. Je nach Konfiguration benimmt sich Shark wie eine TCP-Overlay-Anwendung oder eine pure mobile Anwendung mit Bluetooth. Shark ist multiprotokollfähig und benötigt nicht einmal Internet zur Kommunikation; Kurzstreckenprotokolle tun es auch. Shark-Peer können sich zwei Dinge senden: ein Interesse und Daten. Mit einem Interesse wird beschrieben, worüber, wann zu welchen Thema an welchem Ort man sich mit wem austauschen mag. Peers können beliebig auf den Empfang eines Interessen reagieren. Sie können machen was sie wollen, es ignorieren, weiterleiten, speichern, ein anderes Interesse senden oder auch Daten senden. Daten sind wie im Web beliebige digitale Inhalte. Shark kümmert sich nicht um die Inhalte. Shark speichert aber jederzeit wann, von wem, wo etc. die Daten empfangen wurden. Wir sprechen von einem Kontext in dem Zusammenhang. Shark Peers sind völlig frei in der Kommunikation. Sie können z.b. Nachrichten ignorieren, die nicht signiert sind. Sie können Nachrichten verwerfen, die zwar signiert sind aber von einem Peer mit dem man nichts zu tun haben mag. Shark erlaubt das Signieren und Verschlüsseln. Und da Peers direkt kommunizieren, ist eine End-zu-End-Verschlüsselung möglich - das geht bei den zentralistischen Systemen nicht. Abbildung 2.3 skizziert ein Shark basiertes P2P System. Die Peer kommunizieren direkt. Der meisten Datenverkehr besteht im Austausch von Interessen. An einer Stelle reagiert ein Peer (D) und sendet einem anderen (A) ein Dokument. Das Dokument kann verschlüsselt sein, so dass nur A es entschlüsseln kann. Weder das Dokument noch die Interessen liegen auf einem Server. Will man den Datenverkehr in Shark basierten Netzen abhören, muss man jede ein-

13 2.2. EINSTIEG 13 Abbildung 2.3: Shark Peers kommunizieren zelne Verbindung abhören. Und da wir auch Bluetooth nutzen können, wird das schwierig. Will man alle Daten eines Shark Netzes bekommen, könnte man alternativ auch alle Geräte hacken. Alle! Man müsste bspw. aller Handys einer Gruppe von Menschen habhaft werden. Das ist praktisch unmöglich oder wenigstens um mehrere Größenordnungen aufwendiger, als einen Server zu hacken und die dort liegenden Daten mal so eben anderweitig zu nutzen. Shark ist ein Framework zum Bau dezentraler semantischer P2P Systeme. Es eignet sich hervorragend zum Bau von Systemen, in denen Informationen verteilt werden, ob mobil oder lokal und mit beliebigen Protokollen. Shark eignet sich nicht, um ein Shopping-Portal zu bauen. Das bedarf einer zentralen Verkaufseinheit (einem Server) an die sich Clients wenden. 2.2 Einstieg Shark ist ein P2P System. Es geht davon aus, dass Peers direkt miteinander kommunizieren können. Sie tauschen dabei lediglich zwei Dinge aus: Interessen und Wissen. Beide sollen zunächst grob erklärt werden, um sie später im Detail vorzustellen Interesse Ein Interesse beschreibt den Wunsch nach Kommunikation. Was muss erfüllt sein, dass ein Peer sich mit einem anderen Peer unterhält? Das steht in einem Interesse. Ein Interesse erlaubt die Beschreibung worüber, mit wem an welchem Ort und zu welcher Zeit man sich austauschen mag. Man kann auch sagen, ob man Informationen sucht, anbietet oder beides. Man kann beliebig viele Interessen haben und mit jedem anders umgehen.

14 14 KAPITEL 2. GRUNDKONZEPTE Interessen beschreibt ein Peer lokal bei sich. Kein anderes Gerät muss es sehen. Damit unterscheidet sich Shark schon einmal von Web-Anwendungen und deren Server. Ein Peer kann sich auch generell entscheiden, ein Interesse niemals zu versenden. Das ist ein nicht publiziertes Interesse (non-published interest). Hätte kein Peer ein Interesse publiziert, käme es zu keiner Kommunikation, denn kein Peer wüste von einem anderen. Ein Peer muss daher anfangen und einem anderen Peer ein Interesse übermitteln. Wir sprechen nun von einem publizierten Interesse (published interest). Es wurde anderen bekannt gemacht. Shark definiert nicht, wie ein Peer auf den Empfang eines Interesses reagieren soll. Diese Businesslogik kann in Knowledge Ports (KPs) implementiert werden. Shark bietet einige KPs an, die lediglich konfiguriert werden müssen. Der wichtigste ist und trägt daher auch seinen Namen der Standard KP auf den wir noch ausführlich zu sprechen kommen Wissen Wissen ist in Shark per Definition Information in einem Kontext. Kontext ist auch das, was wir bereits beim Interesse beschrieben haben: Zu welchem Thema, an welchem Ort zu welcher Zeit von wem usw. wurde Informationen übermittelt. Informationen sind digitale Daten beliebigen Inhalts. Das ist wie im Web. Man kann hier wie dort Texte, HTML-Files, MP3 usw. übermitteln. Informationen werden aber in Shark immer im Kontext gespeichert. Gerade in Informationssystemen ist es interessant zu wissen, wer was sendete. Shark speichert das. Wissen wird mit dem KEP Kommando insert übertragen. Mit dem Kommando kommen Informationen (das können auch ganze Bündel von Informationen sein) mit ihrem jeweiligen Kontext. Das sendende Peer ist sich auch durchaus bewusst, dass es das Wissen sendet. Es legt auch sehr bewusst den Kontext offen, unter dem es das tut. Das Speichern des Kontextes durch das empfangende Peer ist daher allen bekannt. In Shark muss man aber auch nur das übertragen, was man will - es ist ein P2P System, daher kann ist diese Form des Nichtvergessens legitim. Wir sprechen manchmal auch von der Übermittlung von Wissenspartikeln. Dahinter liegt ein Bild:man könnte sich ein Peer auch wie ein Atom denken, dass in einer bestimmten Umgebung, einen Kontext und durch die Nachbarschaft anderer Peers zum Emitieren an dieser Stelle von Wissen angeregt wird. Wenn man so will, ist der Wissensaustausch eine Emission von Wissens- Quanten, die von anderen Peers absorbiert werden können in Shark sprechen wir von Assimilation. Konkret reden wir aber in Shark von Context Points (CP) an die Informationen gebunden sind. Ein CP beschreibt exakt ein Thema, einen Sender, einen Ort, eine Uhrzeit usw. An ihn können Informationen gebunden sein und übertragen werden.

15 2.2. EINSTIEG 15 Abbildung 2.4: Context Point (CP) Alice und Bob interessieren sich für Java Ein erstes kleines Szenario soll den tieferen Einstieg in Shark illustieren und bei der Gelegenheit sollen auch gleich Alice und Bob vorgestellt werden. Beide bewohnen eigentlich das Reich der Kryptografie in dem sie regelmäßig versuchen, Daten auszutauschen. Sie sind in diesem Buch zu Besuch, um das gleiche zu tun 2. Alice und Bob mögen sich für Java interessieren. Alice will Informationen dazu senden und zwar an jeden beliebigen. Bob ist der Kommunikationspartner ebenfalls egal, genauso wie Ort und Zeit der Kommunikation. Beide sind damit typische Nutzer an einem stationären Rechner. Das Interesse von Alice kann verkürzt so notiert werden: [topic: Java, peer: Alice, remotepeer: Any, direction:out] Sie (peer:alice) interessiert sich für tt topic: Java. Die will mit beliebigen Peers (remotepeer: Any) kommunzieren, aber sie will dabei Wissen senden und nicht empfangen (direction: out). Bob würde schreiben: [topic: Java, peer: Bob, remotepeer: Any, direction:in] Bobs Interesse sieht sehr ähnlich aus. Er ist natürlich Bob (peer: Bob) und will Wissen empfangen (direction: in). So weit so gut. Bleiben nun beide ruhig, passiert gar nichts. Eine/r von beiden muss dem/der anderen das eigene Interesse mitteilen. Ziehen Sie als Leser nun die Stirn in Falten? Wieso ist das so umständlich? In Webanwendungen hinterlegt man sein Profil und dann sieht jeder andere das und los gehts mit dem Finden neuer Freunde. Warum soll das auch noch gut sein, wenn das nicht so ist? Wir haben zwei Antworten darauf: 2 Mallory, Eve und andere Unholde haben wir aber nicht mitgenommen wir hoffen, dass Alice und Bob den Aufenthalt in diesem Buch daher als angenehmer empfinden als in kryptografischen Werken in denen sie ständig von verfälschenden, abhörenden und anderen unangenehmen Zeitgenossen belästigt werden. Wir wünschen Alice und Bob eine erholsame Zeit in diesem Buch.

16 16 KAPITEL 2. GRUNDKONZEPTE 1. Es ist sicherer. Shark erlaubt es, Interessen zu formulieren, die eben nicht alle anderen sehen sollen. Man kann sie auch erst einmal gänzlich für sich behalten. Wir werden sehen, dass auch nicht publizierte Interessen Businesslogik auf einem Peer in Gang setzen können. Shark macht es möglich, dass Interesse nur an spezielle Peers gesendet wird, die man kennt, deren Identität man mittels Zertifikaten geprüft hat oder was auch immer. In Shark muss man nicht irgendeinem Server vertrauen man muss sich selbst vertrauen und dem Empfänger der Nachricht. 2. Und noch ein ganz plattes Argument hinterher: Das haben wir schon immer so gemacht :) Im Ernst, menschliche Kommunikation geht in der Regel von Mensch zu Mensch. Nur Publikationen (Bücher, Informationsportale etc.) gehen 1-n, d.h. von einem zu vielen. Social Networks sind ein perfektes Beispiel für n-n Kommunikation mit dem zentralen Unterschied, dass in der Mitte einer im Prinzip immer mithört, der Server. Schlimmer noch: Die Fragen und Antworten kann man nicht selten auch noch googln. Wenn sich also jemand nach einem Mittel für [bitte setzen Sie hier eine peinlich und besser private zu behandelnde kleine Krankheit ein] erkundigt, so kann man Frage wie Antwort jederzeit und über Jahre und Jahrzehnte hinweg finden. Das ist peinlich. Bei Shark hört niemand mit und Kommunikation zwischen Shark Peer taucht auch in keinem Suchmaschinen-Index auf, weil Shark keine Webanwendung ist - sie sieht z.t. nur so aus. Man muss ich in Shark schon richtig Mühe geben, um die Daten ins WWW zu bringen. Aus Versehen passiert hier nichts mehr. Das ist ein Vorteil, wenn man Privatsphäre ein wenig schätzt. Nehmen wir also an, dass Bob sein Interesse an Alice sendet. Bob hat sich ihr offenbart und Alice weiß nun eine ganze Menge: Es gibt Bob. Bob interessiert sich für Java. Bob will Informationen zu dem Thema von jedem beliebigen haben. Was kann Alice nun tun? Was sie will. Sie könnte sich das einfach merken, um es anderen Peers mitzuteilen. Sie könne auch ihrer Freundin Clara, dieses Interesse senden. Das Standardverhalten, das in Standard KP in Shark implementiert ist, geht aber so: Alice prüft zunächst, ob das empfangen Interesse eine gemeinsame Schnittmenge mit irgendeinem eigenen Interesse hat. Die Schnittmengenerzeugung erfolgt über eine Methode, die wir Kontextualisierung nennen und die Programmierern zur Verfügung steht, die man aber auch nicht kenne muss, wenn man den Standard KP benutzt. Grob gesagt, wird das Interesse Schritt für Schritt geprüft und das passiert in dem Fall im Alice Peer, weil sie das Interesse von Bob erhielt: Gibt es eine Deckung im Interesse? Ja, beide interessieren sich für Java. Gibt eine Deckung in den Peers? Ja, Alice will mit jedem kommunizieren und

17 2.2. EINSTIEG 17 Abbildung 2.5: Alice sendet Bob etwas zum Thema Java Bob ist ein Peer. Bob will seinerseits auch mit jedem reden und Alice fällt ebenfalls in diese Menge. Bob will etwas haben, Alice etwas senden. Das passt. Das Ergebnis auf Alice Seite sieht damit so aus: [topic: Java, peer: Alice, remotepeer: Bob, direction:out] Hätte übrigens Alice ihr Interesse an Bob gesendet, hätte Bob folgende ermittelt: [topic: Java, peer: Bob, remotepeer: Alice, direction:in] Wir nennen Interessen, die als Schnitt zweier Interesse zweier Peers entstehen wechselseitige Interessen (mutual interest). Sie zeigen an, wofür sich beide interessieren. Aber zurück zu Alice. Sie will Informationen senden und sie kennt nun auch Thema und Empfänger. Sie nutzt daher ihre Datenbank im Peer, ermittelt passende Informationen, hängt den Kontext an (das ist in dem Fall direkt das wechselseitige Interesse) und sendet das Wissen an Bob. Bob empfängt das Wissen und hat einige gelernt: Es gibt Alice. Alice sendet ihm Informationen zum Thema Java Es soll folgendes betont werden: Angenommen, Alice würde sich ebenfalls für Hochseefischen interessieren, dann würde Bob nichts darüber erfahren. Warum? Weil Bob sich nicht dafür interessiert und Alice den Durchschnitt berechnet hat. Bei der Ermittlung des Schnitts wird geprüft, ob das empfangene Interesse z.b. Themen enthält, die zu eigenen Themen passen. Nur diese kommen in das wechelseitige Interesse. Nicht-publizierte Interessen tragen also durchaus und wertvoll zur Businesslogik eines Peers bei. Zurück zum Bob, der Wissen von Alice erhielt. Was kann er tun? Wenn Bob Alice vertraut, dann kann er die Daten in seine Datenbank übernehmen. Das ist das Standardverhalten. Abbildung 2.5 illustriert den Vorgang.

18 18 KAPITEL 2. GRUNDKONZEPTE Knowledge Exchange Protocol (KEP) Die technische Basis der Kommunikation zweier Geräte sind Protokolle. Die Basis des WWW ist HTTP. Shark hat ebenfalls ein eigenes Protokoll. Es heißt Knowledge Exchange Protocol (KEP). Das Protokoll hat zwei Funktionsprimitive: Expose sendet ein Interesse an ein anderes Peers. Das Interesse verlässt so das Peer und kann vom empfangenen Peer bearbeitet werden. Wenn ein Interesse so verteilt wurde, sprechen wir in Shark von einem publizierten Interesse. Es ist anderen Peers bekannt, siehe Diskussion oben. Insert sendet Wissen an ein anderes Peer. Das empfangene Peer kann mit Wissen - genau wie mit einem Interesse - beliebig verfahren. Es kann sich das Wissen merken. Wir sprechen in Shark von der Assimilation von Wissen, Details zu diesem Prozess folgen weiter hinten 3. Ein Peer kann das Wissen aber auch verwerfen oder es sofort an andere Peers weitergeben, ohne sich damit zu beschäftigen. Es kann tun, was es will. Es gibt verschiedenen Protokollbindungs für KEP, d.h. KEP Nachrichten können auf unterschiedlichen Protokolle transportiert werden. Das ist ein Alleinstellungsmerkmal von Shark gegenüber anderen P2P Systemen, die sich nicht selten als Overlay-Netzwerk auf einem Protokoll, meistens TCP/IP verstehen. KEP ist anders. Eine Kommunikation zwischen Shark Peers kann zwischen den Protokollen wechseln. So kann z.b. ein Interesse über verschickt werden, ein anderes über Bluetooth. Das Wissen kann dann über eine HTTP- Verbindung verschickt werden oder einen Plain-TCP-Socket. Shark basiert nicht zwingend auf dem Internet. Shark kann durchaus pur auf Kurzstreckennetzen wie Bluetooth basieren. Es kann aber auch als pures TCP-Overlaynetzwerk konfiguriert werden. Entwickler sind hier völlig frei. Sie müssen lediglich entscheiden, welche Protokolle aktiviert werden sollen. Dieser Aspekt wird bei der Verwendung der SharkEngine beschrieben, Abschnitt KEP ist im Gegensatz zu vielen anderen Protokollen sehr einfach. Es hat zwei Kommandos. Es ist außerdem zustandsfrei und asynchron, was die Implementierung für spontane Netze sehr erleichtert. Entwickler von Shark-Anwendungen kommen mit KEP nicht direkt in Berührung, daher wird es in den Programmierteilen nicht weiter diskutiert. Ein weiteres Buch Inside the Shark Framework wird die Details des Frameworks offen legen 4 3 Ja, das Wort ist von den Borg aus Star Trek inspiriert. Es ist Perfektion. Dank an das Kollektiv und die Queen! 4 Wenn Sie sich vor dessen Erscheinen dafür interessieren: Haben sie keine Scheu und kontaktieren Sie den Autor: Ich freue mich auf jede/n, der/die sich für Details interessiert. Tippen Sie meinen Namem in Ihre bevorzugte Suchmaschine und Sie werden mich finden und auch eine Kontaktadresse. Trotz aller Kritik sind natürlich Informationen über Shark und mich auch im WWW zu finden. Mehr gibts aber im SharkNet.

19 2.2. EINSTIEG Alle Facetten eines Interesses Wir kennen nun das Prinzip der Kommunikation zwischen Shark-Peers. Nun soll ein detaillierterer Blick in das Interesse und seine Facetten geworfen werden. Im folgenden werden sämtliche Facetten eines Interessen genannt und kurz beschrieben. Topic Diese Facette beschreibt das Thema, über das sich das Peer austauschen will. Diese Facetten kann beliebig viele Topics nennen. Die Standardbelegung ist any, was bedeutet, dass sich das Peer für alle Themen interessiert oder in anderen Worten keine Einschränkungen bezüglich des Thema haben. Diese Facetten wird mittels eines Semantic Tags Sets repräsentiert, siehe 2.4 Peer Diese Facette beschreibt das Peer, das dieses Interesse angelegt hat. Diese Facetten kann wahlweise ein Peer enthalten oder leer sein. Im Standardfall wird das anonyme Peer angenommen, d.h. das Peer legt seine Identität nicht offen. Diese Facetten wird mittels eines Peer Semantic Tags repräsentiert, siehe Remote Peer Diese Facette beschreibt die Peers mit denen sich das Peer austauschen will. Hier können beliebige viele Peers benannt werden. Der Default ist any, womit jedes beliebige Peer gemeint ist. Diese Facetten wird mittels eines Semantic Tag Sets von Peer Semantic Tags repräsentiert, siehe und 2.4 Originator Diese Facette beschreibt ebenfalls ein Peer. Mit diesem Peer ist allerdings ist dasjenige gemeint, dass eine Information diesem konkreten Kontext zugeordnet hat. Was bedeutet das? Weiter oben wurde erklärt, dass ein Peer Wissen senden kann. Wissen ist per Definition Information in einem Kontext. Irgendjemand muss aber diese Information dem entsprechenden Kontext zugeordnet haben. Das muss nicht zwingend das Peer selber sein. Nehmen wir an, es gibt einen Experten für Quantenphysik, Peer Q. Q liest viel und ordnet regelmäßig Artikel, Bücher usw. den jeweiligen Themen der Quantenphysik zu. Artikel, die er schlecht findet, ordnet er natürlich nicht dort ein. Nehmen wir an, dass ein Student S bei Q studiert. S ist in den Studien noch nicht so weit fortgeschritten, um einschätzen zu können, ob manche Artikel und Bücher wesentlich und richtig sind oder nicht. S vertraut aber Q und so kann S entscheiden, erst einmal alles als wahr und passend anzunehmen, was Q so einordnet. Trifft S nun andere Studierenden, die sich für Quantenphysik interessieren, so würde S anbieten: [topic: Quantenphysik, peer: S, remotepeer: Any, originator: Q, time: Any, location: Any, direction:out]

20 20 KAPITEL 2. GRUNDKONZEPTE Empfänger wissen nun, dass S Dokumente von Q erhalten hat und man diese über diesen Kanal empfangen kann 5. In einfachen Anwendungen wird der Originator gleich dem Peer sein. Das ist auch die Standardbelegung. Ist die Facette leer, so wird Peer als Originator angenommen. Es können beliebige viele Originator genannt werden. Diese Facetten wird mittels Peer Semantic Tags repräsentiert, siehe Time Diese Facette beschreibt, wann ein Peer Informationen austauschen will. Die Standardbelegung ist any, was bedeutet, dass das Peer jederzeit kommunizieren will. Es gilt zu beachten, dass diese Facetten nicht beschreibt, wann eventuell übermittelte Informationen gültig sind. Ein Peer kann so zum Beispiel formulieren, dass es nur im Urlaub und zu einer konkreten Uhrzeit Interesse am Erhalt von gewissen Informationen hat. Diese Facetten wird mittels eines Sets von Time Semantic Tags repräsentiert, siehe Location Diese Facette beschreibt, wo ein Peer Informationen austauschen will. Die Standardbelegung ist any, was bedeutet, dass das Peer an jedem Ort Informationen austauschen will. Diese Facetten wird mittels eines Sets von Geo Semantic Tags repräsentiert, siehe Direction Dies Facette beschreibt, in welche Richtung das Peer kommunizieren will. Es gibt drei Möglichkeiten: in meint, dass das Peer Informationen empfangen will, out beschreibt, dass das Peer Informationen senden will und inout bedeutet, dass es sowohl Senden als auch Empfangen will. Inout ist die Standardbelegung. Nun kennen wir die Struktur des Interesses, in Abschnitt 3.6 wird beschreiben, wie ein Interesse programmiert wird. 2.3 Semantic Tags Shark ist ein P2P System. Es geht davon aus, dass sich die Peers niemals zuvor getroffen haben, bevor sie kommunizieren. Wie aber formulieren die Peers in einer solchen Umgebung ihre Interessen so, dass ein anderes, ggf. völlig unbekanntes Peer sie auch versteht? Dazu dienen die Semantic Tags die in diesem Abschnitt vorgestellt werden sollen. Um es etwas blumig, aber technisch korrekt zu sagen: Semantic Tags sind das Vokabular, die Worte, mit denen sich Shark Peers unterhalten. Bevor wir in Details einsteigen, soll das Problem etwas näher beleuchtet werden. 5 Und sie müssen S vertrauen. Jeder kann herkommen und behaupten, dass ein Dokument von einem anderen Peer zugeordnet wurde. Das kann schlicht und einfach gelogen sein.