Home

Endbericht - Lehrstuhl 12

1. eintreffenden Pakete aus Neben der Sortierfunktion ist der Splitter auch noch Ansatzpunkt f r verschiedene andere Dienste wie beispielsweise der Kontroll Nachrichten die im Abschnitt 4 2 2 4 genauer beschrieben werden 4 2 2 3 Erstellung der UDP Sockets Um f r die AV Konferenz die Daten an das Netzwerk zu schicken wurde eine Schnittstelle ben tigt Dazu wurde eine Methode implementiert die bei Bedarf Sockets aufbaut welche dann genutzt werden um Daten an das Netzwerk zu schicken Eingangsport Video Eingang und Ausgangsport f r Video je 2 Eingangs Gstreamer und Ausgangsports AVSockets Ausgangsport Video cf KE Eingangsport Audio Ausgangsport f r Ausgangsport Audio Sender Audio Abbildung 4 5 Aufbau der Socketverbindungen Daf r wurden die zwei Methoden AVSockets und SocketFWD implementiert Wie in Abbil dung H Alzu sehen ist kann die Methode AVSockets von dem GStreamer aufgerufen werden und erwartet die Ein und Ausgangsports f r die Videoschnittstelle die Ein und Ausgangs ports f r die Audioschnittstelle und die Peeradresse des Ziels Sie dient im Prinzip nur dazu einen vereinfachten Aufruf f r die Sockets zu erm glichen Sie macht nichts weiteres als jeweils f r Audio und Video die entsprechenden Methoden in SocketFWD aufzurufen Datenweg Abbildung 4 6 Datenwege ber die UDP Sockets Socket WD erstellt f r den Eingangsport einen Socket vom Typ Rece
2. CPU MEM COMMAND Sender smokeenc 22784 3072 2164 14 9 2 4 gst launch hantro4200enc 23432 3316 2256 17 8 2 6 gst launch Empf nger smokedec 31716 3140 2272 2 9 25 est launch hantro4100dec 32160 3344 2436 3 3 2 6 est launch Tabelle 4 5 Auswertung der Video Codec Tests Audio Codecs Wie auch bei den Video Codecs bietet das N810 standardm ssig mehrere Audio Codecs an Bei einigen Codecs bietet der verbaute DSP sogar hardwareseitige Unterst tzung an die in Form von GStreamer Plugins nutzbar gemacht wird So k nnen beispielsweise MP3s zwar hardwareseitig dekodiert aber nicht enkodiert werden Deshalb wurde dieses Format nicht weiter betrachtet Da gerade Multimedia Anwendungen viel Rechenleistung ben tigen wurde versucht hardware gest tzte Codecs zu verwenden Namentlich sind dies die auf Komprimierung von Sprache optimierten Standards G 711 und G 729 Sende Pipeline gst launch dspg729src dtx 3 rtpg729pay udpsink host 192 168 178 27 port 5000 sync fals Empfangs Pipeline gst launch v udpsrc port 5000 caps application x rtp clock rate int 8000 encoding name string G729 rtpg729depay dspg729sink Abbildung 4 15 Sende und Empfangspipeline mit G 729 Der Standard G 711 wie er von der Internationalen Fernmeldeunion ITU verabschiedet wurde beschreibt die Analog Digital Wandlung von Sprachsignalen per Puls Code Modulation 66 4 5 Multimedia PCM Dieses Verfahren
3. So gibt es zum Beispiel ausgereifte Bibliotheken f r die Entwicklung grafischer Oberfl chen siehe Abschnitt P 6 sowie weit entwickelte Multimedia Frameworks siehe Abschnitt Ha die es erm glichen auf zuvor geleisteter Arbeit aufzubauen anstelle alles von Grund auf selbst zu implementieren 1 5 Struktur des Endberichtes Dieser Abschnitt behandelt grob die Struktur der noch folgenden Kapitel des Endberichts Um eine Wissensgrundlage f r weiterf hrende Herangehensweisen zu schaffen schafft das zweite Kapitel eine Basis an Informationen Hierbei werden essentielle Konzepte erl utert und deren Realisierung gekl rt welche meistens durch Fremdanbieter Software gel st wurde Zum besseren Verst ndnis des zugrunde liegenden Peer to Peer Frameworks werden die Haupt elemente von GNUnet und die von UbiMuC benutzten Funktionen im dritten Kapitel n her beleuchtet Dabei ist besonders das Verst ndnis der eigentlichen Arbeitsweise und Struktur von GNUnet ein wichtiger Aspekt der f r die darauf aufbauenden Konzepte unumg nglich ist Erste Anpassungen des GN Unet Basiscodes und eigens entwickelte Erweiterungen kommen ebenfalls dort zur Sprache Nach diesen einf hrenden Worten folgt innerhalb des vierten Kapitels der Hauptteil der durch gef hrten Projektarbeiten Darin enthalten sind detaillierte L sungskonzepte und Implemen tierungswege zur Gew hrleistung der gestellten Anforderungen an UbiMuC Der anf ngliche Entwurf wird dort um zus tz
4. Zuerst werden die entwickelten Konzepte vorgestellt mit welchen Abstraktionsebenen die Ver bindung zwischen GNUnet und unseren Programmschichten hergestellt werden und wie diese mit der GUI verkn pft sind Dabei wird insbesondere auf die Integration in der WIR Core Struktur und die Schnittstellen zwischen dieser und der GUI beziehungsweise der DHT in GNUnet eingegangen Im zweiten Teil des Abschnittes werden schlie lich die Implementie rungsdetails genauer erl utert 4 3 1 Konzepte und Spezifikationen Die Nutzerverwaltung stellt innerhalb von UbiMuC das zentrale Element f r die Suche von Nutzern und die persistente Speicherung der Nutzerdaten dar Deshalb ist sie das Bindeglied zwischen der Anzeige der Nutzer in der GUI der von GNUnet bereitgestellten DHT dem Paketdienst und dem WIR Core Konstrukt Ziel dieses Moduls ist es dem Nutzer von UbiMuC eine einfach zu bedienende Oberfl che zu bieten mit der rudiment re Aufgaben einer Nutzerverwaltung wie man sie aus Messaging Programmen kennt erledigt werden k nnen Konkret bedeutet dieses dass man andere im Netz verf gbare UbiMuC Nutzer suchen und in einer Liste von Kontakten im Weiteren auch Buddyliste genannt abspeichern kann Diese Kontakte werden dauerhaft gespeichert und k nnen mit einem selbst gew hlten Alias versehen und wieder gel scht werden Au erdem sind ber die GUI weitere Informationen zu den Nutzern abrufbar und ber den Online Status ist jederzeit einse
5. e Multimedia Alle Themen auf tieferen Ebenen wurden folglich angegangen sobald die notwendigen Vorar beiten geleistet wurden Im Weiteren soll kurz beschrieben werden wie die einzelnen Knoten der Roadmap zu den gro en Themengebieten zugeordnet werden Config Parser Datencontainer Personenverwaltung Paketdienst EN par 3 oo Video Stream 7 Interface E GUI WIR GUI j Produkttest Abbildung 2 7 Die endg ltige Roadmap 27 2 Grundlagen Zu den Aufgabenbereichen der Transportschicht Gruppe siehe Abschnitt z hlen Daten container Paketdienst die Interface Struktur zwischen WIR Schicht und GNUnet sowie das Interface zwischen der grafischen Oberfl che und der WIR Schicht Die Nutzerverwaltung sie he Abschnitt wurde von der gleichnamigen Gruppe bernommen Zus tzlich wurde von dieser der Config Parser implementiert Nach Vollendung des Paketdienstes wurde ein Teil des Teams mit der Entwicklung des Chats siehe Abschnitt beauftragt Die Multimedia Gruppe siehe Abschnitt war f r die Umsetzung der Audio und Video Streams sowie die Integration und Ansteuerung der Webcam und des Mikrofons zust ndig W hrend des Entwicklungsprozesses wurde die grafische Oberfl che von den jeweiligen Gruppen um deren Bed rfnisse erweitert Die erfolgreiche Entwicklung dieser Teilaspekte f hrt zur Fertigstellung des Projekts UbiMuC 28 3 Transport und Kommunikation Nachdem die Grundlagen von GNU
6. transfer Die Vorteile von GNUnet liegen in der Konzeption zur anynomen Peer to Peer Kommunikation und dem relativ geringen Ressourcenbedarf Au erdem wurde direkt auf Transportebene die effiziente Verschl sselung der Daten mitgeliefert Das Auffinden ande rer Peers und die Kommunikation zwischen den einzelnen Peers wird ebenfalls von GN Unet erm glicht Das Framework ist modular aufgebaut so dass die ben tigten Teile unabh ngig voneinander eingesetzt werden k nnen und sich neue Module sowie Adapter zu unseren Programm Modulen leicht integrieren lassen UbiMuC Transportschicht Da das von GNUnet gebotene anonyme Routing nicht zur Verwirklichung unserer Zwei Punkt Verbindungen geeignet war wurden von der Projektgruppe zwei Konzepte entwickelt mit denen Pakete selbst ndig und ohne Aufforderung an einen befreundeten Peer gesendet werden k nnen Essenziell war hierf r der Aufbau des Pfade durch das Netzwerk F r den eigentlichen Datentransfer wurde der Paketdienst entwickelt der den von uns entwickelten UbiMuC Datencontainer verwendet um die Nutzdaten zu verpacken Der Paketdienst erm glicht die Sende und Empfangsfunktionalit t in Bezug auf die von Ubi MuC neu generierten Nachrichtentypen Diese sind GetRoute und GetRouteReply mit denen es m glich ist eine Route zwischen zwei Peers festzulegen F r die Konnektivit t zwi schen Paketdienst und der Multimedia Anbindung wurden die AV Sockets entwickelt mit denen e
7. 2342 Agent Audio Port out 5001 Audio Port in 2343 Abbrechen Anwenden a ev G lt Abbildung 7 12 Das Optionsmen GUI Screenshot 93 7 Appendix Im Dialog Meine Infos ndern kann man weitere Informationen zu sich selbst angeben Diese Informationen werden bei anderen Nutzern angezeigt wenn diese weitere Informationen abrufen z B durch Anw hlen eines Kontaktes in ihrer Buddyliste 0 5 Meine Informationen n Chat GnUbiMuC Buddylis Buddies Vorname Agent Forest Nachname Agent Nils Geburtstag Agent Blue Wohnort Agent Black Telefon Nr Hobbys eMail Abbrechen Anwenden 4 Abbildung 7 13 Dialog zur Angabe weiterer pers nlicher Informationen GUI Screenshot 94 7 3 Benutzerhandbuch Programm beenden Um das Programm zu beenden gen gt ein Klick auf das X in der oberen rechten Bildschirm ecke oder die Auswahl des Men eintrags Schlie en GnUbiMuC 3 S i Optionen player Chat Meine Infos ndern Benutzerinformationen Schlie en D Alias Agent Nils Agent NIIS Vorname Agent Agent Blue Nachname Nils Agent Black Geburtsdatum Wohnort Telefon Nr Hobbys Blau eMail nu 905 Abbildung 7 14 Beendem glichkeiten von UbiMuC GUI Screenshot 95 7 Appendix 7 4 Bekannte Fehler In diesem Abschnitt werden die bekannten Probleme Bugs beschrieben und gegebenenfalls auf m gliche L sungsans tze hingewiesen Die folge
8. UbiMuC verwendet zum Aufbau und zur Verwaltung von Pfaden zwischen den einzelnen Peers des GNUnet Netzwerks ein Source Routing GNUnet selbst bietet keine M glichkeit gezielt Daten in das Netzwerk zu senden da es nach dem Query Response Konzept aufgebaut ist Man hat als Teilnehmer also nur die Option Daten anzufragen und bei Vorhandensein der Daten eine Antwort vom Anbieter zu erhalten Anderenfalls ist GN Unet nativ nicht in der Lage einen Pfad durch das Netzwerk bereitzustellen so dass kein selbst ndiger Aufbau einer gezielten Verbindung oder ein gerichteter Datenaustausch m glich ist Zur Behebung dieses Problems musste eine eigene Routing Struktur erschaffen werden die sowohl den gerichteten Aufbau von Datenkan len ber das GNUnet Netzwerk erm glicht als auch das gezielte Versenden von eigenen Daten an andere Peers Paketdienst anbietet Um Nutzdaten zwischen zwei Teilnehmern auszutauschen m ssen beide ber eine Pfadliste verf gen welche die Schritt f r Schritt Weiterleitung von Daten erm glicht Routing Nachrichtentypen Um den Pfad Aufbau durch ein eigenes Routing Protokoll in GNUnet zu integrieren musste der GNUnet Kern um zwei weitere Nachrichtentypen GetRoute und GetRouteReply er g nzt werden Diese beiden neuen Nachrichtentypen erhalten eigene Callback Funktionen so dass die selbstentwickelten Routingmethoden umgehend nach Empfang einer entsprechenden Nachricht vom Kern abgearbeitet werden Zum Auf
9. ber ein von Nokia zur Verf gung gestelltes Software Development Kit das Maemo 4 0 SDK Dieses stellt eine vom normalen System abgekapselte Umgebung namens Scratchbox zur Verf gung die das System eines N810 nachbildet Von ihren Entwicklern wird sie als cross compilation toolkit bezeichnet und enth lt entsprechend sowohl einen Compiler der X86 Bin rdateien erstellt die das Testen auf dem normalen System erlauben als auch einen der ARM Bin rdateien ausgibt so dass in der gelieferten Umgebung auch direkt die Pakete f r das N810 gebaut werden k nnen Dies erlaubt es Software f r das N810 auf normalen Linux Systemen zu entwickeln und testen ohne besondere Anforderungen an die f r die Entwicklung zu nutzende Hardware zu stellen Zusammenfassung zur Hardwareplattform Die Rechenleistung der CPU des N810 ist alles andere als berdimensioniert Dies ist insbe sondere f r das Verschl sseln von Daten erforderlich f r eine sichere Kommunikation und das Enkodieren von Video und Audio Daten wie es f r die Arbeiten im Bereich Multimedia 11 1 Einleitung siehe Abschnitt erforderlich ist problematisch Im Rahmen der Projektgruppe muss ent sprechend auf dedizierte Einheiten wie zum Beispiel den verbauten digitalen Signalprozessor zugegriffen werden um die gesteckten Ziele erf llen zu k nnen Die Softwareentwicklung selbst hingegen ist vergleichbar mit der Entwicklung von Software f r gebr uchliche Linux Systeme
10. nicht zugeordnet werden k nnen wird eine Fehlermeldung ausgegeben Diese sagt genau aus was f r eine Art von Eintrag erwartet wird und gibt zudem die Nummer der Zeile aus die nicht verarbeitet werden konnte Die resultierenden Datenstrukturen werden von einem globalen Objekt des Typs ubimuc _ config verwaltet Dieses Objekt besitzt ein Interface mit dem sowohl einzelne Werte im Fall Konfigurationseinstellungen geschrieben und gelesen werden k nnen stellt diese Funktio nalit t aber ebenso f r ganze Listen im Fall Kontaktlisteneintr ge beziehungsweise einzelne Objekte im Fall eigene Informationen zur Verf gung Falls Werte schreibend ver ndert wer den wird auch daf r gesorgt dass diese nicht nur in den Datenstrukturen des ubimuc__ config Objektes sondern ebenfalls in der Config Datei angepasst beziehungsweise hinzugef gt wer den Beispiele f r vom Programm benutzte Eintr ge sind die Ports f r die Videokonferenz Diese werden bei Bedarf aus dem Konfigurations Objekt ausgelesen und verwendet 85 7 Appendix 7 2 Installation von UbiMuC Die Installation von UbiMuC verl uft vollst ndig ber den beim N810 bereits mitgeliefer ten Paketmanager Es ist jedoch ein zus tzlicher Eintrag vom UbiMuC Repository n tig Um diesen hinzuzuf gen ffnet man den N810 Programmmanager und w hlt unter dem Men ein trag Optionen den Punkt Programmkatalog Im Programmkatalog klickt man auf Neu um
11. ten aufzubauen und auch Ubertragungen zwischen Ger ten inklusive Weiterleitung ber mehrere Zwischenger te sind umsetzbar Die Adaptierung dieser Infrastruktur f r Netze mit festen IPs ist ebenfalls leicht m glich 6 2 Vergleich mit Minimalzielen An dieser Stelle wird noch einmal auf die in Abschnitt beschriebenen Minimalziele der Projektgruppe eingangen und diese mit den Ergebnissen verglichen Gefordert war die Entwicklung eines Prototypen f r ein mobiles Peer to Peer Framework un ter Ber cksichtung von Sicherheitsaspekten Dieses dient vornehmlich zum Austausch von Multimedia Daten auf einem Internet Tablet f r bestimmte vorgegebene Anwendungsszenari en In Tabelle 6 I werden diese Anforderungen mit unseren in den vorherigen Kapiteln erl uterten L sungsans tzen gegeben bergestellt Minimalziel L sungskonzept Ad Hoc Netz Avahi Sicherheitsaspekte durch GNUnet abgedeckt IP Video Telefonie Paketdienst Nutzerverwaltung GStreamer Instant Messaging Paketdienst Nutzerverwaltung Filesharing nicht implementiert UbiMuC Prototyp GUI WIR Schicht amp GNUnet Evaluation siehe Kapitel Tabelle 6 1 Kurz bersicht der Minimalziele Das Suchen und Finden der Peers in Ad Hoc Netzen wurde mit Hilfe von Avahi gel st und in GNUnet integriert Durch die Wahl von GNUnet als UbiMuC zugrundeliegendes Peer to Peer Framework auf Transportebene musste sich nicht mehr um die Implementierung von Sicherheitsfeatures gek mmert w
12. werden und auf die Umsetzungen von selbigen eingegangen werden 68 4 5 Multimedia Protokoll des Verbindungsaufbaus Dem Konzept fiir den Verbindungsaufbau wie es in Abbildung schematisch dargestellt wird liegt ein simples 3 Wege Handshake zu Grunde und es ist auf ein einfaches Szenario aus gerichtet Es ist darauf ausgelegt mit m glichst wenigen verschiedenen Anfragen eine Verbin dung aufzubauen um so die Menge an ben tigten Paketen und Funktionen im Handler einfach zu halten Es wird davon ausgegangen dass immer nur eine Audio Video Konferenz mit ge nau einem Gespr chspartner existiert So ist es weder m glich zwei verschiedene Konferenzen gleichzeitig zu betreiben noch eine Konferenz unter mehr als zwei Nutzern zu initiieren Client A i i Client B i Voreinstellungen Voreinstellungen curent connection i curent connection i L connection_established FALSE b connection_established FALSE I Initiiere Konferenz Baue Request Paket H i Empf nger H ash 3 i 1 Sender H sch s Flags H H Setze i i eurrent_connection Hash H i Request Paket If Konferenz best tigen Behandlung i DANN Dialog Ferster i SONST i Maximale Wartezeit 3 i 30 Sekunden 3 i 4 3 i current_connection Hash A i i Baue Request Paket Empf nger H ach i i Sender Hash i Flags iII Beginne Konferenz Request Paket i Behandlung i i WENN curre
13. 2 Schnittstellen zwischen DHT und Core sowie Core und GUI Die Schnittstelle zwischen DHT und Core befasst sich vor allem mit der Ansteuerung der DHT ber GNUnet Befehle Haupts chlich werden dabei zwei Befehle benutzt zum Lesen von Daten aus der DHT und zum Schreiben von Daten in die DHT Die durch das Lesen der Daten erhaltenen Eintr ge werden in einer lokalen Liste zwischengespeichert und k nnen von dort aus weiterverwendet werden Sie stellen ein Abbild der aktuell lokal vorhandenen DHT dar Die Schnittstelle zwischen dem Core und der GUI dient dazu die in der Buddylist Daten struktur im Core abgelegten Informationen graphisch zu veranschaulichen Dabei wird eine Liste der aktuell betrachteten Buddies inklusive deren Onlinestatus an die GUI weiter geleitet Dort werden die einzelnen Eintr ge in einer Liste angezeigt und entsprechend ihres Onlinestatus eingef rbt Die eigentliche Verwaltung des Onlinestatus und das Sortieren nach Onlinestatus bzw Alias geschieht dabei im Core Die GUI k mmert sich nur um die graphische Darstellung 4 3 2 Implementierung Bei der Implementierung k nnen drei Teile unterschieden werden e das Ansteuern der DHT in GN Unet e das eigentliche Verwalten der einzelnen Kontakte e das Anzeigen in der GUI 57 4 Design Ansteuern der DHT Das Ansteuern der DHT in GNUnet befasst sich in erster Linie mit der GNUnet API Hier wird eine Verbindung zum eigentlichen GNUne
14. 7 GNUnet Homepage ttp www gnunet org Es es 5 8 Hildon Framework auf Gnome org ttp live gnome org Hildon 9 GTK Homepage ttp www gtk org 10 Whitepaper der DHT in GNUnet The Design and Implementation of a Distributed am Ki un g 5 gt pat O SN rm Do CO O O er O D bg 2 Z 2 d O e Si ttps gnunet org svn GNUnet docs papers dht whitepaper pd 11 Maymounkov P and Mazieres D Kademlia A peer to peer information system based on the xor metric Proceedings of the 1st International Work shop on Peer to Peer Systems IPTPS ttp www cs rice edu Conferences IPTPS02 109 pdf 12 GStreamer Homepage E es ttp gstreamer freedesktop org 13 Video4Linux Homepage ttp linux bytesex org v4l2 Es 14 ALSA Homepage http www alsa project org main index php Main Page 15 GNOME Homepage http www gnome org 97 Literaturverzeichnis 16 Flumotion Homepage http www flumotion net 17 Hantro 4200 Homepage ttp www hantro com index php 140 3 18 Hantro 4100 Homepage ttp www hantro com index php 98 19 G 711 auf der Homepage der ITU T http www itu int rec T REC G 711 en 20 G 729 auf der Homepage der ITU T http www itu int rec T REC G 729 en Es 21 REC 1889 http www ietf org rfc rfc1889 txt 22 Maemo Testprogramme http maemo org development documentation manuals 4 0 x Hinw
15. 72 5 1 Aufbau des Kreuztestes mit f nf Ger tedl o o 78 7 1 Nickname Eingabe beim Programmstart GUI Screenshot 87 99 Abbildungsverzeichnis 7 2 Navigationsreiter in der UbiMuC Benutzeroberfl che GUI Screenshot 88 1 3 Die Buddyliste GUI Screenshot o 89 7 4 Funktionsmen f r das Manipulieren der Buddyliste GUI Screenshot 90 7 5 Dialog f r das Hinzuf gen einzelner Kontakte GUI Screenshot 90 7 6 Alias ndern Dialog GUI Screenshot 0 o 90 7 7 Eine laufende Videokonferenz GUI Screenshot o o o o 91 7 8 Funktionsmen f r das Manipulieren der Videokonferenz GUI Screenshot 91 7 9 Aktive Chatsitzung in der UbiMuC Benutzeroberfl che GUI Screenshot 7 10 Eingabefl che und Senden Button in der UbiMuC Benutzeroberfl che GUI LE EA EE A A E AA ARA 92 7 11 Aufruf des Optionsmen s GUI Screenshot 2 2 2 2 22 22 93 7 12 Das Optionsmen GUI Screenshot 93 7 13 Dialog zur Angabe weiterer pers nlicher Informationen GUI Screenshot 94 7 14 Beendem glichkeiten von UbiMuC GUI Screenshot 95 100 Tabellenverzeichnis 1 1 Anwendungsf lle und deren L sungskonzepte 3 1 Services und Applikationen 4 1 Test mit GNUnet Revision 804 zwei Ger te 4 2 Test mit GNUnet Revision 804 drei Ger te 4 3 Test mit
16. Abbildung 4 19 Ablauf beim Aufbau einer AV Konferenz Schritt 2 Schritt 2 Der Pakethandler bei Client B stellt ein eingehendes Paket von Client A fest und sieht anhand der eigenen Variablen dass momentan keine Verbindung besteht Der Nutzer wird nun per Dialog Fenster gefragt ob eine Verbindung zu Client A aufgebaut werden darf Stimmt der Nutzer dem zu wird ein eigenes Request Paket gebaut und an Client B verschickt Auferdem wird hier die Variable current connection auf den UbiMuC Hash von Client A gesetzt Dieser Schritt ist in Abbildung visualisiert Client B Behandlung H d WENN current_connection H i i DANN Dialog Ferster SONST 1 WENN current_connection Hash B i i UND connection_established FALSE DANN H Setze connection_established TRUE Baue Request Paket Empf nger H seh Sender H ach Request Paket TY Vollst ndige Konferenz i Abbildung 4 20 Ablauf beim Aufbau einer AV Konferenz Schritt 3 Schritt 3 Ist das Zeitfenster bei Client A noch nicht abgelaufen so wird beim Eingehen des Requests von Client B connection established auf TRUE gesetzt und ein weiteres Request Paket an Client B verschickt um die Verbindung zu best tigen Nun werden wie Abbildung zu 71 4 Design entnehmen ist die Ports f r die Konferenz ge ffnet und Daten von Kamera und Mikrofon ab jetzt an Client B verschickt Sollte das Zeitfenster dage
17. Aliasnamen des Nutzers beschriftet mit dem die Chat Sitzung aufgebaut wurde 60 4 4 Chat Erh lt ein Nutzer erstmalig eine Nachricht von einer unbekannten Person so k nnen zwei F lle auftreten Der Absender ist in der DHT Struktur verzeichnet und der Empf nger kann dessen Adresse Hashwert und Aliasnamen mittels der DHT Schnittstelle abfragen und in Erfahrung bringen Sofern dies m glich ist wird das Chat Tab normal aufgebaut und mit dem erhaltenen Aliasnamen gekennzeichnet Die empfangene Nachricht wird anschlie end im Textfenster angezeigt Ist ber die Buddyliste anf nglich kein Aliasname bestimmbar wird dies durch die Beschrif tung Unbekannte Person hervorgehoben Falls auch keine Antwort von der DHT eintrifft bzw die Suche erfolglos endet und demnach kein korrespondierendes GNUnet HELLO vor liegt wird die Nachricht verworfen Dies hat den Grund dass der Empf nger der Nachricht ohne DHT Eintrag und GN Unet HELLO nicht auf den ihm zugesandten Text antworten kann N here Details zu den Gr nden wurden in den Abschnitten 3 1 3 1 sowie 3 1 3 2 behandelt Darstellung der Textnachrichten Inhaltlich werden die Nachrichten innerhalb des Textfensters in der jeweiligen zeitlichen Rei henfolge dargestellt auf optische Hervorhebungen oder Zeitstempel ist aufgrund der einge schr nkten Displaygr e des N810 verzichtet worden Zur besseren bersicht bei l nger an dauernden Chat Sitzungen verf gt jeder Tab ber e
18. C Repr sentation haben Allgemein betrachtet werden beim Marshalling s mtliche Objekt Attribute der Reihe nach in ein Bytearray geschrieben wobei man ggf Litte Endian Big Endian Konvertierungen durchf hren muss um die Portabilit t zu wahren 36 4 Design Im Anschluss an die mit GNUnet gelegten Grundlagen der Transportschicht orientiert sich das Kapitel Design an der von der Projektgruppe geleisteten Arbeit Das Ziel von UbiMuC ist es einen Prototypen einer Peer to Peer Kommunikationsplattform zu implementieren Mit GN Unet ist zwar eine Basis f r den Austausch von Datenpaketen im Netz geschaffen allerdings m ssen darauf aufbauend noch einige zus tzliche Funktionalit ten erarbeitet werden Dazu geh ren unter anderem der in GNUnet bereits geplante jedoch noch nicht verwirklichte Chat der Austausch von Bild und Tonmaterial sowie verschiedene Erweiterungen auf niedrigeren Programmschichten Hierbei richtet sich die Gliederung nach der Projektplanung siehe Abschnitt P 7 welche zuvor ausgearbeitet wurde Daraus resultieren fiinf Unterkapitel die Bottom up wie in der Struktur von UbiMuC bereits beschrieben vom Transport der Datenpakete bis zur eigentlichen Anwendung angeordnet sind Zun chst wird ein berblick ber den selbstentwickelten Datencontainer gegeben gefolgt von der Transportschicht Erweiterung welche mit Hilfe des Datencontainers Pakete an andere Peers verschickt Ein weiteres Konzept bildet die Nutzerverw
19. Chat Fenster gewechselt Wenn ein einfacher Chat nicht reicht kann auch eine Videokonferenz mit dem aktuell angew hlten Kontakt gestartet werden Dieses Icon erm glicht dies 2 Mit dieser Option kann man den angezeigten Alias des ausgew hlten Kontaktes ver ndern Alias Agen t Alias ndern neuer Alias JAgentNils OK Abbrechen Abbildung 7 6 Alias ndern Dialog GUI Screenshot 90 7 3 Benutzerhandbuch Das Player Fenster Das Playerfenster wird im Falle einer Videokonferenz benutzt GnUbiMuC Buddyliste Player Chat gu e e d 22 GW Abbildung 7 7 Eine laufende Videokonferenz GUI Screenshot Uber die Icons am unteren Bildschirmrand ist es m glich verschiedene Funktionen an und auszuschalten ua e ad di 228 4 Abbildung 7 8 Funktionsmen f r das Manipulieren der Videokonferenz GUI Screenshot 4 HI Hiermit ist es m glich das angezeigte Bild an und auszuschalten BO e Analog dazu l sst sich auch die Kamera an und ausschalten Mit diesen Icons l sst sich die Tonausgabe an und ausschalten 4 d Analog dazu l sst sich auch das Mikrofon an und ausschalten Hiermit kann man die gesamte Videokonferenz beenden 91 7 Appendix Der Chat Im Chatfenster werden aktive Chat Sitzungen angezeigt d ml GnUbiMuC Buddyliste Player Chat Agent Black x lt lt Chat gestartet gt gt Agent Orange Hallo Agent Black Servus Agen
20. Dienst von GNUnet Er ist nicht direkt sichtbar f r einen Benutzer kann aber von einer oder mehreren Applikationen genutzt werden Weiterhin wird ein Service nur dann geladen wenn er von einer Applikation gebraucht wird Der erste Service Identity ist f r die Verwaltung einer Liste zust ndig die aus bekannten Peers besteht Weiterhin enth lt er Informationen ber die Peers die sich auf einer Blacklist befinden und ber die HELLO Nachrichten F r das Versenden von Paketen steht in GN Unet eine Transportschicht zur Verf gung Der Zugriff auf diese Schicht wird durch den n chs ten Service Transport erm glicht Stats kann verwendet werden um bestimmte statistische Informationen wie die Anzahl von empfangenen Bytes gesendeten Nachrichten und gespei cherten Datenmengen zu speichern Mittels des Werkzeug gnunet stats hat man dann die M glichkeit die gespeicherten Informationen auszulesen Der Service PingPong pingt einen Host an und l st eine Aktion aus sobald eine Antwortnach richt empfangen wurde Topology ist ein Service der f r den Aufbau einer Mesh Topologie zust ngig ist Hierbei handelt es sich um ein Netz in dem jeder Netzwerkknoten mit einem oder mehreren verschiedenen Knoten verbunden ist Fragmentation erlaubt das Senden und Empfangen von Nachrichten die gr er sind als die Maximum Transmission Unit Dabei werden alle Nachrichten vor dem Versand auf die maximale Gr e von 65535 Bytes zerlegt Beim n chsten S
21. GNU Lizenz stehende Programm Avahi f r die Bildung von Ad Hoc Netzen mittels ZeroConf ausgew hlt welches im weiteren Verlauf in GNUnet eingebunden werden muss Projektplanung Um die einleitend erw hnten Ziele und Vorstellungen in Form einer einheitlichen Software Umgebung durch UbiMuC zu gew hrleisten ist eine Vielzahl an Einzelarbeiten und individu ellen L sungswegen notwendig Als erste Ansatzpunkte und zur Etablierung einer ad quaten Planung m ssen auf Basis der geschilderten Zielvorstellungen einzelne Anwendungsf lle aus gearbeitet werden welche die UbiMuC Umgebung realisieren sollte Diese Anwendungsf lle m ssen nat rlich inhaltlich mit L sungskonzepten und Strukturen gef llt werden so dass die geforderten Zielvorstellungen realisiert werden k nnen Was die Nutzung von externen Diens ten und Frameworks betrifft so ist deren strukturierte Analyse zur Integration der Funktio nalit ten in UbiMuC unausweichlich 1 2 Anwendungsf lle Im Mittelpunkt stehen dabei besonders die Modifikationen des Peer to Peer Frameworks die f r die Integration und reibungslose Zusammenarbeit mit UbiMuC n tig sind sowie die Ent wicklung einer Zwischenschicht welche die Daten zwischen dem Framework und den einzelnen UbiMuC Funktionen vermittelt Um entsprechende Modifikationen durchf hren zu k nnen muss die ausgew hlte Software detailliert betrachtet werden um ein Verst ndnis der Arbeits weise zu entwickeln Was die sp tere Anp
22. Hardware und Arbeitsumgebung Dieser Abschnitt behandelt die der Projektgruppe 526 zugrundeliegende Hardwareplattform Auf dieser soll das gesamte Projekt UbiMuC bei Abschluss der Projektgruppe lauff hig sein Es wird sowohl auf Sinn und Zweck der Zielplattform eingegangen als auch auf die Hardware und Software selbst Des Weiteren werden f r die Softwareentwicklung f r dieses Ger t ben tigte Grundlagen kurz angeschnitten Allgemeines zur Hardwareplattform Als Zielplattform f r die Projektgruppe war das von Nokia vertriebene Internet Tablet N810 vorgegeben Dieses soll eine allgegenw rtige Internetnutzung erm glichen Bedingt durch den 10 1 4 Hardware und Arbeitsumgebung mobilen Ansatz m ssen entsprechend den Erfordernissen auch die Hardwareeigenschaften an gepasst sein Das bedeutet dass eine hohe Akkulaufzeit und m glichst vielf ltige Verbindungs m glichkeiten vorliegen m ssen Des Weiteren muss das Ger t hinreichend klein sein so dass es m glich ist es immer bei sich zu tragen vergleichbar mit einem Handy oder Smartphone Nokia grenzt das Ger t dabei bewusst durch Aussparen des GSM UMTS Senders Empf ngers von den Mobiltelefonen ab Somit ist es mit dem N810 nicht m glich auf klassische Art und Weise zu telefonieren so dass hier Voice over IP eingesetzt wird Im Ger t selbst kommt ein OMAP2420 von Texas Instruments zum Einsatz Diese System on Chip L sung stellt s mtliche Grundfunktionen wie eine A
23. Kontaktes Ist dieser momentan online werden automatisch weitere Informationen wie Geburtsdatum Hobbys etc abgerufen und angezeigt sofern diese von der Person hinterlegt wurden GnUbiMuC DU j te Buddies Benutzerinformationen Agent Nils Alias Aaent Nils Agent Blue Vorname Agent Agent Forest Nachname Nils Wohnort Telefon Nr Hobbys Blau eMail a 5 960 Abbildung 7 3 Die Buddyliste GUI Screenshot 89 7 Appendix Die einzelnen Funktionen lassen sich ber Icons am unteren Bildschirmrand steuern Dabei k nnen folgende Funktionen aufgerufen werden a po e OO k 4 Abbildung 7 4 Funktionsmen f r das Manipulieren der Buddyliste GUI Screenshot 2 Hiermit ist es m glich nach weiteren Kontakten zu suchen Bei einem Klick ffnet sich ein Dialog mit einer Liste aktuell verf gbarer Kontakte Mit einer Eingabe im Feld Filter ist es m glich die Suche einzugrenzen Buddy hinzuf gen Agent Forest NSEQNWCGMKCDADHJFIWTBPLBGJNOHWKUUJFXRVDVCLKENK Agent Nils UKYQHZVLEKAVOSJUNVPQCJIKNRYWXUHDCIJVECXGCPYBOPSQZ Filter Abbildung 7 5 Dialog f r das Hinzuf gen einzelner Kontakte GUI Screenshot amp Ein Klick auf dieses Icon sorgt daf r dass der angew hlte Kontakt aus der Liste der bekannten Kontakte gel scht wird Dieses Icon bietet die M glichkeit mit dem aktuell angew hlten Kontakt eine Chat Session zu er ffnen Dabei wird automatisch auf das
24. Napster die nicht unter diese Definiti on fallen Daher ist die Peer to Peer Working Group 6 mit ihrer Definition etwas allgemeiner In einem Peer to Peer Netzwerk werden verteilte Rechenressourcen durch direkte Kommunikation gemeinsam genutzt 13 2 Grundlagen Mit dieser Definition ist man sicher zu allgemein Das Finzige was man mit Si cherheit ber Peer to Peer Netzwerke sagen kann ist dass Peer to Peer Netzwerke nicht Client Server Netzwerke sind Diese Definitionen lassen sich auf UbiMuC bertragen Alle Ger te bernehmen die gleichen Funktionen Der Einsatz auf mobilen Ger ten impliziert trotz geteilter Rechnerressourcen eine dynamische Netzstruktur da Teilnehmer zu jeder Zeit dem Netz beitreten oder dieses verlassen k nnen Da drei verschiedene Auspr gungen von Peer to Peer Netzwerken existieren musste eine der Folgenden f r das UbiMuC Projekt ausgew hlt werden e Serverbasierte Peer to Peer Netzwerke e Reine Peer to Peer Netzwerke e Hybride Peer to Peer Netzwerke Jede dieser Auspr gungen beinhaltet einige Vor und Nachteile Daher werden sie hier genauer betrachtet Serverbasierte Peer to Peer Netzwerke Diese Auspr gung von Peer to Peer Netzen orientiert sich noch sehr stark an traditionellen Client Server Strukturen Hierbei ist ein Server f r die Verwaltung von Ressourcen und den Verbindungsaufbau zwischen zwei Peers zust ndig Demnach besteht dieses Netz aus hetero genen Knoten mit unterschi
25. Netzwerke und deren Umsetzung in UbiMuC mit GNUnet gegeben Ein weiteres Konzept bilden Ad Hoc Netzwerke mit ZeroConf Unterst t zung Als ZeroConf Implementierung kommt hier Avahi zum Einsatz welches ebenfalls kurz vorgestellt wird Nach den grundlegenden Konzepten und deren Umsetzung wird ein berblick ber die Struk tur des bisherigen Projektes gegeben Hierbei werden die einzelnen Komponenten und deren Verbindungen untereinander aufgezeigt Es folgt eine gesonderte Betrachtung der im ersten Semester entwickelten Benutzeroberfl che Abgeschlossen wird dieses Kapitel durch die Projektplanung des zweiten Projektsemesters Diese Planung zeigt die Abh ngigkeiten der einzelnen Projektbestandteile die in den folgenden Kapiteln beschrieben werden 2 1 Peer to Peer Konzepte Das Peer to Peer Konzept ist eine essenzielle Eigenschaft des Projektes UbiMuc Um dieses Konzept zu verstehen ist eine Definition des Begriffes Peer to Peer notwendig Professor C Schindelhauer definiert es in seiner Vorlesung Algorithmen f r Peer to Peer Netzwerke wie folgt Wenn man also die funktionale Beschreibung eines Netzwerks betrachtet so gilt die folgende Definition Ein Peer to Peer Netzwerk ist ein Kommunikationsnetzwerk zwischen Rechnern in dem jeder Teilnehmer sowohl Client als auch Server Aufgaben durchf hrt Obgleich diese Definition eine gute Intuition gibt werden wir sehen dass es tat s chlich Peer to Peer Netzwerke gibt z B
26. Umsetzung einiger Dienste ben tigen Daher haben wir uns daf r entschieden die Klasse Datacontainer zu entwickeln die f r alle in UbiMuC anfallenden Daten bertragungen genutzt werden soll Format Der Datacontainer enth lt alle notwendigen Informationen um eine zuverl ssige Rekonstruk tion der Nutzdaten gew hrleisten zu k nnen Wie in Abbildung dargestellt ist wurden jeweils 32 Bit lange Felder im Header eingef gt um eine Sequenznummer zur Wiederher stellung der Paketreihenfolge eine Verbindungsnummer zur Zuordnung von Datenstr men eine Typ Enumeration zur Klassifikation der enthaltenen Nutzdaten sowie die Datengr e abzubilden 1 0 3 Abbildung 4 1 Datacontainer Auff llig ist dass im Gegensatz zum Header von anderen Netzwerkprotokollen wie TCP IP keine Adressinformationen enthalten sind da diese ausschlie lich zum Versand von Paketen ben tigt werden und Datacontainer innerhalb von UbiMuC auch zum Zwischenspeichern von Daten beispielsweise innerhalb des Splitters genutzt werden wo Adressdaten die jeweils 64 Byte belegen nur unn tig Speicherplatz belegen w rde Bei den Headern wurde darauf geachtet dass das Marshalling portabel bleibt insbesondere bei bertragungen zwischen Architekturen mit unterschiedlicher Endianess 38 4 2 UbiMuC Transportschicht Besonderheiten Um die ffentlichen Schnittstellen des Datacontainers besonders einfach zu halten wu
27. Verbindungsaufbau zu bekannten Peers m glich Au erdem wurde f r die Kommunikation auf Transport Ebene neben dem Paketdienst eine Abstraktion der Ver bindungen als bidirektionale Pipeline entwickelt Diese ist jedoch nur ein Prototyp und wird in der UbiMuC Software nicht verwendet da sich diese am Ende des zweiten Projektgrup pensemesters als sehr fehlerbehaftet herausstellte Die Teile des Programms die urspr nglich diese Pipeline nutzen sollten verwenden daher ausschlie lich den Paketdienst 6 3 Ausblick Als weitere Arbeit an UbiMuC bietet sich f r zuk nftige Projekte nat rlich die Verbesse rung der Audio Videoqualit t sowie die Reduzierung der Prozessorlast an Darauf aufbauend k nnte man Multiuser Konferenzen entwickeln um mehrere Benutzer gleichzeitig miteinander kommunizieren zu lassen Da sich UbiMuC zur Zeit noch auf Multimedia und Kommunikation beschr nkt sind als Erweiterungen auch klassische Peer to Peer Anwendungen wie zum Beispiel Filesharing denk bar Hier k nnten die Nutzer ber UbiMuC das Netz nach interessanten Inhalten durchsuchen um diese danach herunterzuladen Ebenfalls denkbar w ren auch Streams die mit Hilfe von UbiMuC bereitgestellt werden und an bestimmten Orten einfach von den Benutzern abgeru fen werden k nnen So k nnten Touristeninformationen aktuelle Abfahrpl ne oder hnliche Informationen durch fest installierte WLAN Ger te ber UbiMuC zur Verf gung gestellt wer den Diese Dienste k n
28. Wiederverei nigung mit dem Hauptentwicklungszweig beseitigt wurden Implementierungsdetails der ein zelnen Komponenten sowie die Beschreibung der aufgetretenen Probleme werden in diesem Abschnitt behandelt 4 5 2 1 Audio Implementierung Im Gegensatz zu den Vorg ngermodellen lassen sich beim N810 die Audio Komponenten nicht durch die Linux Audio Standard Schnittstelle ALSA ansprechen Der DSP als Soundkarte muss demnach auf eine andere Weise angesteuert werden Auch das Mikrofon ist hiervon betroffen Der Zugriff ist hier allerdings ber die mitgelieferten GStreamer Plugins m glich die explizit Ausg nge des DSP als Audioquellen zulassen Neben einem PCM Signal bietet der DSP auch mehrere hardwareseitig enkodierte Streams an Werden diese Streams genutzt entlasten diese sp rbar den Hauptprozessor des Systems der in dem Fall keine softwareseitige mehr Enkodierung durchf hren muss Um dieses Potenzial zu nutzen wird das G 729 Ausgangssignal des DSP genutzt Weiteres Optimierungspotenzial bieten die verschiedenen Konfigurationsm glichkeiten des ver wendeten GStreamer Plugins Eine dieser Konfigurationsoptionen erlaubt Datenpakete nur dann zu erzeugen wenn ein gewisser Eingangspegel am Mikrofon anliegt Mit diesem Wissen wurde eine effiziente Enkodierung des Mikrofonsignals in UbiMuC implementiert 4 5 2 2 Kamera Integration Die im N810 verbaute Kamera unterst tzt Video4Linux2 VAL2 und ist demnach ber stan dardisierte Methoden
29. ansprechbar Auch hier verwendet UbiMuC das Multimedia Framework GStreamer Als Codec kommt der vorher beschriebene Hantro 4200 zum Einsatz Um eine optimale Performanz zu erreichen wurden Abstriche bei Qualit t und Darstellung in Kauf 74 4 5 Multimedia genommen So ist die Aufnahmeaufl sung softwareseitig auf 176x144 Pixel begrenzt w hrend der Stream auf der Empf ngerseite mit einer Aufl sung von 352x288 Pixel wiedergegeben wird Die Aufnahme selbst erfolgt mit acht Bildern pro Sekunde Als problematisch erwies sich die Integration in die Benutzeroberfl che Referenzprogramme verbinden die Ausgabefl che mit der Ausgabesenke sobald die Ausgabefl che sichtbar wird Da Streams in UbiMuC nur gestartet werden k nnen wenn diese nicht angezeigt werden war dieses Vorgehen nur ber Umwege m glich Beim Starten einer Konferenz wird noch vor Senden und Empfangen der Streams auf den Konferenz Tab des Benutzerinterfaces mit dieser Ausgabefl che gewechselt Ein weiteres Problem bildete die Anzeige selbst Wenn w hrend der Wiedergabe eines Streams die Wiedergabefl che teilweise verdeckt wurde war selbst nach dem Wiedereinblenden keine Anzeige auf den zuvor verdeckten Teilen dieser Anzeigefl che mehr m glich Stattdessen blie ben diese Fl chen wei Eine L sung brachte das Abschalten des Double Bufferings f r das Anzeigeelement Durch diese Implementierungen sind das Streamen eines Videobildes sowie das Anzeigen eines Streams
30. beschriebenen Verwaltungsaufgaben hinaus enth lt die WIR Schicht die Module f r die Nut zerverwaltung den Paketdienst sowie die Multimedia Ansteuerung und den Chat Auf diese wird in Kapitel 1 genauer eingegangen 2 6 Benutzeroberfl che Bereits vor dem eigentlichen Implementieren wurden gewisse Anforderungen an die GUI for muliert Als oberstes Ziel wurde dabei gew hlt dass s mtliche wichtigen oft benutzten Funk tionen leicht zug nglich sind Des Weiteren sollte die GUI das von anderen Programmen des N810 gewohnte look and feel bieten so dass sich der Nutzer sofort zurecht findet Dieser Ansatz wurde durch folgenden Aufbau realisiert G nUbiMuC x Buddyliste Player Chat Buddies Benutzerinformationen Agent Nils Alias Aaent Nils Agent Blue Vorname Agent Agent Forest Nachname Nils Agent Black Geburtsdatum Wohnort Telefon Nr Hobbys Blau eMail a uE OG Abbildung 2 6 Ein Bild der finalen GUI 25 2 Grundlagen Der gr te Teil des Bildschirms wird von dem jeweils aktiven Programmteil Buddyliste Chat oder Videokonferenz genutzt Das Umschalten zwischen den einzelnen Programmteilen ist ber einige beschriftete Reiter am oberen Bildschirmrand m glich Eine Leiste am unteren Bildschirmrand bietet dem Nutzer durch bebilderte Icons die M glichkeit den gerade aktiven Programmteil zu steuern Weniger h ufig benutzte Programmteile sind ber einen Klick auf den Programmnamen er reichb
31. dass eine zu Beginn ermittelte Route zum Zeitpunkt der Nutzung nicht mehr existiert Ist dies der Fall muss als Reaktion auf den Datentransfer eine neue Route aufgebaut werden Wird dies grunds tzlich durchgef hrt spricht man von reaktiven Verfahren dem Gegenst ck zu proaktiven Verfahren Diese bilden die Routen ausschlie lich bedarfsorientiert Das hei t dass erst bei Nutzdaten versand eine Route zum Zielpeer gesucht wird Der Versand der Nutzdaten wird dadurch zwar verz gert aber es werden keine unn tigen Routen aufgebaut Wir haben uns im Rahmen unseres Projektes f r ein reaktives Verfahren entschieden N heres dazu im Kapitel 4 2 1 2 2 4 Avahi ZeroConf Um innerhalb von Ad Hoc Netzwerken TCP IP basierte Kommunikation zu erm glichen muss die Verteilung von IP Adressen dezentral bewerkstelligt werden Bei Netzwerken mit stati scher Benutzerzahl und bekannten Benutzern ist es m glich diese im Voraus fest zuzuteilen In unserem Fall ist weder das eine noch das andere gegeben weswegen wir auf dynamische Zuteilungsverfahren zur ckgreifen F r eine dynamische IP Adressvergabe existiert ein Standard Zero Configuration Networ king oder auch kurz ZeroConf Dieser regelt die Zuteilung von IP Adressen aus dem Raum 169 254 0 0 16 Avahi ist eine unter Linux lauff hige und freie Implementierung des Zero Conf Standards Da dieser Standard prinzipbedingt ohne zentrale Kontrollinstanz auskommen muss werden im Standard ebenfalls Mech
32. einen weiteren Eintrag zu generieren Im sich daraufhin ffnenden Fenster Katalogdetails sind die einzelnen Felder mit folgenden Werten zu f llen Adresse http 1ls12 www cs tu dortmund de ubimuc repository Komponenten main Programmmanager Katalog Katalogdetails Katalogname ubiMuC Repository Internetadresse http Is12 www cs tu dortmund de ubimuc repi Verteilung Komponenten main Deaktiviert Abbruch Deinstallieren Einige Pakete im UbiMuC Repository h ngen von Paketen des Maemo Repository ab das standardm ig nicht eingebunden wird Dieses wird auf die selbe Art wie das vorige Repository eingebunden Adresse http repository maemo org Komponenten free non free Nun kann man UbiMuC mittels des grafischen Paketmanagers oder mit root Rechten per Kommandozeile mittels des Befehls apt get install ubimuc installieren 86 7 3 Benutzerhandbuch 7 3 Benutzerhandbuch Programmstart Um das Programm zu starten muss zuerst das entsprechende Paket mittels Paketmanager installiert werden siehe Abschnitt 7 2 Danach gen gt die Eingabe des Befehls ubimuc auf der Konsole user nokia N810 51 3 ubimuc Das Starten des Programms kann einige Sekunden in Anspruch nehmen Sobald der Initialisie rungsvorgang abgeschlossen ist wird der Startdialog angezeigt Hier hat man die M glichkeit seinen Nutzernamen nach Belieben zu w hlen st
33. empfangenen Paketen die in Abschnitt 4 2 2 2 genauer beschrieben wird hat der Paketdienst keine weiteren Aufgaben Insbesondere findet keine Sicherung der Paketreihenfolge statt Das ist die Aufgabe der verbin dungorientieren Bidirektionalen Pipeline die dazu die restlichen Header des Datencontainer nutzt Neben der Reihenfolge die die Sequenznummer nutzt wird mit der Verbindungsnum mer eine eindeutige Zuordnung zwischen zwei Endpunkten vorgenommen Zus tzlich werden nicht mehr nur ganze Pakete zwischengespeichert sondern die gesamten Nutzdaten als Byte strom um bei Bedarf auch zeichenweisen Zugriff zu erm glichen Im Laufe der Zeit hat sich herausgestellt dass die Zusatzfunktionen der Bidirektionalen Pipe line f r die Implementierung der in UbiMuC enthaltenden Anwendungen nicht ben tigt wur den F r die Video und Audio bertragung wurde ein UDP Tunnel auf Basis des Paketdienstes entwickelt der in Abschnitt genauer beschrieben wird Chat Nachrichten werden jetzt ebenfalls ber den Paketdienst abgewickelt Und auch f r die bertragung der Informationen der Nutzerverwaltung wurde eine L sung mit der Hilfe der Kontrollnachrichten gefunden auf die in Abschnitt eingegangen wird Die Weiterentwicklung der Bidirektionalen Pipeline wurde damit gestoppt 4 2 2 Implementierung Der Paketdienst bzw das BidiPipe Modul wurden wie auch der Avahi Dienst als Applika tionen in GNUnet eingebunden Die Komm
34. in UbiMuC m glich 75 4 Design 76 5 Evaluierung In diesem Kapitel werden die Tests dargestellt die zur Bewertung der fertigen Software gefah ren wurden Dabei liegt der Schwerpunkt auf Testszenarien die das Zusammenspiel aller fertig entwickelten Komponenten berpr ft die in den vorangegangen Kapiteln beschrieben wurden indem reale Anwendungsf lle mit Hilfe der UbiMuC GUI durchgespielt wurden Insbesondere wurde dabei die ordnungsgem e Interaktion zwischen der GUI der WIR Schicht und den GNUnet Modulen verifiziert Auf die autonomen Tests mit denen die korrekte Funktionswei se der einzelnen Module gepr ft wurde wird hier nicht eingegangen da auf diese bereits in Kapitel 4 in den zugeh rigen Abschnitten eingegangen wurde UbiMuC Systemtest Der Fokus lag hier auf der Kommunikation zwischen den Ger ten und der echten Nutzung des Programms Dazu wurden der Chat und die AV Konferenz in verschiedenen Netzwerktopolo gien getestet und die Auslastung sowie die Qualit t der AV Konferenz dabei beobachtet Es wurden wie in Abschnitt die iptables genutzt um sicherzustellen dass die Ger te nur ihren Vorg nger und ihren Nachfolger in einer Kette sehen k nnen So wird ein echtes Multi Hop Netzwerk aufgebaut bei dem die Kommunikation ber mehrere Zwischenknoten zum Ziel gelangt Es wurden drei unterschiedliche Testaufbauten genutzt Reihentest mit drei Ger ten Hier wurden drei Ger te genutzt bei dem die Kom
35. kommt beispielsweise bei der ISDN Telefonie zum Einsatz F r das N810 existiert ein DSP gest tzter GStreamer Codec der diesen Standard implementiert Auch der Standard G 729 wurde von der ITU verabschiedet Er beschreibt die Kodierung von Sprache per CS ACELP conjugate structure algebraic code excited linear prediction Dieses Verfahren wird vor allem bei Voice over IP Telefonie verwendet Auch hierf r existiert ein DSP gest tzter GStreamer Codec f r das N810 Die Realisierung dieser Pipeline wurde wie in Abbildung umgesetzt Zum Zeitpunkt der Audio Codec Tests stand bereits fest dass RTP als Protokoll der Multime dia Pipeline eingesetzt wird Da im Gegensatz zum G 729 Codec kein RTP De Payloader f r den G 711 Codec auf dem Ger t existiert wurde nur noch der G 729 Codec betrachtet und auf Effizienz berpr ft Analog zu den Video Codecs erfolgte ein Test der Systemauslastung Auch hier wurde die Auslastung durch das Linux System Werkzeug top ermittelt Da CPU und Speicherlast sehr gering waren und die Qualit t auf Empf ngerseite mehr als zufriedenstellend war gab es keine Notwendigkeit weitere Codecs zu testen Ergebnisse Nach den beschriebenen unidirektionalen Tests wurde mit den gew hlten Codecs Hantro4200 Hantro4100 und G 729 ein bidirektionaler Test durchgef hrt Beide Ger te agierten sowohl als Sender als auch als Empf nger Zudem wurden gleichzeitig Audio und Video Pipelines ver wendet Da auch hier keine weit
36. sie abge sendet werden Zus tzlich wird durch sog Covertraffic s mtliches Anfrage und Antwortver halten der Teilnehmer maskiert Zur Gew hrleistung eines hohen Sicherheits und Integrit ts ma es innerhalb von GNUnet wird die Kommunikation dar ber hinaus durch Nutzung von asymmetrischer Kryptographie abgesichert F r einen externen Zuschauer ist also nur ersicht lich dass eine Kommunikation stattfindet nicht jedoch deren syntaktischer oder semantischer Inhalt Das GAP Routing ist fest ins das Filesharing Modul integriert und steht auch nur f r die damit verbundenen Teilfunktionen bereit 19 2 Grundlagen Das Hostlisten Modul Jeder GNUnet Client verf gt in der Basiseinstellung ber eine hartkodierte Adresse die er bei Verbindungsaufname abfragt Unter dieser Adresse ist kontinuierlich eine sogenannte Host liste zu finden welche die zum aktuellen Zeitpunkt dort vorhandenen HELLO Pakete ent h lt GNUnet ben tigt zum sp teren Aufbau von Kommunikationskan len diese HELLO Nachrichten der Teilnehmer mit denen ein Datenaustausch stattfinden soll Innerhalb eines HELLO Pakets befindet sich unter anderem der ffentliche Schl ssel des Absender Peers und ein Zeitstempel Mit Hilfe dieses Schl ssels lassen sich auf Basis des Public Key Prinzips verschl sselte Verbindungen zum Besitzer des zugeh rigen privaten Schl s sels aufbauen Dieser gesicherte Kanal wird allerdings nicht zum Austausch von Massendaten benut
37. sogenannten WIR Schicht entwickelt welche die Steuerzentrale von UbiMuC darstellt W hrend sich die Arbeit in der ersten H lfte der Projektgruppe eher auf eine Recherche in breit gef cherten Themen bezog sollte im Folgenden die Arbeit an Kernthemen forciert werden Um die weitere Planungs und Implementierungsarbeit klarer zu strukturieren wurde deshalb beschlossen einen Projektplan nachfolgend auch als Roadmap bezeichnet f r das zweite Halbjahr zu entwickeln Diese Roadmap dient vor allem der genauen bersicht des Projektfortschritts der Festlegung von Deadlines und der sinnvollen Untergliederung in Arbeitsgruppen In mehreren Iterationen wurde diese Roadmap an unsere Designentscheidungen angepasst Im Folgenden wird aller dings nur die endg ltige Version dargestellt Somit gibt dieses sehr genau den Ablauf des 2 Semesters wieder Die in der Abbildung auf den oberen Ebenen dargestellten Themenkomplexe stellen die zuerst angegangen Aufgabenbereiche dar Die umrahmten Rechtecke stellen die Aspekte dar 26 2 7 Projektplanung des zweiten Semesters die sehr eng miteinander verkn pft sind In hellgrau markierte K sten umfassen grob die ge forderten Minimalziele des Projekts Diese Herangehensweise hat letztlich zu einer Aufteilung in vier bergeordnete Themenbereiche gef hrt die von verschiedenen Kleingruppen bearbeitet wurden Bei diesen vier Bereichen handelt es sich um e Transportschicht e Nutzerverwaltung e Chat
38. verfallen nach dieser Zeit und werden bei GET Anfragen nicht mehr geliefert wenn die Lebenszeit abgelaufen ist Der zweite Wert ber den DHT Eintr ge verf gen ist ihre Kategorie Anfragen an die DHT fordern immer alle Pakete einer Kategorie an Es ist nicht m glich explizit ein einziges Paket zu erhalten Der dritte Block ist f r die Nutzdaten des Pakets Diese k nnen nahezu beliebige Form haben Speichern von Werten in der DHT Das Speichern von Daten geschieht bei Nutzung der DHT entweder in einer MySQL oder einer SQLite basierten Datenbank F r die DHT wird in der Konfigurationsdatei vom GN Unet Dienst eine Maximalgr e an verf gbarem Speicherplatz festgelegt welche auf 64KB vorein gestellt ist Beim Eingehen einer PUT Nachricht wird anhand der zu nutzenden Redundanz und der N he der von Kademlia vorgegebenen XOR Metrik bestimmt ob der Wert auch lokal gespei chert werden soll oder ob er nur weitergeleitet wird Hat der XOR Algorithmus sich dazu entschieden einen Wert von einem PUT Request in der eigenen Datenbank zu speichern so wird berpr ft ob maximal 90 des verf gbaren Speicherplatzes genutzt wird Wird mehr Platz genutzt so werden jene Pakete aus der DHT entfernt deren Lebenszeit abgelaufen ist Anschlie end wird der Wert in der gew hlten Datenbank mit der zugeh rigen Lebenszeit gespeichert Es gibt keine explizite Operation zum L schen von veralteten Eintr gen Dies wird nur durch gef hrt we
39. DataBlock hnelt vom Aufbau her den beiden zuvor beschriebenen Nachrich tenformaten Der wesentliche Unterschied dabei ist dass im UbiMuC DataBlock auch die eigentlichen Nutzdaten gesendet werden Weiterhin beinhaltet der UbiMuC DataBlock auch den zuvor definierten Datacontainer Diese beiden Nachrichtenformate befinden sich jedoch auf unterschiedlichen Ebenen der Da tacontainer auf der WIR Schicht und der UbiMuC DataBlock auf der GNUnet Ebene Der Datacontainer ist daf r da um aus komplexen Datenstrukturen einfache Bytearrays zu erzeu gen die sich dann leicht in GN Unet Datenbl cke verpacken lassen 41 4 Design Der UbiMuC DataBlock beinhaltet den Datacontainer die Absender und Empf ngerdaten und alle Informationen die zum routing ben tigt werden Als Typ der Nachricht kann hier Undefiniert Kontrolldaten Datei Text oder Multimedia definiert werden Am Ende des Headers befindet sich das Feld Datenl nge in dem die L nge der nachfolgenden Nutzda ten angegeben wird Der Payload Bereich besteht aus den Nutzdaten die an den Empf nger adressiert sind Der UbiMuC DataBlock ist in der Abbildung 4 4 dargestellt L nge Typ Ziel Quelle Hop Anzahl Route Datenl nge Nutzdaten 2 Byte 2 Byte 64 Byte 64 Byte 4 Byte Hop Anzahl 64 Byte 4 Byte flexibel Header Payload Abbildung 4 4 Aufbau des UbiMuC DataBlock 4 2 1 2 Routingkonzepte
40. Die verschiedenen Chat Sitzungen sind f r den Benutzer in Form von Karteikarten separiert wobei die Reiter mit den jeweiligen Aliasnamen zur besseren bersicht beschriftet sind In einem Tab ist ein Textfenster enthalten welches die gesendeten und empfangenen Nachrich ten anzeigt Die effektive Abgrenzung der einzelnen Chat Tabs untereinander wird ber die UbiMuC Adressen der einzelnen Buddies sichergestellt so dass durchaus zwei Tabs mit glei cher namentlicher Beschriftung angezeigt werden k nnen welche aufgrund der abweichenden Adressen jedoch zu verschiedenen Benutzern geh ren GnUbiMuC Buddyliste Player Chat Agent Black x lt lt Chat gestartet gt gt Agent Orange Hallo Agent Black Servus Agent Black Hi Agent Orange Hallo Abbildung 4 11 Exemplarische Chat Sitzung Diese Tabs werden entweder durch Aktionen des Benutzers erstellt oder extern durch den Empfang einer Chat Nachricht angestofen Die Tabs k nnen zu beliebigen Zeitpunkten ge schlossen werden wobei dann alle dargestellten Informationen verloren gehen Es findet keine automatische Speicherung der Sitzungen statt und es ist auch nicht vorgesehen dass Sitzun gen manuell durch den Benutzer gespeichert werden k nnen Die Abbildung 4 11 zeigt einen Screenshot im laufenden Betrieb wobei hier eine einzige Chat Sitzung exemplarisch dargestellt wurde Wie bereits erw hnt und in der Abbildung visualisiert sind die erstellten Chat Tabs mit dem
41. GNUnet Revision 1179 drei Ger te 4 4 Test mit GNUnet Revision 1187 drei Ger te 4 5 Auswertung der Video Codec Tests 6 1 Kurz bersicht der Minimalziele 101
42. GetRoute angesto en Sobald eine Route aufgebaut werden konnte werden die Daten unmittelbar versendet Wurde innerhalb von zehn Sekunden keine Route gefunden wird das Paket verworfen Um eine abgebrochene Verbindung erkennen zu k nnen ohne das Netzwerk zu stark zu be lasten wurde ein rudiment res Schema zum Versenden von ACK bzw NAK Nachrichten implementiert Beim Eingang eines Datenpakets wird aus den letzten 4 Byte der Nutzdaten ein ACK Paket erstellt welches an den unmittelbar vorhergehenden Hop gesendet wird Trifft andererseits bei einem Hop nach Versenden bzw Weiterleiten eines Pakets innerhalb von drei Sekunden kein ACK Paket ein so wird ein NAK Paket generiert welches an den urspr nglichen Absender des Pakets zur ckgesendet wird In diesem NAK Paket ist das kom plette nicht zugestellte Datenpaket enthalten damit eine erneuter Zustellversuch gestartet werden kann Durch die Nutzung des in GN Unet integrierten CRON Dienstes siehe Abschnitt 3 1 2 k nnen die oben angegebenen Zeitschranken berpr ft werden ohne das der Programmfluss angehal ten werden muss 4 2 2 1 Handler In der UbiMuC Transportschicht gibt es vier verschiedene Handler die sich um die Verarbei tung der unterschiedlichen Nachrichtentypen k mmern e Datencontainer e GetRoute e GetRouteReply e WIR Schicht Handler f r Datencontainer Der Handler f r den Datencontainer empf ngt die Datencontainerpakete inklusive Route ver
43. L nge der eigentlichen SourceRoute au erdem erh ht sich gleichzeit die Anzahl der GetRoute Pakete die von jedem einzelnen Peer losgeschickt wer den Da UbiMuC aufgrund der Reichweitenbeschr nkung von Ad Hoc Netzwerken auf kleine Topologie ausgelegt ist sollte dieser Fall eigentlich keine Probleme bereiten 44 4 2 UbiMuC Transportschicht 4 2 1 3 Vermittlungskonzepte Durch das auf GNUnet aufbauende Netzwerk sind wir nun in der Lage Daten zwischen Peers auszutauschen In Sachen Funktionalit t befinden wir uns auf der dritten Schicht der Netz werkschicht des ISO OSI Referenzmodells Analog zu diesem Modell ist es nun das Ziel die Lransportschicht zu implementieren die es zus tzlich erm glicht einzelne Dienste auf einem Peer zu unterscheiden Transportdienste Die Transportschicht von UbiMuC sah urspr nglich zwei Dienste vor den Paketdienst und die darauf aufbauende Bidirektionale Pipeline Von den Funktionen her hneln diese Dienste dem User Datagram Protocol UDP und dem Transmission Control Protocol TCP Der Paketdienst von UbiMuC ist hierbei das verbindungslose Pendant zu UDP und f r das Senden und Empfangen von unabh ngigen Datencontainern zust ndig Die Typ Enumeration der Datacontainer Objekte bernimmt in diesem Fall die Aufgabe der Portnummer und dient der Unterscheidung von unterschiedlichen Diensten Abgesehen von der Vorsortierung nach Pakettyp und Zwischenspeicherung von
44. RMI1 basierende CPU einen 2D 3D Beschleuniger einen digitalen Signalprozessor und einen Imaging Video Accelerator zur Verf gung Die ARM11 CPU ist mit 400 MHz getaktet und hat Zugriff auf 128 MB mobile DDR memory Verbindung zur Au enwelt erh lt man ber das dem IEEE 802 11 b g Standard folgende WLAN Modul oder via Bluetooth Als Eingabeger t fungieren sowohl der ber hrungssensitive Bildschirm als auch eine Daumentastatur Weitergehende Informationen ber die verbaute Hardware k nnen auf der zugeh rigen Internetseite von Nokia nachgelesen werden 1 Softwareplattform N810 Das Betriebssystem des N810 ist linuxbasiert Die verwendete Distribution baut auf Maemo Linux auf welches selbst von Debian abstammt Es ist explizit auf die Nutzung mit kleinen eingebetteten Systemen auf ARM Basis ausgelegt Die grafische Oberfl che wird mithilfe von X11 dargestellt und sowohl ein Mediaplayer als auch ein Browser und Kommunikationssoft ware sind entweder schon vorinstalliert oder durch den Nutzer nachtr glich installierbar Das gesamte System baut dabei weitestgehend auf nur leicht modifizierten Standardkomponen ten auf wie sie auch bei vielen Linuxdistributionen zu finden sind Entsprechend sind viele der zur nachtr glichen Installation angebotenen Programme Portierungen gebr uchlicher Soft ware wie zum Beispiel MPlayer 2 oder Pidgin 3 eine Multiprotokoll Chat Software Die Entwicklung von Software f r das N810 geschieht
45. Verbindung annimmt ClientB Oient Elnitiiere Konferenz Baue Request Paket i Empf nger H sch Sender H ah 1 Request Paket Maximale Warte zeit 30 Sekunden Abbildung 4 18 Ablauf beim Aufbau einer AV Konferenz Schritt 1 Schritt 1 Von Client A wird wie in Abbildung 4 18 zu sehen ist ein Request Paket erstellt und mit un serem Datencontainer als AV Konferenz Paket an den gew hlten Konferenzteilnehmer Client B geschickt Au erdem wird bei Client A der UbiMuC Hash von Client B in der Variablen current connection vermerkt Nun beginnt ein 30 Sekunden langes Zeitfenster in dem auf 70 4 5 Multimedia eine Antwort von Client B gewartet wird Letztlich wird beim Warten durchgehend gepr ft ob connection established auf TRUE gesetzt ist Geht innerhalb der festgelegten Wartezeit keine Antwort ein so wird die Variable current connection wieder zur ckgesetzt und alles erscheint f r den Pakethandler so als ob nie eine Anfrage verschickt wurde i Client A rines Request Paket Client p Jl Konferenz best tigen Behandlung H WENN current_connection i i i DANN Dialog Ferster i 4 SONST Maximale Warte zeit i 30 Sekunden Annahme B will Konferenz A Setze current_connection Hash A Baue Request Paket Empt nger Hash Sender Hash i Flags Request Paket i III Beginne Konferenz
46. altung die es erlaubt bekannte Netzteilnehmer in einer Freundesliste zu speichern und verwalten Aufbauend darauf bilden der Chat und die Audio Video Konferenz die M glichkeit mit bekannten Teilnehmern in Kontakt zu treten Bei jedem einzelnen dieser Themen wird zun chst das Konzept erl utert und danach werden gegebenenfalls die zu Grunde liegenden Algorithmen genauer erkl rt Im Anschluss daran wird jeweils auf deren Implementierung eingegangen 4 1 Datencontainer Der modulare Aufbau von UbiMuC erfordert es eine einheitliche Schnittstelle f r Datenpakete zu entwickeln die zwischen den Applikationsteilen ausgetauscht werden Unter Beibehaltung dieser Schnittstelle kann man einzelne Module wie beispielsweise den Splitter der f r das Vorsortieren von empfangenen Paketen zust ndig ist ohne gro en Aufwand nach Belieben austauschen GNUnet enth lt zwar bereits ein Paketformat das f r unsere Daten verwendet werden kann allerdings beinhaltet dieses einige Nachteile 37 4 Design e Da GNUnet f r das eigene Datenformat C Strukturen einsetzt die mit globalen Funk tionen manipuliert werden w rde das objektorientierte Paradigma gebrochen e Das Verwenden von GNUnet spezifischen Teilen innerhalb der oberen Schichten von UbiMuC w rde zudem die Modularit t gef hrden da die Transportschicht damit nicht mehr einfach ausgetauscht werden k nnte e Im Nachrichtenheader fehlen einige Felder die wir zwingend zur
47. an umliegende Peers weitergeleitet Diese pr fen nun ob sie die Anfrage beantworten k nnen oder leiten die Suche an andere Peers weiter Im Falle der Weiterleitung speichern sie jedoch dass sie eine Anfrage weitergeleitet haben von welchem Peer sie eintraf und an welche Peers sie weitergeleitet wurde Nach dem Ablauf einer festen Zeitspanne verfallen diese lokalen Routingtabellen jedoch Sendet ein Peer nun Antworten auf die Anfrage ist jeder der einzelnen Peers in der Lage die Daten weiterzuleiten so dass diese bei der Anfragequelle ankommen k nnen Auf diese Weise wird ein sehr flexibles Routing der Daten ber das Netzwerk erm glicht ohne das einem externen Betrachter der Ursprung der Anfrage oder die eigentliche Datenquelle offenbart wird Das Routingskonzept hat allerdings als Konsequenz dass Nutzdaten zwischen den Teilnehmern nur dann ausgetauscht werden k nnen wenn es eine Anfrage und darauf passende Antworten gibt da ohne dieses Vorgehen keine passenden Zuordnungen bei den Zwischenpeers vorliegen und kein Routing der Daten stattfinden kann Die eigentlichen Anfragen des Filesharing Moduls werden inhaltlich in Form von Hashwerten und dazu korrespondierenden Datenbl cken gestellt Um den anf nglich erw hnten hohen Grad der Anonymit t innerhalb des GN Unet Netzes zu gew hrleisten werden zwei zentrale Konzepte angewendet Auf der einen Seite werden die beschriebenen Anfragen und Antworten auf eine einheitliche Gr e gebracht bevor
48. anfangs haupts chlich damit besch f tigt wie die Audio Video Eigenschaften des N810 effizient genutzt werden k nnen Mittels GStreamer konnte ohne gro e Hardwareeinschr nkungen auf die Webcam und das Mikrofon zugegriffen werden Jedoch wurde die gr te Einschr nkung der Bildqualit t immer noch durch die geringen Datentransferraten erzeugt Deshalb war die Auswahl eines geeigeneten Videoco decs von gro er Bedeutung um die bertragung des Bildes so fl ssig und deutlich wie m glich zu gestalten Zum Auf und Abbau einer Konferenz wurde zus tzlich eine Handshake Routine entwickelt Zusammenfassung Durch die Kombination der von GNUnet angebotenen Peer to Peer Funktionali ten mit der eigens entwickelten UbiMuC Software wurde ein funktionsf higer Prototyp geschaffen mit dem innerhalb von WLAN Netzen Audio Video Konferenzen und Chat Session abgehalten werden k nnen Au erdem k nnen Freunde durch die Kontaktliste abgespeichert und damit leicht wiedergefunden werden In Tests wurde gezeigt dass die von uns entwickelten Konzepte umgesetzt wurden Allerdings st t man bei Verwendung der Software schnell an die technischen Grenzen des verwendeten Internet Tablets Daher bleibt die Qualit t bei Video bertragungen teils hinter den Erwartungen zur ck Trotzdem wurden die im Zusammenhang mit dem Datentransfer angestrebten Funktionen umgesetzt 82 6 2 Vergleich mit Minimalzielen Es ist m glich Ad Hoc Netzwerke mit den Ger
49. anismen zur Konfliktbew ltigung bei mehrfach vergebenen Adressen festgeschrieben Die Adresse wird pseudozuf llig gew hlt damit bei jedem Neuverbinden mit dem Netzwerk nach M glichkeit die selbe Adresse ausgew hlt wird Weiterhin sieht der Standard eine dezentrale Namensaufl sung und einen Mechanismus zum Bekanntgeben und Auffinden von Netzdiensten vor Die dezentrale Namensaufl sung verl uft analog zum bekannten DNS System des Internets allerdings kommt hier kein Server zum Einsatz sondern die Anfragen werden an eine Multicast Adresse versendet und vom Namens inhaber beantwortet 22 2 5 Struktur von UbiMuC Die Zuteilung von IP Adressen wird bereits vor dem Start von UbiMuC bei der Auswahl der Verbindung am N810 durchgef hrt Die beiden anderen beschriebenen Dienste die Namensauf l sung und das Dienstesystem werden durch UbiMuC genutzt Durch unsere Implementierung wird sichergestellt dass alle Ger te innerhalb ihres Empfangsradius unterschiedliche Namen besitzen Dies wird zwar vom Standard nicht vorgesehen da es durchaus Anwendungsf lle f r solche Szenarien geben kann wie zum Beispiel die Lastverteilung auf gleichartigen Netzwerk Ressourcen Deswegen m ssen wir unterschiedliche Namen durch unsere Implementierung si cherstellen Weiterhin wird ber Avahi der GNUnet Dienst bekanntgegeben Alle Peers die sich im ak tuellen Empfangsradius befinden erhalten unmittelbar nach Bekanntgabe des Dienstes diese Informati
50. ar ber das so aufrufbare Optionsmen kann der Nutzer bestimmte Programmeinstel lungen wie die f r die Videokonferenz benutzten Ports modifizieren ohne eine Datei von Hand editieren zu m ssen Beim Design der GUI musste letztendlich nicht nur auf den gew nschten Benutzerkomfort sondern auch noch auf die Hardwaregegebenheiten geachtet werden S mtliche Optionen und Schaltfl chen durften weder zu klein da sie sonst nicht mehr lesbar sind noch zu gro da sie sonst Platz wegnehmen der anderweitig gebraucht wird sein Zur Implementierung wurde das Hildon Framework benutzt welches auf GTK 2 0 9 aufsetzt Durch den Einsatz von Hildon konnte das N810 spezifische look and feel erreicht werden 2 7 Projektplanung des zweiten Semesters Die bisher in diesem Kapitel genannten Themen stellten die Basis f r die weiterf hrende Entwicklung des Programms UbiMuC dar Diese Themenbereiche wurden berwiegend im ersten Halbjahr der Projektgruppe herausgearbeitet Nachdem entschieden wurde sich auf reine Peer to Peer Netze zu beschr nken wurde GNUnet als grundlegendes Framework f r die Entwicklung unserer Software gew hlt Da reine Peer to Peer Netze serverlos arbeiten wurden Ad Hoc Netze als bevorzugte Netz werkinfrastruktur festgelegt Deren Umsetzung wird von Avahi bernommen welches bereits als Applikation in GNUnet integriert wurde Als Bindeglied zwischen GNUnet und der grafi schen Oberfl che wurde ein erstes Konzept der
51. arbeitet sie und sendet sie danach weiter Nach dem Empfangen wird das Paket deserialisiert und berpr ft an welchen Peer es adressiert ist Falls es an den aktuellen Peer geht wird es 46 4 2 UbiMuC Transportschicht f r die WIR Schicht verpackt serialisiert und an die WIR Schicht gesendet Wenn ein anderer Peer das Ziel ist wird es zum n chsten Hop weitergeleitet und dem vorherigen Knoten ein ACK gesendet Handler f r GetRoute Nach dem Deserialisieren vergleicht der Handler f r die GetRoute Pakete die Zieladresse mit der eigenen Adresse Sind die beiden Adressen gleich wird ein GetRouteReply Paket angesto en Bei unterschiedlichen Adressen tr gt der Handler die Adresse des Peers in die Routingtabelle ein und sendet das aktualisierte Paket an seine benachbarten Hosts weiter Handler f r GetRouteReply Der Handler f r die GetRouteReply Pakete nimmt das Paket entgegen deserialisiert es und berpr ft die Zieladresse Sofern der Peer nicht selber das Ziel ist leitet er es an seinen Vorg nger in Routingtabelle weiter und speichert die Source Route f r kommende Routings Wenn der Peer das Ziel war f gt er die erhaltene Source Route in die lokale Routingstruktur ein Handler f r die WIR Schicht Der Handler f r die WIR Schicht nimmt die Pakete aus der WIR Schicht entgegen und startet das GetRoute Wenn eine Source Route gefunden wurde werden die Nutzdaten mit dem Routingpfad vers
52. artup title Agent Orange Los gehts Tab Esc PgUp PgDn Ctrl Abbildung 7 1 Nickname Eingabe beim Programmstart GUI Screenshot Wurde das Programm bereits benutzt wird der zuletzt verwendete Name angezeigt Ein Klick auf Los gehts bernimmt den eingetragenen Namen und ffnet die eigentliche Benutzer oberfl che 87 7 Appendix Die Benutzeroberfl che Die Benutzeroberfl che besteht aus drei Teilen e Der Buddyliste e Dem Chatfenster e Dem Playerfenster Zwischen diesen kann mit den Reitern am oberen Bildschirmrand umgeschaltet werden G nUbiMuC Buddies Benutzerinformationen Agent Nils Alias Aaent Nils Agent Blue Vorname Agent Agent Forest Nachname Nils Agent Black Geburtsdatum Wohnort Telefon Nr Hobbys Blau eMail a u WO 4 Abbildung 7 2 Navigationsreiter in der UbiMuC Benutzeroberfl che GUI Screenshot Bei Programmstart ist die Buddyliste standardm ig ausgew hlt 88 7 3 Benutzerhandbuch Die Buddyliste Die Buddyliste ist das Herzst ck des Programms Von hier aus k nnen s mtliche Funktio nen angesto en werden S mtliche Kontakte werden in einer Liste gespeichert Die Farbe der Eintr ge gibt dabei deren Online Status wieder Rot steht f r offline und Gr n f r online Wenn man einen Kontakt ausw hlt erscheint auf der rechten Bildschirmseite ein Kasten mit Informationen Angezeigt wird hier der Alias des ausgew hlten
53. assung und Integration der benutzten Softwaresys teme betrifft ist besondere Sorgfalt wichtig da diese Komponenten f r einen reibungslosen Ablauf der Ad Hoc Community UbiMuC unausweichlich sind Im Anschluss an erste konzeptionelle Arbeiten und die Planungsphase sind die eigentlichen Funktionalit ten von UbiMuC zu erstellen Diese m ssen dabei im Kontext des mobilen End ger tes Details in Abschnitt 1 4 und der geplanten Nutzungsszenarien entsprechend im plementiert und getestet werden Eine Herausforderung stellt dabei auch die Anpassung der Software an das Endger t dar da sowohl mit Schwierigkeiten hinsichtlich der vorhandenen Rechenleistung als auch des Speicherplatzes zu rechnen ist Weiterhin gilt es ebenfalls die Laufzeit der Batterie und die gesamte Ger tauslastung im Blick zu halten da die nutzbaren Ressourcen durch die Zielplattform limitiert sind W hrend der Implementierungsarbeiten ist durch geeignete und gut dokumentierte Schnitt stellen darauf zu achten dass andere parallel entwickelte Programmteile auf den eigenen Modulen und Funktionen aufsetzen k nnen Nach Abschluss der einzelnen Anforderungen be ziehungsweise Fertigstellung von Unterfunktionen muss durch geeignet ausgew hlte Tests und Probel ufe sichergestellt werden dass die entwickelten Programmteile ihre Arbeit korrekt und wie gew nscht durchf hren Zuletzt ist ein Abschlusstest durchzuf hren der die anf nglich definierten Anforderungen mit der tats chl
54. auen l sst Aufbauend auf der Netzwerkebene durch den Paketdienst bekannt aus Abschnitt 4 2 2 2 ben tigt das Chat Modul also nur die eigentlich zu bermittelnde Nachricht und die Adresse des Zielpeers in Form seiner UbiMuC Adresse Folgen der Architektur Aufgrund der dezentralen Netzwerkarchitektur und dem fl chtigen Charakter des Ad Hoc Netzwerkes kann eine Chat Sitzung ausschlie lich zu Benutzern aufgebaut werden die in der zugrundeliegenden DHT Struktur vergleiche Abschnitt als online verzeichnet sind Ist ein Benutzer nicht online liegt f r ihn keine g ltige Adresse vor so dass an ihn gesen dete Nachrichten niemals ihr Ziel erreichen w rden Da es im Vergleich zu anderen Instant Messenger Programmen wie ICQ bei UbiMuC strukturbedingt keinen zentralen Anmelde und Pufferserver gibt k nnen keine Offline Nachrichten f r die Benutzer hinterlassen werden Das 59 4 Design Chat Modul ist demnach so entworfen worden dass die Sitzungen nur dann aufgebaut wer den wenn eine g ltige Adresse f r den Zielteilnehmer vorliegt und ein Nachrichtenaustausch berhaupt m glich ist Was die Zustellung und konkrete Bearbeitung Senden und Empfangen von Daten betrifft baut das Chat Modul vollst ndig auf dem Paketdienst auf Integration in die GUI Der Chat ist ber einen eigenen Tab in der GUI erreichbar und l sst sich au erdem durch Anw hlen von Freunden aus der Buddyliste durch eine Chat Funktion direkt starten
55. auf beiden Seiten die Ports ge ffnet und Daten von Kamera und Mikrofon k nnen ausgetauscht werden Dieses einfache Schema erm glicht es einen Handshake leicht zu realisieren doch ist es schwierig ihn so zu erweitern dass Kon ferenzen mit mehr als zwei Teilnehmern oder mehrere Konferenzen gleichzeitig erm glicht werden Allerdings wird dieses in den Anforderungen von UbiMuC nicht gefordert und w rde die vorhandene Hardwareplattform h chstwahrscheinlich berlasten Protokoll des Verbindungsabbaus Der Verbindungsabbau ist im Vergleich zum Verbindungsaufbau noch einfacher gehalten Es wird das gleiche Datenpaket wie beim Verbindungsaufbau verwendet Dieses besteht aus dem Hashwert des Empf ngers dem Hashwert des Senders und Flags Im Gegensatz zum Verbin dungsaufbau sind hier nun die Flags gesetzt So werden beim Verbindungsabbau keine neuen Datentypen verwendet sondern nur die Datenformate des Verbindungsaufbaus wiederverwen det Daher muss an dieser Stelle nur der Handler angepasst werden damit die entsprechenden Datenpakete mit den gesetzten Flags korrekt behandelt werden Beendet ein Benutzer nun die Konferenz an der er teilnimmt so wird an den Konferenzpartner eben diese Nachricht geschickt Der Sender schlie t nun seine Empfangs und Sende Ports Zudem werden sowohl die Kamera als auch das Mikrofon abgeschaltet Beim Eintreffen der Nachricht ffnet sich nach dem berpr fen des Hashwertes des Absenders auf der Empfangsseite ei
56. bau einer Verbindung zu einem anderen Peer ben tigt der Quellpeer zuerst einmal die eindeutige GN Unet Adresse des Ziels Deshalb ist ein vorhandenes HELLO Paket des Zielpeers zwingend notwendig Ohne dies kann keine Route aufgebaut werden Bevor jedoch GetRoute angesto en wird findet eine Pr fung statt ob nicht bereits eine g ltige Route zum Ziel existiert Besitzt der Quellpeer keinen Routingpfad zum Zielpeer so startet er erst dann das GetRoute Protokoll Mithilfe der vorliegenden Zieladresse wird ein GetRoute Pakete erzeugt welches an alle erreichbaren Nachbarn verschickt wird Diese m ssen dann gem des nun folgenden Routings f r die Bearbeitung des GetRoute Pakets sorgen 42 4 2 UbiMuC Transportschicht GetRoute Erh lt ein Peer eine GetRoute Nachricht pr ft er zuerst ob seine eigene GNUnet Adresse mit der angegebenen Zieladresse innerhalb des GetRoute Paketes bereinstimmt Ist dies der Fall antwortet der betroffene Peer mit einem GetRouteReply auf die Nachricht welches er an den Peer schickt von dem er die GetRoute Nachricht erhalten hat Au erdem speichert der Empf nger die im GetRoute Paket enthaltene Peerliste als Routingpfad zur Quelle ab Stimmt die Zieladresse hingegen nicht mit der eigenen Adresse berein so muss das Paket zwangsl ufig weitergeleitet werden Bei der Weiterleitung eines GetRoute Pakets muss jeder Peer dabei seine eige
57. d wie lange zur verf gung stehen soll Die Applikation Avahi realisiert die von uns genutze Ad Hoc Netzwerkstruktur Da wir keine zentrale Verwaltungsinstanz haben wird eine verteilte Datenstruktur ben tigt Diese erhal ten wir durch das DHT Modul Um eine Kommunikation zwischen den Clients aufzubauen benutzen wir die Hostliste die Adressen von den GN Unet Clients enth lt N here Erl uterungen zu den Funktionsweisen des DHT und des Hostlisten Moduls werden in den n chsten Abschnitten gegeben 3 1 3 1 DHT Modul GNUnet bietet ber das DHT Modul eine verteilte Datenstruktur an welche ihren Inhalt mit gewisser Redundanz auf alle Clients die dieses Modul aktiviert haben verteilt DHT steht dabei f r Distributed Hash Table ins Deutsche bersetzt verteilte Hashtabelle Urspr ng lich diente dieses Konzept als eine M glichkeit Informationen ber von Peers zur Verf gung gestellten Inhalt im Netzwerk zu verbreiten ohne eine zentrale Daten und Infrastruktur zu ben tigen Grunds tzlich baut die in GNUnet verwendete DHT Implementierung wie sie ur spr nglich in einem Paper beschrieben wurde 10 auf Kademlia auf Bei einer verteilten Hashtabelle werden die zu speichernden Werte ber die verschiedenen Knoten im Netzwerk verteilt Beim Suchen nach Eintr gen muss eine Anfrage an das Netzwerk verschickt werden so dass im Anschluss Antworten von verschiedenen Knoten eingehen Eine Besonderheit der DHT ist dabei dass nich
58. delt sich um einen MPEG4 Codec fiir ARM basierende Systeme der verschiedene Profile unter st tzt Auch der Standard 4 263 wird von ihm unterst tzt ein Standard der vor allem f r Videokonferenzen ausgelegt ist Als Dekoder wird der Hantro4100 von On2 Technologies Inc verwendet Der oben be schriebene Testaufbau wurde durch folgende Kommandozeilen Abbildung 4 14 umgesetzt Sende Pipeline gst launch vAl2src video x raw yuv width 176 height 144 framerate fraction 8 1 hantro4200enc rtph263pay udpsink host 192 168 178 27 port 5000 Empfangs Pipeline gst launch udpsrc port 5000 caps application x rtp clock rate 90000 rtph263depay hantro4100dec xvimagesink Abbildung 4 14 Sende und Empfangspipeline mit Hantro Codecs Die Systemauslastung beider untersuchter Video Codecs im Testsystem wurde durch das Linux System Werkzeug top ermittelt Tabelle 4 5 veranschaulicht CPU und Speicherlast der beiden Codecs 65 4 Design Die Werte beider Codecs hneln sich Im Vergleich zum Hantro Codec erzeugte der Smoke Codec jedoch eine etwas geringere Systemlast Allerdings war die Bildqualit t beim Hantro Codec eindeutig besser da beim Smoke Codec kein Motiv im Bild zu erkennen war Da die Auslastung des Ger tes keinen der beiden Codecs klar herausheben konnte und die Wiedergabe des Bildes so gravierende Unterschiede aufwies findet der Hantro4200 Codec Verwendung in UbiMuC Codec VIRT RES SHR
59. dem Weg liegenden Peers in einer Liste innerhalb des GetRoute Paketes gespeichert werden Sobald das GetRoute Paket beim Empf nger angekommen ist wandelt der Empf nger das empfangene GetRoute Paket in ein GetRouteReply Paket um und schickt es entlang der gespeicherten Route an den urspr nglichen Sender zur ck Somit best tigt der Empf nger den Verbindungsaufbau zum Sender L nge Typ Ziel Quelle Hop Anzahl SourceRoute 2 Byte 2 Byte 64 Byte 64 Byte 4 Byte Hop Anzahl 64 Byte Header Payload Abbildung 4 3 Aufbau von GetRoute und GetRouteReply Im Folgenden werden die beiden Nachrichtenformate GetRoute und GetRouteReply vor gestellt Der Aufbau ist f r beide gleich und wird in Abbildung 4 3 dargestellt Das Format besteht immer aus zwei Teilen dem Header und der Nutzlast Payload Das erste Feld L nge gibt die Gesamtl nge der Nachricht an Im nachfolgendem Feld wird der Typ der Nachricht spezifiziert Innerhalb dieses Feldes wird zwischen einer GetRoute und GetRouteReply Nachricht unterschieden In den n chsten beiden Feldern befinden sich die jeweiligen Adressen der Peers die miteinander kommunizieren m chten Das Feld Hop Anzahl gibt die Anzahl an Hops an die zwischen dem Sender und Empf nger liegen Das letzte Feld welches dem Payload entspricht speichert die Adressen der Hops die auf der Route vom Sender zum Empf nger liegen Der UbiMuC
60. dener Softwaresubsysteme unter einer ein heitlichen Oberfl che Die Benutzer von UbiMuC sollen mit Hilfe der Software in die Lage versetzt werden spontan untereinander Nachrichten und Informationen austauschen zu k n nen ohne dabei auf eine statische Netzwerkinfrastruktur angewiesen zu sein Im Vordergrund des Unterfangens steht also die Dynamik des Netzwerkes und die Mobilit t der Benutzer wes halb in erster Linie Ad Hoc Netzwerke in Frage kommen Statische Netze mit vorhandenen Access Points sind nachrangig zu betrachten Inhaltlich sollen dabei die besonders wichtigen Funktionalit ten zur Kommunikation gew hrleistet sein Der textuelle Datenaustausch soll durch ein Chatmodul erm glicht werden eine AV Umgebung soll die integrierte Kamera und das Mikrofon ansprechen k nnen und Videokonferenzen herstellen k nnen Die Teilnehmer sollen sich individuell in das UbiMuC Netz mit frei w hlbaren Pseudonymen anmelden um so mit anderen Teilnehmern in der Umgebung in Verbindung treten zu k nnen Dabei sind 1 Einleitung insbesondere die Videokonferenz zwischen Benutzern und der Austausch von textuellen Nach richten von Bedeutung da diese Funktionen bislang durch Skype AIM ICQ oder andere Instant Messenger Programme nur ber statische Server m glich sind und zwingend Zugang zum Internet erfordern Auf Basis von Ad Hoc Netzwerken sollen genau diese zentralen Funk tionen von UbiMuC bereitgestellt werden Die ausgew hlte Plattform A
61. des zuerst favorisierten MPlayers zu verwenden 63 4 Design 4 5 1 2 Genutzte Codecs Zur effektiven Ubertragung von Multimediadaten ist eine Kompression dieser Daten n tig Doch gerade bei eingebetteten Systemen stellt dies ein Problem dar Die Rechenleistung ist sehr begrenzt so dass nur ressourcensparende Codecs verwendet werden sollten Speziell bei Streaminganwendungen sollte die Kompression m glichst zeiteffizient stattfinden Somit muss ten Codecs f r die Bild bzw Ton bertragung in UbiMuC gew hlt werden Hierbei wurden die mitgelieferten Codecs untersucht und getestet Testumgebung Zun chst wurde getestet ob mittels GStreamer eine performante Multimedia Pipeline erzeugt werden kann Dazu wurde gst launch ein mitgeliefertes Kommandozeilen Tool verwendet Bei den Tests wurden zwei N810 eingesetzt Netzwerk Pipeline H H H H H H H H H H H H L Abbildung 4 12 Aufbau der Testumgebung Dabei wurde auf dem einen Ger t eine Sendepipeline per gst launch realisiert die auf einen lo kalen UDP Port leitete Als Quellen dienten das Mikrofon und die ebenfalls im Ger t verbaute Webcam Auf dem Empfangsger t arbeitete gst launch als Receiver Pipeline Diese Pipeline musste so konstruiert werden dass eine Wiedergabe des gesendeten Streams m glich war Die Wieder gabe selbst erfolgte in diesem Test ber zugeh rige Multimedia Senken Videodaten wurden ber die xvimagesink wiedergegeben Diese Senk
62. die Einbindung oder Deaktivierung einzelner Funktionalit ten beg nstigt Die besonders wichtigen Module werden dabei nachfolgend beschrieben ebenso wie auf die Gesamtstruktur von GNUnet eingegangen wird 18 2 2 GNUnet Prozessstruktur GNUnet selbst besteht aus einem lokalen Server und einem Client Prozess welche beide ge trennt voneinander arbeiten Der GNUnet Server gnunetd auch als Core bezeichnet ist f r die Verwaltung s mtlicher Peer to Peer Verbindungen und Datenaustausche mit anderen GNUnet Teilnehmern zust ndig Er kapselt dar ber hinaus die gesamte Netzwerkebene inklu sive der Verschl sselung von Daten der Adressverwaltung und dem Bandbreitenmanagement Die Verbindung zwischen den beiden Prozessen wird ber lokale Nachrichten hergestellt wobei ein vorhandener GN Unet Client die eigentliche Schnittstelle zwischen Benutzer und GN Unet Netzwerk bzw anderen Teilnehmern bildet Die durchgef hrten Client Aktionen des Benutzers werden zur Verarbeitung und Durchf hrung an den Kern weitergeleitet N heres zur allgemei nen Kommunikation zwischen UbiMuC und GNUnet findet sich in Abschnitt Das Filesharing Modul Da GNUnet im Wesentlichen als reines Filesharing Programm entworfen ist realisiert es die Kommunikation zwischen den Teilnehmern haupts chlich auf der Basis des PULL Prinzips Stellt ein Teilnehmer also eine Such oder Downloadanfrage mit Hilfe des Filesharing Moduls von GNUnet so wird die Suchanfrage
63. e Handhabung der Ger te zu vereinfachen wurde auf den Ger ten ein SSH Server instal liert und an einem Desktoprechner mittels Putty SSH Verbindungen zu den einzelnen Ger ten ge ffnet Dies wird in Abbildung 4 9 gezeigt wo f r drei N810 auf einem Desktoprechner pro N810 jeweils zwei SSH Verbindungen ge ffnet wurden Eine Verbindung war f r den Bench mark und die andere um GNUnet zu starten Dadurch hatte man eine viel bessere bersicht und konnte auch einfach mit Copy amp Paste die langen Peeridentitys von einer Konsole in die n chste kopieren Testergebnisse Im Verlauf der Projektgruppe wurden drei GN Unet Versionen getestet die jeweils den aktu ellen Entwicklungsstand wiederspiegelten und eine fortschreitende Entwicklung des Projektes darstellen In Tabelle wurde das Benchmark Programm mit zwei Ger ten unter GNUnet getestet also ohne einen Hop zwischen den Ger ten Hier wurden Geschwindigkeiten zwischen 50 und 67 KB s erzielt 5l 4 Design Dauer min Gesendete Daten Bytes KB s 03 16 13516800 67 35 19 46 60518400 49 38 05 24 19169280 57 78 03 16 10137600 90 51 10 15 30904320 49 07 Tabelle 4 1 Test mit GNUnet Revision 804 zwei Ger te Beim zweiten Test wurde die GNUnet Revision 804 mit drei Ger ten getestet Die Anmerkung iptables deutet hier darauf hin dass die Reichweite der Ger te k nstlich durch einen ipta bles Eintrag eingeschr nkt wurde Die beiden Ger
64. e stellt die Daten auf dem Display in einem separaten neu erzeugten Fenster dar Audiodaten wurden in die Audiosink weitergeleitet welche den jeweils getesteten Codec DSP gest tzt verarbeiten kann Eine weitere Instanz simulierte das zwischenliegende Netzwerk indem sie die Datenpakete vom durch die Sendepipeline bedienten Port des sendenden Ger tes auf einen Port des Emp fangsger tes weiterleitete Diese Instanz simulierte somit die UbiMuC Transportschicht wie sie im Abschnitt 4 2 beschrieben wird Im Folgenden werden die berpr ften Codecs sowie die Ergebnisse der durchgef hrten Tests vorgestellt Als Vergleichskriterien dienen die von ihnen erzeugte Systemlast und die Qualit t der wiedergegebenen Streams Video Codecs Es wurden zwei Video Codecs f r den Einsatz in UbiMuC getestet Der Smoke Codec ist ein JPEG basierender Video Codec Er steht unter GPL und ist Teil des Flumotion Projektes Die Pipelines dieses Codecs wurden f r die Tests wie folgt siehe Abbildung 4 13 umgesetzt 64 4 5 Multimedia Sende Pipeline gst launch v4l2src video x raw yuv width 176 height 144 framerate fraction 8 1 f mpegcolorspace smokeenc keyframe 8 qmax 40 udpsink host 192 168 178 27 port 5000 Empfangs Pipeline gst launch udpsrc port 5001 smokedec xvimagesink Abbildung 4 13 Sende und Empfangspipeline mit Smoke Codecs Der zweite Enkoder ist der propriet re Hantro4200 I7 von On2 Technologies Inc Es han
65. edlichen Aufgaben Den Peers auf der einen Seite und dem Server auf der anderen Seite Abbildung 2 1 Aufbau eines serverbasierten Peer to Peer Netzes Serverbasierende Peer to Peer Netze sind relativ leicht zu implementieren Sie sind zudem leicht wartbar und einfach zu administrieren Allerdings haben sie eine eklatante Schwach stelle F llt der Server aus bricht das gesamte Netz zusammen Dies macht das Netz extrem angreifbar aber auch eine gro e Anzahl an Anfragen k nnen den Server stark belasten Des 14 2 1 Peer to Peer Konzepte Weiteren sind die Speicherressourcen des Servers begrenzt Da auf diesem sowohl Typ und Beschreibung der der durch die Peers bereitgestellten Ressourcen als auch deren Adresse ge speichert werden m ssen ist die Gr e des Netzes durch diesen beschr nkt Ein ebenfalls nicht zu untersch tzender Nachteil liegt in der permanent ben tigten Erreichbarkeit und dem damit verbundenen Energiebedarf Reine Peer to Peer Netzwerke In reinen Peer to Peer Netzwerken wird der Grundgedanke des Peer to Peer strikt verfolgt Alle Peers im Netzwerk haben die gleichen Aufgaben Pflichten und Rechte Diese Topologie besteht demnach ausschlie lich aus homogenen Knoten Peers k nnen Anfragen stellen und Ressourcen Dienste oder hnliches zur Verf gung stellen Stellt ein nicht unmittelbar be nachbarter Peer eine Ressource bereit so werden Anfragen ber die anderen Peers zu diesem weitergeleitet Abbildu
66. eginnt mit einem kurzen Header der jeweils 16 Bit f r Nutz datenl nge und typ enth lt Anhand des Datentyps wird entschieden welche Handlerfunktion aufgerufen werden soll Unsere Aufgabe war es also geeignete Handler sowohl innerhalb von gnunetd als auch UbiMuC zu schreiben Dazu haben wir bis dahin noch unbenutzte Typnum mern definiert die beim Initialisieren unserer GNUnet Plugins zusammen mit den entspre chenden Handlerfunktionen bei gnunetd registriert werden Beim Eintreffen eines Paketes mit passender Typnummer wird von nun an die Handlerfunktion aufgerufen die das vollst ndige Paket inkl Header als Parameter bergeben bekommt Auf der Seite der WIR Schicht wurden eigenst ndige Threads angelegt die immer dann aufgeweckt werden wenn Pakete vom GNUnet Daemon eintreffen Anschlie end findet auch dort eine berpr fung der Typnummer statt Dabei wird auch entschieden wie das Paket weiter zu behandeln ist Auf diesen Vorgang wird in Abschnitt 4 2 2 2 genauer eingegangen Mit diesem Vorgehen k nnen allerdings nur reine Bytearrays verarbeiten werden Um auch komplexere Datenstrukturen handhaben zu k nnen war es notwendig Marshalling Methoden auch Serialisierer genannt zu entwerfen die ganze Objekte in einen Bytestrom umwandeln k nnen so dass sie sich sp ter wieder vollst ndig rekonstruiert lassen Dabei gilt es auch zu be achten dass C Objekte der WIR Schicht die auch im GN Unet Plugin genutzt werden eine passende
67. ehen und anschlie end versendet 4 2 2 2 Paketdienst Schnittstelle Wie man in den vorherigen Abschnitten zur Transportschicht bereits erkannt haben sollte ist es alles andere als trivial Daten mit GNUnet zu bertragen Um diese Komplexit t nicht noch in die Anwendungsschicht zu bringen ben tigen wir eine klar definierte Schnittstelle die s mtliche Elemente und Strukturen von GNUnet sicher kapselt Dies ist die Aufgabe der Paketdienst Schnittstelle Die Schnittstellenklassen sind modular aufgebaut wobei hier alle Module auf der Klasse PacketService aufbauen die eine abstrakte Schnittstelle zum Empfangen und zum Senden von Datencontainern darstellt Eine umfassende Implementierung des PacketService auf der Basis von GNUnet ist die Klasse NetworkLayer Dort werden ausgehende Datencontainer wie sie in Abschnitt 4 1 beschrieben sind serialisiert und an gnunetd weitergereicht Parallel dazu wartet ein spezieller Lese T hread auf eintreffende Datencontainer die nach dem Deserialisieren in einem Empfangspuffer zwischengespeichert werden und dort auf Abholung warten Da f r UbiMuC verschiedenste Daten bertragen werden m ssen mussten wir auf der Basis des PacketService und des NetworkLayers einen Multiplexer entwickeln der eingehende Daten container in verschiedene Eingangswarteschlangen vorsortiert Die Klasse Splitter bernimmt diesen Part und wertet dazu das Typfeld der Datacontainer Objekte zur Unterscheidung der 47 4 Design
68. einer Pfadliste durch das Netzwerk f r sp tere Verwendungszwecke gespeichert und vorgehalten Abschnitt widmet sich im Detail dem Entwurfskonzept der Routingstruktur Die wesentliche Aufgabe des Paketdienstes liegt also in der Bereitstellung einer Sende und Empfangsm glichkeit von Nachrichten f r UbiMuC Module Dabei hat der Paketdienst selbst st ndig f r die Verarbeitung der Daten und den Routenaufbau zu sorgen damit die darauf aufbauenden Module sich nicht mit besagten Details besch ftigen m ssen und die benutz ten Datenstrukturen gut gekapselt werden Details und Struktur des Paketdienstes sind im Abschnitten 4 2 2 verzeichnet ebenso wie die Routing Konzepte und Vorgehensweisen in den Abschnitten und erl utert sind 4 2 1 Konzepte und Spezifikationen Wie schon in vorherigen Kapiteln erw hnt basiert unser Projekt auf dem GN Unet Framework Dieses Framework gibt uns jedoch nicht die M glichkeit selbst ndig Pakete ins Netzwerk zu senden da es nach dem PULL Prinzip arbeitet Um jedoch unsere Ziele zu erreichen ist ein Mechanismus notwendig der uns die M glichkeit gibt einzelne Peers im Netzwerk zu adressieren F r die L sung dieses Problems wurde ein Konzept entwickelt welches in diesem Abschnitt vorgestellt wird Im Folgenden ein einfaches Beispiel Szenario Ein Peer A m chte eine Nachricht an Peer B schi cken Welche Informationen werden ben tigt um dieses Problem l sen zu k nnen Zun chst wird ein eigenes Routin
69. eis Referenzen auf Internetseiten entsprechen wenn nicht anders angegeben dem Stand vom 08 M rz 2009 98 Abbildungsverzeichnis 1 1 UbiMuC Anwendungsf lle 2222222 oo o a 8 1 2 Anwendungsfall der Audio Video Konferenz 2 2 2 2202 8 2 1 Aufbau eines serverbasierten Peer to Peer Netzes 2 2 2 2 2 2 m mn nn 14 2 2 Aufbau eines reinen P2P Netzesl nn nn 15 2 3 Bekanntmachen beitretender Peers unter Verwendung des Ping Pong Protokolls 16 2 4 Aufbau eines hybriden P2P Netzes e 17 2 5 Schema der UbiMuC Strukturl o 24 26 Ein Bild der finalen GUI ooe 222 CE Eon nn 25 2 7 Die endg ltige Roadmapl e 27 3 1 Schichtenmodell GNUnetl e 31 IE 32 4 1 Datacomtalmen 38 daa dida aaa a E 39 4 3 Aufbau von GetRoute und GetRouteReply o 41 4 4 Aufbau des UbiMuC DataBlock 2 22 22 2 En o e 42 48 48 50 50 A E eer A AE Zerf i 51 A ee Ee 56 60 64 j y 65 posa 65 4 15 Sende und Empfangspipeline mit CG 66 Er ers 68 e 69 4 18 Ablauf beim Aufbau einer AV Konferenz Schritt 1 70 N 4 19 Ablauf beim Aufbau einer AV Konferenz Schritt 2 71 4 20 Ablauf beim Aufbau einer AV Konferenz Schritt 3 71 N 4 21 Ablauf beim Aufbau einer AV Konferenz Schritt 4 N 4 22 Ablauf beim Aufbau einer AV Konferenz Schritt 5
70. en Auf der anderen Seite m ssen dort ebenfalls die Antworten von GN Unet interpretiert und unter Umst nden aufbereitet werden Weiterhin ist in der WIR Schicht unsere eigene Programm Logik untergebracht Es werden von dort aus Nutzer und Kontaktdaten zu anderen Peers verwaltet sowie unsere Paketdienst verwaltung realisiert Die von der Schicht bereitgestellten Informationen werden schlie lich von der GUI lediglich dargestellt w hrend die eigentliche Verarbeitungsintelligenz innerhalb der Adapterklassen liegt Auf diese Weise sollte ein Ersetzen der GUI in der Zukunft deutlich vereinfacht werden da lediglich die Kommandoweiterleitung und Darstellung der Ergebnisse angepasst werden m ssen 23 2 Grundlagen Interaktion mit der WIR Schicht Neben der oben genannten Schnittstellen Funktion der WIR Schicht die einzelne Komponen ten wie GUI GStreamer und GNUnet verbindet hat die WIR Schicht insbesondere noch die Aufgabe daf r Sorge zu tragen dass die aufgenommenen Informationen von Webcam und Mikrofon passend kodiert und fiir GNUnet verpackt werden Nutzer 1 Nutzer 2 Interaktion Interaktion aa dekodierte Daten eam Webcam Mikro GUI Steuerung Rohdaten Steuerung GC nn r WIR Schicht GStreamer WIR Schicht kodierte kodieren kodierte Daten Daten Steuerung Steuerung i amp Daten amp Daten Dat tai 4 atencontainer gei GNUnet Abbildung 2 5 Schema der UbiMuC Struktu
71. en Wurde das Chat Tab zwischenzeitlich ge schlossen oder existierte noch nicht sorgt die GUI automatisch f r die Erzeugung und Dar stellung des Nachrichteninhalts durch ein neues Tab Alle Chat Tabs aus der GUI werden in Form von einer gesonderten Mapping Struktur den UbiMuC Adressen zugeordnet so dass die eintreffenden Nachrichten eindeutig den offenen Chat Tabs zugeordnet werden k nnen Das manuelle Schlie en eines Tabs sorgt abschlie end f r die Zerst rung des lokalen Chat Objekts sowie die Entfernung des zum Tab korrespon dierenden Eintrags innerhalb der Mapping Struktur Das lokale Schlie en des Tabs hat dabei keine Auswirkungen auf die Objekte und Strukturen des entfernten Chat Partners Abgleich zu den Anforderungen Die einleitend erw hnten Anforderungen an das Chat Modul sind erf llt worden Das Mo dul gew hrleistet die komplette Kapselung von Sende und Empfangsdetails und stellt den UbiMuC Benutzern eine einfach zu verwendende Schnittstelle zum Austausch von Textnach richten bereit Vor der Erstellung einer Chat Sitzung wird sichergestellt dass der Zielteilneh mer erreichbar ist damit eine Kommunikation berhaupt m glich ist Beim Empfang von Nachrichten wird gew hrleistet dass diese den korrespondierenden GUI Tabs zugeordnet werden damit es nicht zu f lschlichen Anzeigen kommt Aufgrund der sehr komfortablen Schnittstelle des Paketdienstes ist es grunds tzlich kein Problem auch andere nicht Chat Nachrichten
72. en der DHT zu vollst ndigen Benutzerprofilen erweitert Dazu werden den UbiMuC IDs die separat verwalteten Zusatzdaten der Nutzer und ein Online Status Flag zugeordnet Regelm ige berpr fungen ob alle Nutzer noch in der DHT gelistet sind stellen sicher dass dieser Status aktuell gehalten wird Zus tzlich werden die Daten f r die Abspeicherung in der Config Datei aufbereitet Auf Strukturen dieser Ebene greifen die GUI und die anderen Module des Programms zu wenn Nutzerdaten ben tigt werden Daher werden alle Funktionen bereitgestellt die zum Bearbeiten und Speichern der Buddyliste in den anderen Modulen ben tigt werden Buddyliste gt Nico GNUnet Abbildung 4 10 Schema der Abstraktionsebenen In Abbildung wird das Zusammenspiel dieser drei Ebenen nochmal schematisch darge stellt Der rechte Teil stellt die Eintr ge des DHT Moduls in GNUnet dar Die roten Smileys repr sentieren dabei die mit dem Typ UbiMuC versehenen Eintr ge also alle im Netz geliste ten UbiMuC Nutzer Auf der rechten Seite sieht man unten die DHT Schnittstelle in UbiMuC In dieser werden nur noch die DHT Eintr ge mit dem Typ UbiMuC verwaltet Dar ber ist die daraus generierte Buddyliste abgebildet in der wiederum nur noch die in der individuellen Nutzerverwaltung angelegten bekannten Nutzer erscheinen Buddylisten Caching Die Abstraktion der DHT Information zu einer persistenten Liste bekannter Nutzer macht die Verwaltun
73. en kann Jeder Endknoten hat eine Verbindung zu einem Superknoten Dieser fungiert als eine Art Server f r diesen Endknoten 16 2 1 Peer to Peer Konzepte Abbildung 2 4 Aufbau eines hybriden P2P Netzes Ein Vorteil eines hybriden Peer to Peer Netzwerks ist die verbesserte Skalierbarkeit im Ver gleich zur Skalierung des serverbasierten Peer to Peer Netzwerks Durch die multiplen Super knoten kann das Netz zwar weiterhin von au en angegriffen jedoch nicht so leicht komplett zerst rt werden Entf llt ein Superknoten so bricht nicht das gesamte Netz zusammen Zu dem sind sie relativ leicht zu realisieren Wie bei einem serverbasierten Peer to Peer Netzwerk k nnen an den Superpeers auch Engp sse entstehen Weiterhin kann ein Superpeer durch die Vergabe von Priorit ten auch Peers bei der Bearbeitung von Suchergebnissen blockieren Auch in hybriden Systemen m ssen mehrere Superknoten permanent erreichbar sein was wiederum einen nicht zu vernachl ssigenden Energieverbrauch mit sich bringt Skalieren von Peer to Peer Netzwerken Um Peer to Peer Netzwerke zu skalieren m ssen verschiedene Herausforderungen gel st wer den Informationen m ssen ausgewogen ber das Netzwerk verteilt werden Au erdem muss verhindert werden dass Peers veraltete Daten zur Verf gung stellen Verl sst ein Peer das Netzwerk m ssen die von ihm verwalteten Daten von anderen Peers zur Verf gung gestellt werden Um diese Informationskoh renz und Fehl
74. en wir einen eigenen Typ namens UbiMuC und versehen alle unsere Eintr ge mit diesem Typ Damit haben wir die M glichkeit auf einfache Weise auf den f r uns relevanten Teil der DHT Eintr ge zuzugrei fen DHT Schnittstelle Diese Ebene stellt die Abbildung der DHT in WIR Datenstrukturen dar Daher kann man auch von einem lokalen Abbild der DHT in Listenform sprechen Die erw hnten Daten Tripel werden hier zusammengestellt und f r die bergabe an die DHT formatiert Diese Tripel umfassen den Benutzernamen eine in UbiMuC eindeutige Hash ID und die dem Nutzer aktuell zugeordnete GN Unet ID F r die dar ber liegende Schicht werden Funktionen angeboten die zum Arbeiten mit der DHT verwendet werden k nnen Dazu z hlen unter anderem das Auffrischen der lokalen DH T Informationen das Einf gen neuer Daten und das Abfragen der aktuell lokal gespeicherten Inhalte Ein explizites L schen der Daten ist nicht n tig da die DHT diese selbstst ndig Timeout basiert entfernt wenn diese nicht regelm ig aufgefrischt werden Buddylisten Ebene Auf dieser Ebene wird unsere persistente Liste von Nutzern realisiert Im Gegensatz zum Ansatz der DHT sollen in die auf dieser Ebene verwaltete Liste nur auf expliziten Wunsch des Nutzers neue Eintr ge aufgenommen und vorhandene gel scht werden Daraus resultiert die pers nliche Buddyliste die in der GUI angezeigt werden kann Au erdem werden die 59 4 Design rudiment ren Nutzerdat
75. erden da GNUnet auf Grund seiner Konzeption bereits ber ausgereifte Sicherheitsmechanismen bei der Daten bertragung verf gt Die Realisierung der gegebenen Anwendungsf lle wird durch das Zusammenspiel von Paketdienst Nutzerverwal tung und GStreamer umgesetzt Die Videokonferenz liefert ein annehmbares Ergebnis und funktioniert auch ber gr ere Entfernungen Das Instant Messaging verh lt sich dank eines geringeren Datenaufkommens etwas robuster Auf eine Filesharing Funktion musste jedoch verzichtet werden da die Implementierung zu sammen mit den restlichen Anforderungen aus Zeitmangel nicht mehr m glich war Die Fertig stellung eines funktionsf higen Paketdienstes und Streamings hatte insgesamt h here Priori t t Schlussendlich wurde die Leistungsaufnahme und der Umfang an Daten in verschiedenen Tests gepr ft Bis auf das Filesharing wurden folglich alle im Projektgruppenantrag gefor derten Ziele erf llt Dies ist bereits in GN Unet enthalten und erh lt deswegen eine geringere Gewichtung im Gegensatz zu den anderen Anforderungen 83 6 Fazit ber die minimalen Anforderungen hinaus wurden jedoch auch mehrere zus tzliche Features in der UbiMuC Software realisiert Eine rudiment re Kommunikationsm glichkeit zwischen den Benutzern war von Anfang an vorgesehen Jedoch wurde dieser Punkt in Form der Nut zerverwaltung inklusive Kontaktliste erweitert Hierdurch ist gerade in einem Netz mit vielen Teilnehmern ein einfacher
76. eren Performanzprobleme auftraten und die wiedergegebenen Streams eine annehmbare Qualit t erreichten wurden diese Codecs f r UbiMuC festgelegt 4 5 1 3 Genutzte Protokolle F r die bertragung der Nutzdaten ist es einfacher auf ein bestehendes Protokoll aufzusetzen als von Grund auf ein Neues zu implementieren Insbesondere macht es Sinn ein Protokoll zu verwenden welches durch das Multimedia Framework direkt unterst tzt wird Hierzu werden gewisse Anforderungen an das Protokoll gestellt So ist es beispielsweise nicht notwendig dass bei AV Streams alle Datenpakete empfangen werden Allerdings ist daf r deren Reihenfolge wichtig W rde auf ein Datenpaket gewartet werden m ssen erh ht sich die Latenz zwischen dem Senden und der Wiedergabe des Da tenstreams Das User Datagram Protocol UDP bietet diese Funktionalit ten und wird auch weitestgehend in Streaminganwendungen f r hnliche Zwecke eingesetzt Zudem unterst tzt das in UbiMuC verwendete Multimedia Framework GStreamer dieses Protokoll Des Weiteren ist sicherzustellen dass die empfangenen Pakete dekodierbar sind Dies gew hr leistet in UbiMuC das Realtime Transport Protocol RTP Sowohl f r den verwendeten Video Codec Hantro H 263 als auch f r den verwendeten Audio Codec G 729 liefert das Framework GStreamer direkt geeignete RTP Payloader die Nutzdaten in Pakete entsprechender Gr e packen Diese Pakete werden auf der Empfangsseite problemlos identifiziert und durc
77. erken nicht auftreten Zum einen ist bei den beteiligten Ger te nicht immer Wissen ber die Netzwerktopologie vorhanden Die Routing Entscheidungen sind also gegebenenfalls ohne dieses Wissen zu treffen Dar ber hinaus muss jedes einzelne Ger t eine eigene Routing Tabelle verwalten da es keine bergeordnete Instanz gibt die dieses bernimmt Durch die Mobilit t der einzelnen Netz teilnehmer muss st ndig mit einer Topologie nderung gerechnet werden Das hei t dass die 21 2 Grundlagen in den Routing Tabellen vorhandenen Daten keine besonders lange G ltigkeitsdauer haben sollten Schlie lich sollte das Routing trotz allem m glichst effizient gestaltet werden damit einerseits die durch das Routing entstehenden Latenzzeiten m glichst gering bleiben und da mit andererseits sowohl Prozessor als auch Energieversorgung nicht berm ig beansprucht werden Bei den m glichen Routingkonzepten wird grunds tzlich zwischen zwei Ans tzen unterschie den Zum einen existieren proaktive Verfahren die schon vor einer eventuellen Daten bertra gung die Netztopologie analysieren und Routing Pfade ausarbeiten Beim Versand von Nutz daten muss damit nicht auf den Aufbau einer Route gewartet werden Allerdings besteht so beim initialen Aufbau des Netzes ein erh hter Aufwand und es kann passieren dass Routen gebildet werden die mangels Nachfrage nicht benutzt werden Bei Netzen mit mobilen Teilnehmern kann es zus tzlich dazu kommen
78. ertoleranz zu gew hrleisten gibt es verschie dene Datenstrukturen Diese sind in der folgenden Liste aufgef hrt e Distributed Hash Table DHT e Content Addressable Network CAN e CHORD e Koorde e Tapestry e Pastry e Viceroy e Distance Halving 17 2 Grundlagen Relevanz f r UbiMuC Au er Frage steht dass Peer to Peer Netzwerke die Grundlage f r Ub MuC bilden Da das Projekt auf mobilen Ger ten realisiert werden soll und somit keine zentralen Server oder Superpeers permanent zur Verf gung stehen wird das Netz als reines Peer to Peer Netzwerk realisiert Um Daten in UbiMuC zu verwalten wird eine Distributed Hash Table verwendet Diese wird sp ter genauer beschrieben siehe Abschnitt 3 1 3 1 2 2 GNUnet Die UbiMuC Anwendung setzt als Peer to Peer Framework auf GN Unet welches ein hochgra dig anonymes zensurresistentes und dezentrales Filesharing Netzwerk bereitstellt vel 7 GNUnet stellt seinen Anwendern dabei vorrangig M glichkeiten zum Download und zur Su che von im Netzwerk ver ffentlichten Inhalten bereit Das GN Unet Netzwerk besteht aus einer Vielzahl einzelner Teilnehmer den sogenannten Peers Jeder Peer kann zu jeder Zeit dem Netz werk beitreten Daten ver ffentlichen und herunterladen oder auch das Netzwerk verlassen Besonders zu erw hnen ist an dieser Stelle auch dass GNUnet durch den Einsatz von Ver schl sselungsmethoden symmetrisch und asymmetrisch beziehungsweise Sicherhei
79. ervice State handelt es sich um eine kleine Datenbank welche den internen Zustand von GNUnet protokolliert Der letzte Service Boostrap ist f r den Download von HELLO Nachrichten mittels HTTP zust ndig Applikationen Eine Applikation in GN Unet ist ein Dienst die eine Funktionalit t dem Benutzer bereitstellt Dazu baut sie zuerst eine Verbindung zum gnunetd auf und verbindet sich danach mit der GNUnet Core Weiterhin enth lt sie auch eine Eingabem glichkeit damit der Benutzer auf ihre Funktionalit t zugreifen kann Diese Funktionalit t wird dann durch die Services unter st tzt die aus der GNUnet Core angefordert werden k nnen Die Abh ngigkeiten zwischen den Applikationen und den Services sind in der Abbildung D Zou sehen Applikationen IN a Ian rs rs rr Services Abbildung 3 2 Abh ngigkeiten zwischen Applikationen und Services 32 3 1 GNUnet Konzepte Bei der ersten Applikation Advertising handelt es sich um einen Cron Job Dieser stellt durch den Austausch von HELLO Nachrichten sicher dass sich die Knoten gegenseitig kennen und somit ein Netzwerk bilden Durch die zweite Applikation Getoptions bekommt der Client die M glichkeit den Wert einer GN Unet Option erfragen zu k nnen Die n chste Applikation Traffic verwaltet die Menge des entstehenden P2P Traffics in einem lokalen GN Unet Knoten Bei Datastore handelt es sich um die Verwaltung von Inhalten Dabei muss entschieden werden welcher Inhalt un
80. erzielt Bis zu dieser Version war die Verbindung noch nicht stabil so dass die Tests nicht ber l ngere Zeit durchgef hrt werden konnten 52 4 3 Nutzerverwaltung Dauer min Gesendete Daten Bytes KB s Anmerkungen 02 59 19353600 105 59 loud 02 36 16465920 103 08 loud 02 34 15421440 97 79 loud 05 02 31764480 102 72 loud 24 49 138117120 90 98 loud Tabelle 4 4 Test mit GNUnet Revision 1187 drei Ger te Beim letzten Test wurde die GN Unet Revision 1187 mit drei Ger ten getestet In dieser Ver sion wurde ein Bugfixing am Paketdienst vorgenommen und es sollte berpr ft werden ob sich die Performanz ver ndert hat Tabelle 1 4 stellt diese Ergebnisse dar Da die Verbindung in dieser Version viel stabiler geworden ist konnte ein circa 25 min tiger Test durchgef hrt werden um zu schauen wie sich der Durchsatz ber l ngere Zeit verh lt Auswertung Die Tests haben gezeigt dass es bei der Geschwindigkeit zwischen einem Versuchsaufbau mit zwei und einem mit drei Ger ten keinen gro en Unterschied gibt Es l sst sich auch die Entwicklung der GNUnet Versionen ablesen W hrend die Verbindung bei der GN Unet Revision 804 noch ziemlich instabil war und deshalb keine Langzeittests m glich waren haben die nderungen in Revision 1179 eine deutliche Leistungssteigerung gebracht Da sich bei dem realen Test die Geschwindigkeit gegen ber der k nstlichen Testumgebung mit iptables
81. fgerufen sobald eine Kontrollnachricht mit pas sender Signatur empfangen wird und enth lt eine Kopie der Nutzdaten des zugeh rigen Da tenpaketes So lassen sich kurze Steuer Nachrichten austauschen ohne daf r eigene Threads anzulegen Der Austausch der erweiterten Benutzerinformationen der Kontaktliste wurde beispielsweise damit implementiert Hierbei sollte man allerdings beachten dass die Callback Funktionen nicht zu lang werden da der Splitter in dieser Zeit blockiert und keine weiteren Pakete emp fangen kann 4 2 3 Auslastungs und Geschwindigkeitstests von GNUnet Testaufbau In diesen Tests wurde unser Paketdienst in Bezug auf die Geschwindigkeit getestet Dazu wurden mehrere Ger te wie in Abbildung 4 7 vorgestellt aufgebaut Die beiden Ger te A und C k nnen nur das Ger t B erreichen sehen sich aber nicht gegenseitig Das Ger t B steht in der Mitte und hat Verbindung zu beiden Ger ten Auf diese Weise wird sichergestellt dass bei einer Kommunikation zwischen Ger t A und C ein echtes Multihop Routing zustande kommt Diese Tests wurden durchgef hrt um sicherzustellen dass unser Paketdienst eine ausreichende Geschwindigkeit f r die Multimedia bertragung zur Verf gung stellen kann Zus tzlich konnte damit die Zuverl ssigkeit des Paketdienstes berpr ft werden 49 4 Design Abbildung 4 7 Grafische Darstellung des Testaufbaus Abbildung zeigt hier den Testaufbau mit f nf Ger ten Die Ger te
82. g Protokoll in GNUnet gebraucht Dieses verwendet zwei Nachrichten formate GetRoute und GetRouteReply die bei der Aufbau der Route zwischen Peer A und Peer B ben tigt werden Sobald die Verbindung aufgebaut ist k nnen ber den Paketdienst die eigentlichen Nutzdaten versendet werden Die Nutzdaten werden in der vordefinierten Da tenstruktur UbiMuC DataBlock anschlie end von Peer A zu Peer B transportiert In den folgenden Kapiteln wird n her auf den Aufbau und die Funktionsweise der Nachrichtenforma te GetRoute und GetRouteReply siehe Abschnitt 4 2 1 2 sowie auf UbiMuC DataBlock eingegangen 40 4 2 UbiMuC Transportschicht 4 2 1 1 Nachrichtenformate Im Folgenden werden die wichtigsten Nachrichtenformate der Transportschicht zuerst durch ihre Funktionsweise und danach durch ihren Aufbau erl utert Dabei handelt es sich um die Formate GetRoute und GetRouteReply f r den Aufbau einer Route Und das Format UbiMuC DataBlock f r den anschlie enden Transport von Nutzdaten F r jedes Nachrich tenformat wurde innerhalb von GNUnet ein GN Unet Pakettyp definiert und mit einer zuge h rigen Handler Funktion versehen Die GetRoute Nachricht wird vom Sender genau dann gesendet wenn dieser eine Verbindung zu einem anderen Peer herstellen m chte und keine Route zu ihm kennt Per Broadcast wird die GetRoute Nachricht an alle Teilnehmer des UbiMuC Netzes gesendet wobei alle auf
83. g und Nutzung der Nutzerdaten f r unsere anderen Module wie den Chat und das Streaming deutlich komfortabler Ein Gro teil der Nachteile der DHT k nnte auf diesem Wege ausgeglichen werden Jedoch kann sich das nicht deterministische Antwortverhalten der 56 4 3 Nutzerverwaltung DHT noch immer bei den periodisch ausgef hrten DHT R ckfragen zur Aktualisierung des Online Status aller Eintr ge in der Buddyliste negativ bemerkbar machen Unvorhergesehene nderungen in der DHT k nnten sich dadurch direkt in spontanen Wechseln zwischen Online und Oflline Status niederschlagen was gerade bei Versuch eines Verbindungsaufbaus zwischen zwei Peers zu Komplikationen f hren kann Unsere L sung f r dieses Problem ist das Cachen der Eintr ge in unserer Buddyliste Das lokale Abbild der DHT in der WIR Schicht wird nicht nach jeder berpr fung der DHT Inhalte vollst ndig neu erstellt sondern zwischengespeichert und zus tzlich wird mit abgespeichert wie oft der Eintrag eines Nutzers nun schon nicht mehr vorgefunden wurde Erst nachdem ein solcher Nutzer nach mehrfachen Anfragen nicht mehr in der DHT vor gefunden wurde wird er aus der Liste entfernt Dies f hrt auf der dar berliegenden Ebene wiederum dazu dass der Status in der Buddyliste auf Offline gesetzt wird Auf diese Wei se ist ein eventuelles Fehlerverhalten der DHT ausgleichbar und es k nnen sehr rasche und ungewollte Wechsel des Online Status abgefangen werden 4 3 1
84. gen abgelaufen sein und entsprechend der Wert von current connection nicht dem Hashwert von Client B entsprechen so wird hier ein Dialog Fenster angezeigt um zu best tigen dass eine Verbindung aufgebaut werden soll Bei einer Best tigung wird analog zu Schritt 2 fortgefahren Client A Oienp Jm Beginne Konferenz i Request Paket JN Vollst ndige Konferenz Behandlung H WENN current_connection i i DANN Dialog Fenster WENN current_connection Hash A H D UND connection_established FALSE i DANN i Setze i connection_established TRUE Baue Request Paket Empf nger H ah y 1 Sender H ach Flags 3 Request Paket i Y Konferenz besteht H Abbildung 4 21 Ablauf beim Aufbau einer AV Konferenz Schritt 4 Schritt 4 Bei Eingang des best tigenden Request Paketes von Client B wird auch hier die Variable connection established auf TRUE gesetzt Abbildung veranschaulicht graphisch die Reihenfolge der Pr fungen Ebenfalls werden die Ports f r die Konferenz ge ffnet und Daten von Kamera und Mikrofon verschickt Client A Client B Ty Vollst ndige Konferenz Abbildung 4 22 Ablauf beim Aufbau einer AV Konferenz Schritt 5 Schritt 5 Da der Handler sehr einfach gehalten ist und nur anhand des Zustands der beiden Variablen f r den Handshake arbeitet wird nun ein weiteres Request Paket abgeschickt welches dann allerdings vom Empf nger ve
85. h den ebenfalls mitgelieferten RTP Depayloader entpackt Die Nutzdaten k nnen danach weiterver arbeitet werden 67 4 Design Demnach werden RTP Pakete erzeugt die mittels UDP auf einen gew hlten Port des lokalen Systems gelenkt werden An diesem Port k nnen sie durch einen geeigneten Mechanismus wie beispielsweise Sockets siehe 4 2 2 3 gelesen und zum eigentlichen Empf nger weitergeleitet werden Dieser Mechanismus l sst sich variabel ersetzen beispielsweise durch einen GN Unet Dienst Somit wurde die folgende Pipelinestruktur in UbiMuC realisiert Abbildung 4 16 Sendepipeline RTP Payloader UDP Sink A V Encoder AN Source SIOMI0S AN WIR Schicht GE GNUnet Netzwerk RTP Depayloader A V decoder UDP Source SJOMIOS A W Empfangspipeline Abbildung 4 16 Sende und Empfangs Multimediapipeline in UbiMuC 4 5 1 4 Auf und Abbau einer Konferenz In UbiMuC soll es auch die M glichkeit einer Audio Video Konferenz zwischen verschiedenen Nutzern geben Derartige Konferenzen sind bekannt von Programmen wie zum Beispiel Skype Letztlich handelt es sich dabei um eine Form der Videotelefonie Diese dient in UbiMuC dazu zu zeigen dass es nicht nur m glich ist textuell mit anderen Nutzern zu kommunizieren wie im vorhergehenden Kapitel 1 4 beschrieben sondern dies auch anderweitig erm glicht wird Um eine Konferenz zwischen z
86. hat R ume vorgesehen der Datenaustausch findet ausschlie lich zwischen zwei Personen statt Inhaltlich soll es dabei keine Rolle spielen an welchen Punkten des Netzwerkes sich die beiden Teilnehmer befinden oder wieviele Knoten die Nachricht auf der Route zwischen Quelle und Ziel traversieren muss Die Realisierung des Chat Nachrichtendienstes f r die UbiMuC Anwendung wurde in insge samt zwei Schritten durchgef hrt Zu Anfang wurde ein Konzept f r das Chat Modul erstellt auf dessen Basis sp ter die Implementierung durch Klassen und GUI Methoden folgte Inner halb des Konzepts wurden die Spezifikation und die Rahmenbedingungen erfasst sowie die eigentliche Zielsetzung f r das Chat Modul 4 4 1 Konzepte und Spezifikationen Rahmenbedingungen Um gezielt Nachrichten innerhalb des UbiMuC Netzwerkes austauschen zu k nnen muss eine Differenzierung zwischen den einzelnen UbiMuC Teilnehmern vorgenommen werden k nnen Das Chat Modul ben tigt also eine M glichkeit die im Netzwerk vorhandenen Benutzer von UbiMuC auseinander zu halten um so die Nachrichten gezielt behandeln zu k nnen Die se Identifikation und Unterscheidung zwischen den verschiedenen Benutzern ist durch deren eindeutige Benutzeradressen und die Funktionen der Buddyliste gew hrleistet wie sie in Ab schnitt 4 3Jangesprochen wurde Dort kann ein UbiMuC Benutzer anhand seines Aliasnamens und dessen eindeutigem Hashwert erkannt werden so dass sich zu ihm eine Chat Sitzung aufb
87. hbar ob die anderen Nutzer gerade innerhalb des Netzes ver f gbar sind Letztlich wird f r die aktuell verf gbaren Nutzer die Optionen angeboten eine Konferenz oder Chat Session zu starten Die Nutzerverwaltung stellt dabei alle zur Verwaltung der Informationen ben tigten Daten strukturen bereit und verwaltet diese All diese Elemente sind folglich im WIR Core definiert damit auch ein zentraler Zugriff auf diese Programmteile von allen Modulen sofern n tig m g lich ist Sie stellt ebenfalls die Speicherung der Daten ber das Beenden das Programms hinaus persistent sicher indem alle relevanten Daten automatisch in eine Config Datei geschrieben werden Das korrekte Lesen und Schreiben dieser Datei wird von einem Parser bernommen auf den im Anhang eingegangen wird siehe Anhang 7 1 Die Informationen wann Nutzer das lokale Netz betreten oder verlassen bezieht UbiMuC aus der GNUnet DHT Jedoch m ssen diese Daten zun chst f r unsere Zwecke aufbereitet werden Daher arbeitet die Nutzerverwaltung mit mehreren Abstraktionsebenen die die Kapselung der DHT gegen ber unseren Programmteilen sicherstellt Weiterhin ist durch diese Kapselung sichergestellt dass die verschiedenen UbiMuC und GNUnet Module bei Bedarf unabh ngig von einander gestartet werden k nnen 4 3 1 1 Abstraktionsebenen Wie bereits in Abschnitt detailliert dargestellt wurde hat die GN Unet DHT einige nachteilige Eigenschaften Daher ist sie f r die direkte Verwa
88. he Weise verarbeitet und bertragen werden Jedoch entf llt hierbei die Kodierung und Dekodierung der Daten da der Text auch direkt in unseren Paketen als Nutzdaten verpackt werden kann 24 2 6 Benutzeroberfl che Inhalte der WIR Schicht Die WIR Schicht fasst wie bereits dargestellt alle selbst entwickelten UbiMuC Module zu sammen Die bergeordnete Verwaltung dieser eigenen sowie der eingebunden Komponenten bernimmt dabei der so genannte WIR Core Bereich Allgemein umfasst dieser alle Funktiona lit ten die zum Initialisieren Starten und Beenden unserer anderen Module ben tigt werden Es wird beim Programmstart sichergestellt dass Werte aus einer Konfiguration Datei geladen werden oder wenn keine sinnvollen Daten gefunden werden Standardwerte gesetzt werden so dass UbiMuC grunds tzlich funktionsf hig ist Anschlie end wird sichergestellt dass der GNUnet Dienst gestartet ist Sollte er nicht bereits laufen so wird er nun mit den aus der Konfiguration ermittelten Werten gestartet Sobald GNUnet l uft werden unsere eigenen Dienste gestartet und die Benutzeroberfl che initialisiert Zur Laufzeit des Programms findet im WIR Core auch die Ausnahmebehand lung f r den Fall statt dass GNUnet unerwartet terminiert oder dass andere Fehlerf lle auftreten Beim Beenden werden schrittweise die einzelnen Komponenten wieder freigegeben und der GNUnet Dienst wird beendet falls er von UbiMuC gestartet wurde ber die bisher
89. hergestellt werden dass f r alle Ger te nur ihre direkten Nachbarn inner halb des Netzes sichtbar sind Nur so konnte die Kommunikation ber eine lange Kette von Weiterleitungen sichergestellt werden Die Performanz war bei diesem Test genauso wie die vom vorherigen Test die zus tzlichen Hops hatten hier zu keiner Verschlechterung der Qualit t gef hrt Die Verbindung blieb auch stabil als die Ger te mit gr erer Distanz zueinander aufgebaut wurden Die Ger te wurden in verschiedenen R umen auf einer L nge von ber 20 Metern platziert Auch hier wurde der Chat getestet Alle Ger te konnten problemlos miteinander chatten Kreuztest mit f nf Ger ten Ger te durch Wlan direkt verbunden lt gt Ger te nutzen AV Konferenz Bo a Abbildung 5 1 Aufbau des Kreuztestes mit fiinf Ger ten Bei dem Kreuztest wurden wie im vorherigen Aufbau fiinf Ger te so aufgebaut dass sie nur mit ihrem Vorg nger und Nachfolger kommunizieren k nnen Dadurch ergibt sich eine Kette wie in Abbildung dargestellt Ziel des Aufbaus war es zwei Verbindungen aufzubauen um die Doppelbelastung als Konferenzteilnehmer und als Hop auf den Ger ten zu testen Daf r haben wir das Ger t Nr 2 mit dem Ger t Nr 4 sowie die Ger te Nr 1 und Nr 5 untereinander eine Konferenz aufbauen lassen Dadurch ergab sich bei den Ger ten Nr 2 und 4 eine Doppelbelastung als Konferenzteilnehmer und als Hop und ber das Ger t Nr 3 wurden zwei Konferen
90. ich entwickelten Software abgleicht 1 2 Anwendungsf lle Im Fokus der hier folgenden Anwendungsf lle steht die Realisierung der bereits in der Ein leitung umrissenen Nutzungsm glichkeiten Besitzer eines N810 sollen mithilfe der UbiMuC Anwendung ber ein spontan gebildetes Ad Hoc Netzwerk in die Lage versetzt werden mit anderen UbiMuC Teilnehmern Kommunikationsbeziehungen eingehen zu k nnen Vorab muss nat rlich eine Anmeldung am Netzwerk erfolgen damit berhaupt Informationen ausgetauscht werden k nnen Die erkannten Szenarien werden hier nun grob skizziert und nachfolgend wei teren Vorgehensweisen und L sungskonzepten zugeordnet Um die einzelnen Anwendungsf lle und deren Implikationen aber nicht aus dem Blick zu verlieren werden diese den entwor fenen L sungskonzepten gegen bergestellt die f r die Realisierung der Szenarien zust ndig sind Abbildungll 1 zeigt eine Skizze der zentralen Anwendungsf lle im Kontext der UbiMuC Umgebung Im Vordergrund der Bem hungen standen dabei die Hauptanwendungsf lle Videokonferenz und Chat da diese als Hauptaspekte von UbiMuC von zentraler Bedeutung sind und die eigentlichen Kommunikationsm glichkeiten der Benutzer darstellen Neben diesen zentralen Nutzungsszenarien mussten nat rlich auch die darunterliegenden Konzepte und notwendigen Schnittstellen wie ein Paketdienst und das Ad Hoc Netzwerk ber GNUnet implementiert werden was jedoch keinen echten Anwendungsfall an sich darstellt
91. ine vertikale Scrollbar und die Texte werden automatisch an die vorliegende Fensterbreite innerhalb des N810 Displays angepasst Ein Zeilenumbruch wird automatisch vorgenommen wenn der darzustellende Inhalt eine vor definierte L nge berschreitet Dabei spielt es keine Rolle wie lang der Text effektiv ist da der Text so oft wie n tig umgebrochen wird 4 4 2 Implementierung Um eine Chat Sitzung so allgemein wie m glich zu halten wurde der Konstruktor der Chat Klasse nur mit den zwei Parametern networklayer und wir_ buddy entry versehen Der networklayer stellt dabei die Verbindung zur Netzwerkschicht dem Paketdienst und dem dahinterliegenden GN Unet Client her Der hinter dem networklayer gekapselte Paketdienst sorgt automatisch f r den Aufbau einer Route und f r die Versendung der Datenpakete so dass lediglich dessen send Methode zum Datenaustausch mit anderen UbiMuC Benutzern verwendet werden muss Die Struktur wir_buddy_entry impliziert im weiteren Verlauf die Unterscheidung der ein zelnen Nutzer bei mehreren offenen Chat Sitzungen anhand der dort hinterlegten eindeutigen Adressen auf der Basis von Hashwerten Innerhalb eines Objekts der Klasse wir_ buddy entry basierend auf Abschnitt 4 3 ist unter anderem der vergebene Aliasname des Benutzers ge speichert sowie die interne UbiMuC Adresse und der aktuelle Online Status Format von Chat Nachrichten Um Chat Nachrichten abzusenden wird ein Datencontai
92. ist Bei den einzelnen Peers auf der Route findet keine Speicherung der Pfadliste statt da dies das Routing bzw die Pr fung auf vorhandene Pfade erhebliche verkompliziert h tte An der Quelle erkennt der Peer dass er das Request vor einiger Zeit initiiert hat und entnimmt die enthaltene Source Route Diese Route speichert er nun als Pfadliste ab und merkt sich dass er zum Zielpeer eine Route besitzt Sp tere Routenanfrage des Paketdienstes k nnen dann mit der vorliegenden Source Route beantwortet werden so dass keine neue Route aufgebaut werden muss 43 4 Design Datenaustausch per Paketdienst Nachdem durch die anfangs erw hnten Routinen GetRoute und GetRouteReply gezielt ein Netzwerkpfad zwischen zwei Teilnehmern aufgebaut werden kann k nnen diese mithilfe des Paketdienstes anschlie end Daten austauschen Zur Abgrenzung der Nutz und Routingdaten wurde ein weiterer Nachrichtentyp zur Behand lung von Nutzdaten in GNUnet integriert und mit einer eigenen Callback Funktion verse hen Diese sorgt daf r dass eine Nachricht nach dem Empfang entweder an h here UbiMuC Schichten weitergegeben wird oder aber eine Weiterleitung der Daten zum n chsten Peer auf der Pfadliste stattfindet Die Unterteilung in verschiedene Nachrichtentypen war notwendig da GNUnet die Routing daten mit h herer Priorit t verarbeiten soll Dies ist nur ber eigene Typen m glich die mit statischen Priorit tswerden im Quellcode bevor
93. ittelbar ber der Netzwerkebe ne von GNUnet arbeitenden Methoden direkt mit UbiMuC spezifischen Nutzdaten aufgeru fen Besonders zentral ist dabei die cyphertext_send Funktion welche das gezielte Senden von beliebigen Datenstrukturen an andere Peers erm glicht Daf r wird lediglich eine g ltige GNUnet Adresse als Ziel ben tigt sowie ein GNUnet spezifischer Header vor den eigentlich zu sendenden Nutzdaten Mithilfe des f r den Sendevorgang notwendigen HELLO Pakets des Zielpeers findet eine Schl sselabstimmung statt so dass der Datenaustausch gesichert statt finden kann Auf Empf ngerseite ist es notwendig dass geeignete Handler Funktionen f r die Behandlung der eingehenden Pakete eingebunden werden was im folgenden Unterkapitel separat behandelt wird 3 1 1 GNUnet Handler Alle per GNUnet empfangenen Pakete werden zun chst in einer Queue zwischengespeichert Mittels der Funktion GNUNET CORE p2p_inject message wird jede eingegangene Nach richt innerhalb von GNUnet durch einen speziellen Thread untersucht Jede Nachricht enth lt im Header unter anderem eine wohldefinierte GN Unet Typnummer Falls diese nicht bekannt sein sollte werden die ankommenden Pakete verworfen Je nach Typnummer werden die entsprechenden Handler Funktionen zur Behandlung des Nachrich teninhalts aufgerufen Dabei ist es m glich eine Vielzahl von Nachrichtentypen zu definieren ebenso wie mehrere Handler Funktionen pro Nachrichtentyp registriert werden k
94. iver der die Daten aus dem Netzwerk in Empfang nimmt und sie an den Splitter weiterleitet F r den Aus gangsport wird der Socket vom Typ Sender erstellt der die Daten an sein Ziel im Netzwerk schickt Abbildung 4 6 verdeutlicht hierbei noch einmal den Datenstrom zwischen Splitter und Netzwerk ber die Sockets 48 4 2 UbiMuC Transportschicht 4 2 2 4 Kontroll Protokoll Der Paketdienst ist gut geeignet um gr ere Datenmengen zu bertragen Die Pakete die auf der einen Seite versendet werden kommen beim Empf nger nach und nach an und k nnen zu beinahe beliebigen Zeitpunkten aus dem Empfangspuffer gelesen werden Dieses Prinzip impliziert allerdings dass auf Empfangsseite regelm ig die Ankunft von Pa keten abgefragt wird Meistens ist dazu ein eigener Thread n tig da l ngere Lesevorg nge die Benutzeroberfl che f r die Zeit einfrieren lassen Oft ben tigt man aber keine aufw ndige Datenverarbeitung und es reicht eine kleine Behand lungsroutine aus die prinzipiell auch direkt vom Paketdienst aufgerufen werden kann Hierzu wurde das Kontroll Protokoll entwickelt Umsetzung Das Kontroll Protokoll sieht vor dass man im Splitter sogenannte Callback Funktionen zu einer bestimmten Signatur registrieren kann Die Signatur besteht in unserem Falle aus einer einfachen Zeichenkette und erm glicht es verschiedene Kontrollnachrichten zu unterschei den Die Callback Funktion wird vom Splitter au
95. liche Abstraktionsebenen und passende Schnittstellen zwischen den Schichten erg nzt damit eine vern nftige Kapselung von Datentypen und Informations strukturen sichergestellt ist Innerhalb des vierten Kapitels befinden sich auch Ausf hrungen zu der besonders zentralen UbiMuC Transportschicht welcher ein eigenes Unterkapitel gewid met wird Im f nften Abschnitt befindet sich der abschlie end durchgef hrte Test der fertigen Software Das vorletzte Kapitel des Endberichts widmet sich einem abschlie enden Fazit worin die gestellten Anforderungen mit der entg ltigen UbiMuC Umgebung verglichen werden Ebenso wird ein Ausblick auf weiterf hrende Arbeiten mit UbiMuC gegeben Der Anhang beinhaltet eine Einf hrung in UbiMuC in Form eines Benutzerhandbuchs und Installationshinweisen Au erdem werden dort die wesentlichen GUI Elemente erkl rt und aufgezeigt so dass eine leichte Benutzung von UbiMuC im Anschluss der Lekt re m glich ist 12 2 Grundlagen Die Entwicklung von UbiMuC st tzt sich nicht nur auf selbstentwickelten Code und Konzepte Vielmehr werden vorhandene Komponenten verwendet die im ersten Semester der Projekt gruppe schon erarbeitet wurden Dieses Kapitel greift essentielle Themen des Zwischenberich tes noch einmal kurz auf da sie die Grundlage f r das weitere Vorgehen bildeten Hierbei handelt es sich sowohl um Konzepte als auch um deren Implementierungen Zun chst wird ein grober berblick ber Peer to Peer
96. ls Endger t ist das Nokia N810 ausgew hlt worden welches haupts chlich durch das Linux Subsystem eine gute Entwicklungsbasis aufweist und zus tzlich ber eine Vielzahl von inte grierten Funktion verf gt Besonders erw hnenswert ist die im Ger t enthaltene Webcam die in Kombination mit dem ebenfalls vorhandenen Mikrofon f r den Austausch von audiovisu ellen Mitteilungen sorgen kann Die ausklappbare Daumentastatur erm glicht zus tzlich das schnelle und komfortable Eingeben von Nachrichten Auf technischer Seite ist au erdem die Unterst tzung von drahtlosen Netzwerken ber die WLAN Standards 802 11b und 802 11g gegeben Das N810 verf gt ber eine Bluetooth Schnittstelle die von UbiMuC jedoch nicht verwendet wird Die hohe Konnektivit t in verschiedene Drahtlosnetzwerke erm glicht so die Bildung von Ad Hoc Netzen welche im Weiteren die Basis f r UbiMuC darstellen Ein de taillierter Blick auf das N810 soll hier jedoch nicht vorweggenommen werden sondern wird in Abschnitt gegeben Die Software Subsysteme Aufgrund des eingeschr nkten Zeitrahmens wurde ein bestehendes Peer to Peer Framework als Basis f r die Entwicklung von UbiMuC benutzt Die Entscheidung der Projektgruppe fiel dabei auf das Open Source Projekt GN Unet welches ein dezentrales und hochgradig anonymes Peer to Peer Programm mit Filesharing Funktionen darstellt GNUnet selbst setzt zwar auf ein eher dezentrales Peer to Peer Konzept Daher wurde das ebenfalls unter
97. ltung unserer Nutzerdaten nicht geeignet Insbesondere das nicht deterministische Antwortverhalten bei Anfragen und die Tat sache dass es sich um eine verteilte Struktur handelt die lokal nicht vollst ndig verf gbar ist 54 4 3 Nutzerverwaltung machen eine bergeordnete Verwaltungsebene notwendig Weiterhin wollten wir eine ausrei chende Kapselung unserer Software Module gegen ber den GN Unet Modulen gew hrleisten nicht zuletzt weil unsere Software in C geschrieben ist und GNUnet auf C basiert Die Konsequenz ist dass die Verwaltung der Nutzerdaten sich ber 3 Ebenen erstreckt e dem DHT Modul von GNUnet e der UbiMuC Schnittstelle zur DHT e der Buddyliste der WIR Schicht DHT Ebene Auf der DHT Ebene haben wir keinen Einfluss auf die genaue Verwaltung unserer Daten Mit Hilfe von GNUnet Funktionen werden der DHT Tripel von Nutzdaten bergeben deren Speicherung und Verteilung komplett GN Unet berlassen ist Diese Daten umfassen nur die In formationen die zur Zuordnung der GNUnet Nutzerdaten zu unseren Nutzerdaten n tig sind und werden daher von GNUnet in keiner Weise inhaltlich verarbeitet sondern ausschlie lich von der dar ber liegenden Schicht erstellt und verarbeitet DHT Eintr ge haben wie bereits in Abschnitt 3 1 3 1 unter Struktur beschrieben einen Ty pen nach dem sie aus der DHT angefordert werden k nnen Es k nnen nur alle Eintr ge mit dem gleichen DHT Typ gemeinsam angefragt werden deshalb nutz
98. mer den Verbindungsaufbau und sendet eine Konferenz Anfrage an das Ziel ab Besteht eine Route ber das Netzwerk zum Ziel kann dort die Anfrage akzeptiert oder abgelehnt werden Im Falle der Akzeptanz werden auf bei den Seiten die integrierte Webcam und das Mikrofon des N810 aktiviert um anschlie end die Audio Video Konferenz zu erm glichen N here Informationen zum N810 und dessen Hard ware sind in Abschnitt L 4 zu finden Handelt es sich um einen textuellen Nachrichtenaustausch so kann das Chat Modul verwendet werden Dabei sollen ausnahmslos Texte beliebiger L nge zwischen zwei Teilnehmern ausge tauscht werden Eine Realisierung von Chat R umen oder Mehrteilnehmer Sitzungen ist nicht vorgesehen Zuordnung der Anwendungsf lle zu L sungskonzepten Zur besseren bersicht folgen nun die im einzelnen zu erledigenden Anwendungsf lle sowie deren Zuordnung zu den entwickelten L sungskonzepten in Form von Tabelle Anwendungsfall L sungskonzept Verbindung zum Netzwerk aufnehmen Avahi und GNUnet Personensuche DHT und Kontaktliste Datenweiterleitung Eigene Datenstrukturen und Paketdienst ber GN Unet Audio Video Konferenz Paketdienst GStreamer Chat Paketdienst Tabelle 1 1 Anwendungsf lle und deren L sungskonzepte Die Realisierung eines universell nutzbaren Paketdienstes stellt dabei die Hauptaufgabe dar da GNUnet ber keine solche M glichkeit verf gt GNUnet selbst ist darauf ausgelegt auf Basis von Queries u
99. munikationsteilnehmer ber einen Zwi schenknoten kommunizieren konnten Die AV Konferenz wurde erwartungsgem gestartet und auf beiden Ger ten erschien nach einem kurzem Verbindungsaufbau das Multimediafens ter Beim Video fiel auf dass das Bild wegen der Wahl eines Video Codecs mit recht niedriger Aufl sung ziemlich grobk rnig dargestellt wurde Die Framerate des Videos war ebenfalls sehr gering so dass es zu deutlichen Verz gerungen kam hnlich sah es bei der Sprachqualit t aus bei der die Audio bertragung nicht sonderlich berzeugte Die CPU Auslastung des Ger tes lag w hrend der bertragung im Schnitt bei 70 wobei 30 f r GNUnet und 40 f r die GUI anfielen Zus tzlich wurde getestet die Ton bertragung abzuschalten Dabei wurde eine merkliche Ver besserung der Qualit t bei der Video bertragung bemerkt Umgekehrt hatte eine Abschaltung der Video bertragung eine deutliche Verbesserung der Audioqualit t zur Folge Zus tzlich wurde in dieser Konstellation der Chat berpr ft Alle Ger te konnten problemlos miteinander chatten und die Nachrichten wurden sofort bertragen 77 5 Evaluierung Reihentest mit f nf Ger ten Dieser Test erweiterte unseren bisherigen Aufbau um zwei weitere Ger te zur berpr fung der Skalierbarkeit des Konzepts Ziel war es eine AV Konferenz zwischen zwei Endger ten aufzubauen deren Daten ber drei Hops weitergeleitet werden Wie beim vorherigen Test musste hierbei sic
100. n Dialog Fenster In diesem wird dem Benutzer mitgeteilt dass der Konferenzpartner die Sitzung beendet hat Gleichzeitig wird derselbe Prozess auf der Empf nger Seite angesto en wie zuvor auf der Sender Seite Die Ports werden geschlossen Kamera und Mikrofon in den Ausgangszustand versetzt Das Abbauprotokoll gew hrleistet die an den Verbindungsabbau gestellten Anforde rungen 73 4 Design Zusammenfassung Die beiden vorgestellten Protokolle zum Verbindungsaufbau und abbau sind einfach gehalten Trotzdem garantieren sie aber alle Anforderungen wie sie zuvor an die Konzepte der jeweiligen Protokolle gestellt wurden Mit der Umsetzung dieses Gesamtkonzeptes wird wie zu Anfang dieses Kapitels angesprochen vor allem sichergestellt dass die Kamera und das Mikrofon auf Empf ngerseite nur dann aktiviert werden wenn der Nutzer dies auch wiinscht was der Privatsph re des Anwenders entgegen kommt und damit einen essenziellen Punkt von UbiMuC auch bei Nutzung von Audio Video Konferenzen sichert 4 5 2 Implementierung Die Implementierung der Multimedia Funktionalit ten erfolgte in mehreren Schritten Nach der Evaluierung welche Komponenten auf welche Weise verwendet werden sollten wurden diese modular zum Beispiel in Testprogrammen auf Brauchbarkeit getestet Im Folgenden wurden diese in einem separaten Branch in eine Kopie der bis dato erstellten Benutzeroberfl che integriert Hier ergaben sich einige Probleme die vor der
101. n UbiMuC an GNUnet geschickte eigene Nachrichten verworfen da GNUnet ber keine passende Handlermethode verf gt bzw den Nachrichtentyp gar nicht kennt und entsprechend verwirft Details zu den einzelnen Nachrichtentypen und konkreten Implementierungen werden dabei im Unterabschnitt 4 2 1 1 behandelt Abschlussbetrachtung Nach dieser ersten Betrachtung von GNUnet ist bereits ersichtlich dass einige Module an gepasst und erweitert werden m ssen w hrend auf der anderen Seite einige Module garnicht ben tigt werden Im nachfolgenden Kapitel 3 werden die notwendigen GN Unet Modifikationen erl utert sowie genauer beschrieben Auch wird dort der auf GNUnet aufsetzende Paketdienst in den Grundz gen behandelt 2 3 Ad Hoc Netzwerke Bei Ad Hoc Netzwerken handelt es sich um einen speziellen Typ von Funknetzen Die einzelnen Netzteilnehmer stehen dabei ber ein vermaschtes Netzwerk in Verbindung Es besteht keine feste Struktur insbesondere k nnen die Teilnehmer auch mobil sein Die Gr e des Netzes bestimmt sich ber die Reichweite der Funksignale Durch die fehlenden Strukturen m ssen die Teilnehmer eines Ad Hoc Netzwerkes zus tzlich zur eigenen Netznutzung die Routing Funktionalit ten eines festinstallierten Netzwerkes ber nehmen Die blichen Routing Mechanismen f r festinstallierte Netzwerke greifen bei Ad Hoc Netzwerken in der Regel nicht da einige weitere Bedingungen ber cksichtigt werden m ssen die in statischen Netzw
102. n den beitretenden Peer zur ck und verringert die TTL der Ping Anfrage um eins Zudem tr gt er die Adresse des beitretenden Peers in seiner eigenen Hostliste ein Auf diese Weise wird der beitretende Peer dem bestehenden Netz bekannt gemacht Ist die TTL der Ping Anfrage noch nicht abgelaufen so sendet dieser Peer die Anfrage an ihn bekannte Peers weiter ins Netzwerk Diese bekannten Peers empfangen die Anfragen und verarbeiten diese ebenso Ist eine TTL von Null erreicht senden die betreffenden Peers die Ping Nachricht nicht weiter sondern nur eine Pong Nachricht an den beitretenden Peer Die Adressen der Pong Nachrichten werden in der Hostliste des beitretenden Peers eingetragen So werden Peers des Netzwerks dem beitretenden Peer bekannt gemacht Dud Abbildung 2 3 Bekanntmachen beitretender Peers unter Verwendung des Ping Pong Protokolls Dieses Protokoll wird vornehmlich bei reinen Peer to Peer Netzwerken eingesetzt generell ist aber auch eine Verwendung in hybriden Netzwerken denkbar die im folgenden Abschnitt beschrieben werden Hybride Peer to Peer Netzwerke Bei hybriden Peer to Peer Netzwerken wurde versucht die Vorteile von reinen und serverba sierten Peer to Peer Netzen zu vereinen und die Nachteile zu minimieren Daraus ergaben sich zwei Arten von Peers Endknoten und Superpeers Die Superpeers bilden das innere Netz eines hybriden Peer to Peer Netzwerks welches als reines Peer to Peer Netzwerk aufgefasst werd
103. nalit t zur Daten bertragung gefordert Daher soll die Kommunikation hierbei nicht wie in klassischen Ans tzen ber einen zentralen Server abgewickelt werden sondern in Form von Peer to Peer Netzen Als multimediale Inhalte gelten in unserem Fall insbesondere Instant Messaging IP Video Telefonie und Filesharing Eine der gro en Herausforderungen des Projektes ist es den bei eingebetteten Systemen ver f gbaren geringen Speicher und niedrige Rechenleistungen optimal zu nutzen Insbesondere macht dies eine Anpassung der Peer to Peer Strukturen bez glich Algorithmen und Proto kolle f r mobile Ger te notwendig Bedingt durch die Umsetzung in WLAN Netzen ist es unabdingbar Verschl sselungsverfahren bei Daten bertragung einzusetzen Daher m ssen ef fiziente Verfahren gefunden werden die sich mit den beschr nkten Ressourcen vereinbaren lassen Als Minimalziel ist hierbei gefordert dass UbiMuC sowohl in einem WLAN mit fester In frastruktur als auch in einem Ad Hoc Netz lauff hig ist F r die Sicherheit der bertragenen Daten soll eine effiziente Ver und Entschl sselung im Framework vorhanden sein Aufgabe ist die Entwicklung eines Prototyps der dieses Framework nutzt sowie die Evaluierung unter den folgenden Gesichtspunkten e Geschwindigkeit und Ressourcenverbrauch von Streaming e Kodierung und Dekodieren von Multimedia Inhalten e Ver und Entschl sselung der Daten e Tests der Algorithmen und Protokolle auf Performanz 1 4
104. nd Replies Daten auszutauschen ein selbst ndiges Absenden von Informatio nen in das Netzwerk ohne vorher eingetroffene Anfrage ist aufgrund der Routing Struktur von GNUnet gar nicht vorgesehen Die Module Chat siehe Abschnitt 4 4 und Audio Video Konferenz siehe Abschnitt ben tigen allerdings genau diese M glichkeit da die Daten hier spontan ausgetauscht werden sollen ohne dass Anfragen vorhanden sind Mehr zur Struk tur von GNUnet folgt jedoch im entsprechenden Abschnitt In den sp teren Abschnitten folgt zur L sung dieser Problemstellung ein detailliertes Konzept siehe Abschnitt mit samt Implementierung weshalb an dieser Stelle nicht weiter darauf eingegangen wird Anhand von Tabelle ist aber bereits jetzt zu erkennen dass die Funktionalit t und Realisierung des Paketdienstes von essenzieller Bedeutung f r das UbiMuC Gesamtprojekt ist Ohne diese Strukturen lassen sich die erstellten Anwendungsszenarien mithilfe von GNUnet nicht reali sieren 1 Einleitung 1 3 Minimalziele Das Ziel der Projektgruppe UbiMuC ist die Realisierung eines Prototypen f r einer mobilen Multimedia Community zum Austausch von multimedialen Inhalten unter Einsatz des Nokia N810 Die Benutzer von UbiMuC sollen mit Hilfe der Software in die Lage versetzt werden spontan untereinander Nachrichten und Informationen austauschen zu k nnen ohne dabei auf eine statische Netzwerkinfrastruktur angewiesen zu sein Dabei ist explizit die Nutzung der WLAN Funktio
105. nden Bugs wurden aus Zeit und Ressour cenmangel nicht behoben In dem Modul das die Kontaktliste umsetzt ist ein Bug bekannt e Gelegentlich wird ein Nutzer der sich im UbiMuC Netz befindet von der Kontaktliste nicht als online angezeigt Der Grund hierf r liegt wahrscheinlich in der Unzuver l ssigkeit der auf der GNUnet DHT aufbauenden Kontaktliste die die zugeh rigen Antworten auf DHT Anfragen nicht erh lt Das hei t der eigentliche Fehler liegt nicht im UbiMuC Modul sondern in der DHT von GNUnet die teilweise nicht korrekt auf DHT Anfragen antwortet Dieses Problem k nnte mit einem Patch f r GN Unet eventuell behoben werden 96 Literaturverzeichnis 1 Funktionsbeschreibung des N810 auf der deutschen Nokia Homepage ttp www nokia de A4630299 ag 2 Homepage des MPlayer Port f r Maemo ttp mplayer garage maemo org Es 3 Homepage des Pidgin Port f r Maemo ttp pidgin garage maemo org ag 4 Homepage des cross compilation toolkits Scratchbox ttp www scratchbox org ES 5 Skript zur Vorlesung Algorithmen f r Peer to Peer Netzwerke von P Mahlmann und Q CO O E D a O D g v E O H G E lt O 4 Y D ek CO v Q O zr O Les Pp uN O B E O 4 u O B O a ek O N e e A H ttp wwwcs upb de cs ag madh WWW Teaching 200458 AlgoP2P 6 Homepage der Peer to Peer Working Group ttp p2p internet2 edu index html
106. ne GNUnet Adresse an die im Paket enthaltene Source Route anh ngen Beginnend beim urspr nglichen Quell Peer entsteht ber die Zeit eine Routing Liste aller Peers die das Paket weitergeleitet haben Um Zyklen zu verhindern pr ft jeder Peer beim Empfang des GetRoute Pakets ob seine eigene Adresse nicht bereits in der Liste enthalten ist Ist dies der Fall verwirft er das Paket bzw leitet es nicht weiter Auf diese Weise werden Routing Zyklen verhindert und das Netz werk wird durch die schnelle Ausl schung von doppelten GetRoute Anfragen nicht unn tig berflutet GetRouteReply Das Verhalten beim Empfang einer GetRouteReply Nachricht ist dem von GetRoute sehr hnlich wobei die Peers hier nur daf r sorgen dass das Paket vom Ziel zur urspr nglichen Quelle zur ckkehrt Nach Empfang einer GetRouteReply Nachricht sucht der jeweilige Peer also nach der eigenen Adresse innerhalb der mitgelieferten Source Route und sendet das Paket an den dort verzeichneten unmittelbaren Vorg nger Sofern dies durch kurzfristige Ver nde rungen der Netzwerktopologie nicht m glich ist wird der Routingvorgang durch ein Timeout abgebrochen Jeder Peer auf dem Pfad der Source Route zwischen den Quell bzw Ziel Peers ist also als Teil der Route f r die Weiterleitung der Pakete verantwortlich Diese Weiterleitung findet solange statt bis das GetRouteReply Paket bei der urspr nglichen GetRoute Quelle angekommen
107. ner vom Typ Text ben tigt dessen Inhalt aus der zu bermittelnden Nachricht des Benutzers besteht Zus tzlich muss der Text Nachricht noch der Hashwert des Absenders vorangestellt werden Dies ist n tig damit auf der 61 4 Design Empf ngerseite mehrere Chat Sitzungen unterschieden werden k nnen Da eine eintreffende Nachricht keinerlei weitergehenden Informationen ber deren Ursprung oder Quelle erh lt war dieser Schritt zur eindeutigen Identifikation und Abgrenzung der Sitzungen notwendig Senden von Chat Nachrichten Da ein Objekt der Chat Klasse immer zwingend mit dem Paketdienst und einem Eintrag aus der Buddyliste beziehungsweise der DHT verbunden ist k nnen Chat Nachrichten un mittelbar vom erstellten Chat Objekt durch Aufruf der send Methode abgeschickt werden Das eigentliche bermitteln der Textnachricht wird dabei vom Paketdienst bernommen der mit einem vom Chat Objekt erstellten Datencontainer des Typs Text versorgt wird und die n tigen Inhalte in Form von Nutzdaten enth lt Empfang von Chat Nachrichten Auf der Empfangsseite sorgt ein eigener Listener Thread daf r dass die Datenpakete mit Text Flag entnommen und weiterverarbeitet werden k nnen Innerhalb des Threads werden die Nutzdaten aus den erhaltenen Datencontainern entnommen au erdem wird die Absen deradresse zur Herstellung des Kontextes extrahiert Anhand der Absenderadresse erfolgt die Zuordnung zu bereits bestehenden Chat Sitzung
108. net bereits im Abschnitt erl utert wurden ist das Kapitel der Transport und Kommunikationsschicht ein tieferer Blick auf GNUnet und die Kopplung an UbiMuC Im Gegensatz zum vorher gew hrten allgemeinen Einblick auf das Fra mework werden in diesem Kapitel unter Anderem die in UbiMuC weiterverwendeten Konzepte und Module beschrieben ebenso wie die genutzten Funktionen von GNUnet Zu den zentralen Konzepten geh ren Sachverhalte die beim Verst ndis von GN Unet weitergeholfen haben und eine Basis f r weiterf hrende Arbeiten bilden Hierzu geh rt unter anderem die Nutzerverwal tung von UbiMuC mittels der GN Unet DHT die Sende und Empfangsmechanik von GN Unet ber Handlen und Sendefunktionen sowie der Aufbau von sogenannten CRON Jobs Weiterhin wird in den GNUnet Services die Anbindung von GNUnet Applikationen beschrieben Dabei wird verst rkt auf die Module der Hostlisten und der DHT eingegangen da diese die f r die Entwicklung von UbiMuC haupts chlich verwendeten Applikationen darstellen Im Anschluss daran wird erl utert wie die Verkn pfung zwischen UbiMuC und GNUnet umgesetzt wird 3 1 GNUnet Konzepte Basierend auf der in Abschnitt geschilderten Struktur von GNUnet haben die Entwickler des Frameworks einige zentrale Module entwickelt die die Gesamtfunktionalit t von GN Unet realisieren F r UbiMuC ist jedoch die Nutzung aller Module berhaupt nicht notwendig so dass sich dieser Abschnitt dabei vor allen Dingen mit den von UbiMuC
109. ng 2 2 Aufbau eines reinen P2P Netzes Reine Peer to Peer Netzwerke sind zwar weiterhin angreifbar jedoch k nnen durch die voll kommen dezentrale Struktur nur selten Schl sselknoten ausgeschaltet werden Das Wegfallen eines Peers l sst somit das bestehende Netz nicht zusammenbrechen Eine hohe Ausfallsicher heit ist gew hrleistet Eine hohe Skalierbarkeit ist hierdurch ebenfalls gegeben Es ist zudem energiesparend da keine permanent betriebenen Server ben tigt werden Allerdings ist die Wartbarkeit des Netzes nahezu unm glich Die Suche nach Ressourcen ist durch die Time to live kurz TTL der Suchanfrage beschr nkt So sind Ressourcen einzelner Peers nicht im gesamten Peer to Peer Netzwerk verf gbar Auch das Finden vorhandener Peers ist eine Herausforderung f r die es bislang keine opti male L sung gibt Ist ein Teilnehmer des Netzwerks bekannt m ssen dem beitretenden Peer Adressen weiterer Netzwerkteilnehmer mitgeteilt werden In kleinen lokalen Netzwerken kann dieses ber eine Broadcast Anfrage realisiert werden Bei gro en Netzen wie beispielsweise dem Internet ist eine solche Methode jedoch nicht durchf hrbar 15 2 Grundlagen Daher wird das sogenannte Ping Pong Protokoll verwendet siehe Abbildung P 3 Hierbei sendet der beitretende Peer eine Ping Anfrage mit einer TTL von beispielsweise drei in das Netzwerk Jeder Peer der diese Anfrage empf ngt sendet eine Pong Antwort mit seiner eige nen Adresse a
110. nicht ge ndert hat l t sich daraus schlie en dass die Begrenzung der Geschwindig keit softwareseitig ist und nicht durch die Hardware hervorgerufen wird Durch die nderungen am Paketdienst in Revision 1187 ist die Verbindung dann viel stabiler geworden so dass auch Langzeittests m glich waren Insgesamt wurde gezeigt dass der Paketdienst eine ausreichen de Geschwindigkeit f r UbiMuC bereitstellt wobei die Geschwindigkeit dennoch nach oben begrenzt ist 4 3 Nutzerverwaltung In diesem Unterkapitel wird auf den Teil unseres Programms eingegangen der die Verwaltung von Nutzern regelt Der Zweck diese Teils unserer Software ist die Kommunikation verschie dener UbiMuC Nutzer innerhalb eines gemeinsamen Netzes komfortabler zu gestalten indem wir jedem Nutzer eine Liste bekannter anderer Peers inklusive deren Status bereitstellen Auf diese Weise ist es dem Nutzer leichter m glich den berblick ber aktuell im Netz erreichbare Peers zu behalten und mit diesen eine Verbindung aufzubauen Die Module f r Chat und Multimedia Streaming nutzen daher auch die von der Nutzerver waltung bereitgestellten Daten zum Verbindungsaufbau Dar ber hinaus hilft die zentrale Sammlung all dieser Informationen auch eine einfache Schnittstelle zur Anzeige in der GUI zu definieren Die Idee lehnt sich an Kontaktlisten als zentrale Organisationsform der Ge spr chspartner an wie sie in den meisten Messaging Programme blich sind 53 4 Design
111. nitt durchgef hrt Die Verbin dung auf GNUnet Ebene wird unmittelbar im Anschluss ber den Download von Hostlisten eingerichtet Das Hostlisten Modul stellt einen kompakten HTTP Server zur Verf gung ber den dieser Austausch erfolgen kann Der genutzte HTTP Server stammt aus der libmicrohttpd Bibliothek die ebenfalls dem GNUnet Projekt entstammt aber auch als eigenst ndige Bibliothek genutzt werden kann Eine eingehende HTTP Anfrage nach einer Hostliste wird vom HTTP Server an eine Callback Funktion bergeben Diese erstellt dann aus den vorhandenen HELLO Nachrichten eine Liste die dann an den HT TP Server zur ckgegeben wird Der Server bertr gt dann die Hostliste an den Anfragenden 3 2 Kommunikation zwischen UbiMuC und GNUnet Daemon Wie in Abschnitt 2 2 bereits erw hnt wurde ist das GNUnet Framework als Client Server Architektur organisiert Demnach gibt es einen eigenst ndigen Serverprozess mit dem Namen gnunetd der vollkommen unabh ngig von den Clientprozessen und damit auch von UbiMuC l uft Der getrennte Adressraum von Prozessen erfordert es daher einen geordneten Nachrich tenaustausch zwischen UbiMuC und gnunetd zu implementieren S mtliche daf r notwendigen Funktionen stellt GNUnet bereits in einer Bibliothek zur Verf gung die nur noch hinzugelinkt werden muss Damit kann man hnlich zu UDP Sockets Daten paketorientiert austauschen 35 3 Transport und Kommunikation Jedes bertragene Datenpaket b
112. nn der maximal f r die DHT zu nutzende Speicherplatz nahezu komplett verwendet wird Geht eine erneute PUT Anfrage f r ein Paket ein dessen Kategorie und Nutzdaten iden tisch zu einem bereits gespeicherten Paket sind wird nur dessen Lebenszeit aktualisiert da das Paket ja bereits vorhanden ist Auslesen von DHT Werten Das Auslesen von Daten geschieht durch das Versenden von DHT Get Messages Diese werden vom GNUnet Dienst an eine festgelegte Anzahl anderer Nutzer weitergeleitet welche selbst wiederum bis zu einer festgelegten Netztiefe weiterleiten Es werden dabei immer alle Eintr ge einer bestimmten Kategorie von der Datenstruktur erfragt Jene Knoten die eine Anfrage f r auf ihnen verf gbare Pakete empfangen antworten mit einer DHT Result Message M gliche Probleme der DHT und UbiMuC spezifische Anpassungen Generell ist die DHT keine verl ssliche Datenstruktur Es ist nicht sichergestellt dass die GET Anforderungen auch an all jene Nutzer weitergeleitet werden die die entsprechenden Daten haben Dieses Problem wird dadurch verringert dass Anfragen fter weitergeleitet werden als dies mit den Standardeinstellungen der Fall ist Des Weiteren kann es helfen die Redundanz von DHT Eintr gen im Netz zu erh hen 34 3 2 Kommunikation zwischen UbiMuC und GNUnet Daemon Da die DHT im Falle von UbiMuC nur f r sehr kleine Eintr ge genutzt wird haben wir uns daf r entschieden eingehende PUT Nachrichten immer
113. nnen Dies wird ber ein mehrdimensionales Array realisiert welches eine Spalte pro Nachrichtentyp be sitzt in der s mtliche Handler Funktionen abgelegt werden k nnen Schl gt die Behandlung durch eine Handler Funktion fehl wird automatisch die n chste sofern vorhanden aufgerufen Die Nachrichtentypen werden in gnunet protocols h definiert Hier bei muss darauf geachtet werden dass die Nummerierung eindeutig ist Handler werden mit GNUNET CORE p2p register handler registriert Diese Funktion erg nzt haupts chlich das Array um den selbst geschriebenen Handler der mit den GN Unet Konventionen konform sein muss 3 1 2 CRON Innerhalb des GNUnet Frameworks existieren eine Reihe von Aufgaben die in bestimmten Zeitabschnitten wiederkehrend ausgef hrt werden m ssen Sei es das Versenden von HELLO Nachrichten oder im Rahmen der Initialisierung der verteilten Hashtabelle F r solche Aufga ben bietet GNUnet einen Cron Manager an der einzelne Methoden nach bestimmten Zeitsche mata ausf hren kann Dieser Cron Manager ist an das Cron System angelehnt welches unter unixoiden Systemen Programme automatisiert ausf hren kann arbeitet aber auf Methoden ebene Mit Hilfe dieses Cron Managers wird eine threadbasierte Nebenl ufigkeit erm glicht N tzlich ist diese Funktion in unserem Falle insbesondere f r Timeouts da der Kontrollfluss so 30 3 1 GNUnet Konzepte w hrend die Wartezeit abl uft weiter fortsch
114. nt_connection b DANN Dialog Ferster i i SONST 8 WENN current_connection Hash B H UND connection_established FALSE H DANN 1 i Setze y eonnection_established TRUE 4 H i i Baue Request Paket i i Empf nger Hash 3 H Zender H ah F i Flags Request Paket rv Vollst ndige Konferenz Behandlung DANN Dialog Ferster SONST WENN current_connection Hash i UND connection_established FALSE DANN Saze connection_established TRUE Baue Request Paket Empf nger H ash Sender H ach i Flags V Konferenz besteht po ARHAR Behandlung i H i Pakcetwird verworfen b Abbildung 4 17 Handshake beim Verbindungsaufbau einer Audio Video Konferenz 69 4 Design Diese Beschr nkungen wurden zum einen eingef hrt um den Verbindungsaufbau nicht zu verkomplizieren zum anderen um die vorhandene Hardwareplattform nicht zu berlasten da die Auslastung des N810 auch bei nur einer einzigen Verbindung schon recht hoch ist Generell arbeitet der Verbindungsaufbau in der Art dass Nachrichten nur dann beantwortet werden wenn das eigene System gerade in einem Zustand ist der einen Verbindungsaufbau zul sst Das Abweisen von Verbindungsanfragen oder von Paketen die momentan nicht erwartet werden geschieht nur implizit das hei t sie werden nicht beantwortet sondern einfach ignoriert Generell wird davon ausgegangen das
115. nten auch mit dem GPS Ger t des N810 gekoppelt werden um die Standpunkte f r die einzelnen Informationen besser zu lokalisieren Da heutzutage immer mehr mobile Ger te mit WLAN ausger stet werden w re eine Portie rung von UbiMuC auf andere Systeme auch sehr interessant Hier bieten sich unter anderem Mobilfunkger te Spielekonsolen Pocket PC s oder hnliche an Die Mobilfunkger te bieten zus tzlich noch die M glichkeit f r das lokale Ad Hoc Netz eine Schnittstelle ber die Mobil funkleitung zum Internet bereitzustellen 84 7 Appendix 7 1 Config Parser Der Configparser hat die Aufgabe die in einer Konfigurationsdatei abgelegten Werte in vom Programm nutzbare Datenstrukturen umzuwandeln Dabei handelt es sich um die einzelnen Eintr ge der Kontaktliste die Konfigurationseinstellungen des Programms selbst und die ei gens hinterlegten Zusatzinformationen Die Konfigurationsdatei liegt als plaintext Datei im Home Verzeichnis des Benutzers und k nnte somit auch von Hand editiert werden Die Datei ist wie oben bereits beschrieben in drei Bereiche aufgeteilt Neben berschriften zum Beispiel owninfo sind nur Eintr ge der Form lt Key gt lt Value gt vorhanden Dies vereinfacht die Dekodierung der einzelnen Werte extrem Der Configparser liest die Datei zeilenweise ein und interpretiert die gelesene Zeile abh ngig vom Bereich der Datei in dem er sich aktuell befindet Sollte eine gelesene Zeile
116. on und bauen direkt eine Verbindung zum neu hinzugekommenen Peer auf Der Peer der sich neu ins Netz einbucht und den GNUnet Dienst bekannt gibt sendet seinerseits auch eine Anfrage nach bereits vorhandenen Diensten und baut eine Verbindung zu allen Peers auf die auf diese Anfrage geantwortet haben Zum Verbindungsaufbau werden per http Anfrage die Hostlisten der anderen Peers angefor dert In diesen stehen dann unter Umst nden auch schon weitere Peers die sich momentan au erhalb des eigenen Empfangsradius befinden die er aber ber GNUnet trotzdem errei chen kann N heres zu den Hostlisten unter B 1 3 2 Nach Herunterladen der Hostliste kann der Peer beginnen sich an der Verteilten Hashtabelle zu beteiligen um die Personensuche aufnehmen zu k nnen 2 5 Struktur von UbiMuC Dieses Kapitel behandelt die Schicht zwischen GNUnet und der GUI dem sogenannten WIR Interaction Relay kurz WIR Damit die Basisfunktionen von GN Unet von unserer Anwendung genutzt werden k nnen ist es erforderlich die zentralen GN Unet Programmteile zu kapseln und so f r uns nutzbar zu machen Durch die Kapselung sollen weitergehende Eingriffe in den GNUnet Quellcode umgangen werden Im Falle von sp teren Weiterentwicklungen oder Codever nderungen durch die GN Unet Community ist es dann h chstens notwendig unsere Schnittstellen anzupassen Alle Anfragen unserer Anwendung an das GN Unet Netzwerk sollen in diesen Interface Klassen bersetzt und angepasst werd
117. r In Abbildung 2 5 wird das Zusammenspiel der einzelnen Komponenten der UbiMuC Plattform bei einem Datenaustausch zwischen zwei Nutzern graphisch dargestellt Die Pfeilrichtung gibt dabei die Flussrichtung der Befehle und Daten an W hlt der Nutzer beispielsweise die Videokonferenz Option in der GUI aus wird eine GStrea mer Instanz starten Diese steuert selbstst ndig die im N810 eingebaute Webcam und das Mi krofon an Die daraus gewonnenen Video und Audiorohdaten werden vom G teamer Prozess in Echtzeit in ein Format konvertiert das sich relativ leicht ber ein Netzwerk streamen l sst Auf die Details der Multimediaverarbeitung wird genauer in Kapitel 4 5 eingegangen Die ko dierten Multimediadaten werden in der WIR Schicht an den Paketdienst weitergereicht der sie f r den Versand auf GNUnet Ebene vorbereitet In GNUnet sind unsere selbst definierten Nachrichten durch unsere Anpassungen registriert so dass anschlie end die Pakete ber die GNUnet Schicht im Netzwerk bertragen werden k nnen ohne das GNUnet deren Inhalte kennen muss Auf der Empf ngerseite verarbeitet die WIR Schicht auf analoge Weise die Pakete von GNU net allerdings in umgekehrter Reihenfolge Der Paketstrom wird von unserem Paketdienst wieder zu einem kontinuierlichen Datenstrom zusammengesetzt und an den GStreamer wei tergereicht In der GUI l uft schlie lich der GStreamer eingebettet und zeigt den Multimedia Stream an Chatnachrichten k nnen auf hnlic
118. ramework besteht aus modu laren Komponenten wie Multimediaquellen und senken Codecs und Filtern Diese k nnen in so genannten Pipelines zusammengesetzt werden Die Modularit t des Frameworks erlaubt eine leichte Erweiterbarkeit durch externe Komponenten die als weitere Plugins hinzugef gt werden k nnen Als Sourcen werden Protokolle wie TCP und UDP aber auch Hardware ber Standard Schnittstellen wie VideofLinux und ALSA 14 unterst tzt ALSA ist eine Schnittstelle f r Audio Hardware Video4Linux eine Schnittstelle f r Video Hardware wie TV Karten oder Webcams Die auf dem N810 verbaute Webcam unterst tzt Video4Linuz und kann somit durch das GStreamer Plugin angesprochen werden ALSA hin gegen wird nicht verwendet die Audio Hardware ist jedoch ber spezielle Audio Sinks und Sourcen ansprechbar Diese Plugins sind teilweise DSP gest tzt Durch ihren Einsatz ergeben sich erhebliche Performanzvorteile zur Laufzeit Heutzutage ist GStreamer schon die Grundlage einiger Multimedia Anwendungen und essen zieller Systembestandteil vieler Linux Distributionen da es in der weit verbreiteten Deskto pumgebung GNOME verwendet wird Auch das auf dem N810 verwendete Debian Derivat setzt GStreamer ein Zudem stellt GStreamer APIs f r eine Vielzahl von Programmierspra chen insbesondere C und C zur Verf gung Letztendlich waren die DSP Unterst tzung und die native Anbindung der Audio Hardware an GStreamer der Anlass diesen anstelle
119. rden einige Operatoren berladen Mit den blichen Vergleichsoperatoren kann man nun gegen die Sequenznummer vergleichen um die Reihenfolge der Datenpakete zu ermitteln Abschlie end wurden noch sechs Konstruktoren eingef gt die besonders h ufig vorkommende Daten wie Textdaten effizient behandeln 4 2 UbiMuC Transportschicht Die eigentliche Transportschicht von UbiMuC besteht aus einem bei jedem Peer verf gba ren Paketdienst Dieser sorgt daf r dass Verbindungen zwischen den UbiMuC Teilnehmern ber das GNUnet Netzwerk ohne gro en Aufwand hergestellt und verwaltet werden k nnen Aufgrund der Beschr nkungen durch die vorliegende GNUnet Architektur und den allgemei nen Aufbau des Frameworks siehe Abschnitt ist die Bereitstellung einer allgemeinen Schnittstelle zum Datenversand und empfang unausweichlich GNUnet verf gt ber kein natives Multi Hop Routing ausgenommen das Filesharing Modul daher k nnen Daten zwischen Peers nur dann ausgetauscht werden wenn diese ber eine direkte Verbindung zueinander verf gen Ist diese direkte Verbindung nicht vorhanden m ssen die Daten ber andere Teilnehmer weitergeleitet werden Um jedoch diese Weiterleitung zu erm glichen muss eine Pfadliste zwischen Quell und Ziel peer vorliegen die f r den Datentransfer benutzt werden kann Diese Pfadliste wird mittels der in Abschnitt 4 2 1 1Jerl uterten GetRoute und GetRouteReply Nachrichten aufgebaut Mit Hilfe dieser Pfadli
120. reitet Der Cron Manager erm glicht sowohl die einmalige Ausf hrung einer Methode nach einer bestimmten Zeit als auch die wiederkehrende Ausf hrung einer Methode in gewissen Zeitabst nden Die auszuf hrenden Funktionen d rfen keinen R ckgabewert haben Weiterhin m ssen die Funktionen einen Zeiger als Parameter bergeben bekommen 3 1 3 GNUnet Applikation Services GNUnet ist ein Peer to Peer Framework welches verschiedene Services und Applikationen unterst tzt Es basiert auf mehreren Schichten wie in Abbildung B 1 zu sehen ist wobei die Hauptschicht gnunetd als Server ausgef hrt wird Diese kann mittels TCP eine Verbindung mit seinen Clients aufbauen Weiterhin enth lt gnunetd eine GN Unet Core Schicht in der sich die Services befinden Diese Services k nnen von den Clients die den Applikationen entsprechen ber eine Applikation Service API angefragt werden Server gnunetd Application Service API I AAA Client Abbildung 3 1 Schichtenmodell GNUnet Die Services und Applikationen die beim UbiMuC benutzt werden sind in der Tabelle zusammengefasst Im Folgenden werden diese kurz vorgestellt und erl utert Services Applikationen Identity Advertising Transport Getoptions Stats Traffic PingPong Datastore Topology Avahi Fragmentation DHT State Hostliste Boostrap Tabelle 3 1 Services und Applikationen 31 3 Transport und Kommunikation Services Ein Service ist ein interner
121. rmatik der Technischen Universit t Dortmund statt Die Aufgabe bestand in der Entwicklung einer dezentral organisierten Multimedia Community auf einer mobilen Plattform 1 1 Motivation Mit der zunehmenden Verbreitung von drahtlosen Netzwerktechnologien und deren Integra tion in Mobiltelefonen Smartphones Netbooks und Internet Tablets w chst gleichzeitig das Bediirfnis nach entsprechender Software zur Nutzung und Interaktion mit den verschiedenen Technologien Fiir den Multimediasektor gibt es derweil Insell sungen die beispielsweise das Streaming von Inhalten durch einen dedizierten Medienserver zu drahtlosen Teilnehmern er m glichen Auf Seiten der drahtlosen Kommunikation mit Mobiltelefonen gibt es dank Smart phones mit WLAN und UMTS nun auch die M glichkeit der Internet Telefonie per VoIP was jedoch mit recht hohen laufenden Kosten verbunden ist Integrierte Webcams in Notebooks erm glichen bei vorhandenem Internet Zugang die Erstellung von Videokonferenzen durch Skype oder andere Programme Alle der gerade erw hnten L sungen ben tigen jedoch immer eine vorhandene Infrastruktur oder expliziten Internet Zugang Zielsetzung Im Rahmen der Entwicklung einer mobilen Multimedia Community sollen die einzelnen Teil nehmer ber ein drahtloses Netzwerk verbunden werden und miteinander kommunizieren k n nen Im Mittelpunkt der Bem hungen steht dabei der konzeptionelle Entwurf einer solchen Softwareumgebung sowie die Integration verschie
122. rworfen wird siehe Abbildung 4 22 F r den Verbindungsaufbau ist es letztlich nur relevant welche Werte current connection und connection established haben wenn eingehende AV Konferenz Pakete festgestellt wer den Dabei wird immer wenn bei Eingang eines AV Konferenz Pakets die Variable cur rent connection Null ist der Nutzer gefragt ob eine Verbindung zum anfragenden Nutzer aufgebaut werden soll Wenn die Variable nicht Null ist so wird gepr ft ob sie gleich dem 72 4 5 Multimedia UbiMuC Hash des Absenders des empfangenen AV Konferenz Paketes ist und ob au erdem die Verbindung noch nicht hergestellt wurde Ist dies der Fall so werden die Schritte eingeleitet die n tig sind um die Ports zu ffnen und Daten zu versenden Durch Setzen der Variablen connection established auf TRUE wird notiert dass die Ports offen sind um sicherzustellen dass nicht mehrfach versucht wird Ports zu ffnen Sollte man sich in keinem der oben genannten Zust nde befinden so wird keine Audio Video Konferenz er ffnet Gibt es keinen Eintrag im Handler f r den aktuellen Zustand so werden die eingehenden Pakete verworfen und es tritt keine Reaktion ein Mit diesem simplen Mechanismus wird si chergestellt dass es nicht zu Deadlocks beim Verbindungsaufbau kommen kann wenn mehrere Nutzer nahezu gleichzeitig versuchen Verbindungen zueinander aufzubauen Nach erfolgtem Aufbau einer Verbindung sind
123. s bisher keine aktive Verbindung besteht und bisher auch keine Anfrage abgeschickt wurde Der aktuelle Status des Clients wird mit zwei Variablen gespeichert Zum einen wird in der Variable connection established festgehalten ob man momentan in einer vollst ndig etablierten Konferenz ist Sie ist mit FALSE vorinitialisiert und sollte nur dann wenn gerade eine Verbindung aktiv ist auf TRUE gesetzt werden In der Variablen current connection wird der UbiMuC Hash des Nutzers festgehalten mit dem man gerade versucht eine Verbindung aufzubauen oder mit dem man bereits eine Kon ferenz hat Dies ist n tig um sicherzugehen dass die Pakete dieses Nutzers nicht einfach verworfen werden Hier ist nur dann ein Wert eingetragen wenn gerade eine Verbindung auf gebaut werden soll oder eine Verbindung besteht Ist dies nicht der Fall muss dieser String leer sein um sicherzugehen dass eine neue Verbindung aufgebaut werden kann Generell wird fast alles mit einem simplen Request Paket abgearbeitet Dieses besteht da bei aus dem UbiMuC Hash des Empf ngers dem eigenen Hash sowie optionalen Flags Um einen funktionsf higen Handshake zu erm glichen ist des Weiteren ein Listener n tig der eingehende Request Pakete passend behandelt Im Folgenden werden nun die einzelnen Schritte des Handshake f r den Verbindungsaufbau beschrieben Dabei steht Client A f r jenen der die Konferenz initiiert und Client B f r denjenigen der die
124. s einfach m glich ist bestehende Streaming Daten zwischen den Anwendungen der entsprechenden Peers ber GNUnet geleitet zu versenden 81 6 Fazit Nutzerverwaltung Die Nutzerverwaltung erm glicht dem Nutzer von UbiMuC mit seinen Eintr gen in der Kon taktliste in Kontakt zu treten sobald diese als verf gbar angezeigt werden Die von GNUnet bereitgestellte DHT liefert die Basis f r diese Nutzerverwaltung Da diese jedoch nicht zur lokalen Speicherung der ben tigten Informationen genutzt werden konnte wurden weitere UbiMuC Strukturen als zus tzliche Abstraktion der DHT Informationen entworfen Mittels der entwickelten DHT Schnittstelle wurde es erm glicht auf einem lokalen Abbild der DHT zu arbeiten und die GN Unet eigenen Strukturen unber hrt zu lassen Als zus tzliches Feature wurde die Kontaktliste hinzugef gt mit der der Nutzer selbst ndig bekannte Netz teilnehmer zu einer eigenen Freundesliste hinzuf gen und dies dauerhaft abspeichern kann Chat Der Chat bietet eine direkte Punkt zu Punkt Kommunikation zwischen Nutzern Dieser stellte die Vorarbeit f r Audio Video Konferenzen da weil der Transfer von Text Segmenten einfa cher zu realisieren war als die bertragung gro er Datenmengen in Echtzeit Um den Chat komfortabler nutzen zu k nnen wurde er mit der Nutzerverwaltung verkn pft und eine intui tive Benutzeroberfl che hierf r erstellt Multimedia Im Zusammenhang mit Multimedia Streams wurde sich
125. schwindigkeitstests von GNUnet 4 3 Nutzerverwaltung 10 10 12 13 13 18 21 22 23 25 26 29 29 30 30 31 33 35 35 37 37 39 40 41 42 45 45 46 47 48 49 49 53 Inhaltsverzeichnis 4 3 1 Konzepte und Spezifikationen 2 22 2 Co un nn 4 3 1 1 Abstraktiomsebenedl e 4 3 1 2 Schnittstellen zwischen DHT und Core sowie Core und GUI 4 3 2 Implementierung 2 Eon nn AA ee ee ee ee ee a e e aie a e e a e 4 4 2 Implementierung 2 2 22 a a Be in ae ee rar ehe EEGENEN 4 5 1 Konzepte und Spezifikationen 2 22 2 2 rn nn nn 4 5 1 1 G treamerl 2 22 on 4 5 1 2 Genutzte Codecs 2 2 2 22 mon 4 5 1 3 Genutzte Protokolle 45 14 Auf und Abbau einer Konferenz ooo aaa 4 5 2 Implementierung 2 En nn 4 5 2 1 Audio Implementierung 22 2 22 nn nn 4 5 2 2 Kamera Integration 2 onen 5 Evaluierung 6_ Fazit 6 1 Projektzusammenfassung paraa e rechte ha 6 3 Ausblick EE 7 Appendix EE EEN 713 Benutzerhandbuch 22 2 2222 CC Lone 1 4 _ Bekannte Fehlerl nn nen Literaturverzeichnis Abbildungsverzeichnis Tabellenverzeichnis 77 81 81 83 84 85 85 86 87 96 97 99 101 D i 1 Einleitung Die Projektgruppe 526 Ubiquitous Multimedia Community UbiMuC fand im Sommerse mester 2008 und im Wintersemester 2008 2009 am Lehrstuhl 12 der Fakult t fir Info
126. ste kann anschlie end eine Weiterleitung der Daten ber jeden einzel nen Peer durch Verwendung von UbiMuC DataBlock Nachrichten erfolgen Abbildung verdeutlicht den geschilderten Vorgang Ablauf 1 GetRoute 2 GetRouteReply 3 UbiMuC_ Data Block U Abbildung 4 2 Struktur des Routings 39 4 Design Ein weiterer wichtiger Aspekt liegt au erdem in der Kapselung der GNUnet internen Daten strukturen so dass diese nicht bis zu den Routinen f r AV Konferenz und Chat weitergef hrt werden m ssen Zu diesem Zweck wurde ein eigener Datencontainer entwickelt der s mtliche Nutzdaten kapselt und vom Paketdienst zur Kommunikation mit anderen Teilnehmern des Netzwerkes benutzt wird Der Paketdienst wird dabei an dieser Stelle kurz erw hnt wobei ei ne detaillierte Erl uterung der Routing Konzepte und Vorgehensweisen in den nachfolgenden Abschnitten beschrieben wird Paketdienst Da GNUnet nativ keine extern nutzbare Schnittstelle bereitstellt um auf direktem Wege un kompliziert und ohne vorherige Anforderung Daten zwischen zwei Teilnehmern auszutauschen war es n tig einen solchen Datendienst f r Nutzdaten der Multimedia beziehungsweise Chat Module selbst einzubauen Die eigentliche Verbindung zwischen den UbiMuC Teilnehmern wird ber ein eigens daf r entworfenes Routing Protokoll Get Route mittels Erkundung des Netzwerkes aufgebaut und bei den jeweiligen Endpunkten in Form
127. t Black Hi Z Agent Orange Hallo Abbildung 7 9 Aktive Chatsitzung in der UbiMuC Benutzeroberfl che GUI Screenshot Es ist m glich mit mehreren Personen parallel zu chatten Dabei wird jede Chat Sitzung als einzelner Reiter am oberen Bildschirmrand angezeigt Um Nachrichten an den aktuell ausge w hlten Nutzer zu schicken muss diese Nachricht in das Textfeld am unteren Bildschirmrand eingegeben und das Senden Icon angeklickt werden Das Senden mittels dr cken der Enter Taste ist ebenfalls m glich ai _ _ __ __ _ _ _ _ _ _ _ ______RoEEO IAAOOGEGE AAA Abbildung 7 10 Eingabefl che und Senden Button in der UbiMuC Benutzeroberfl che GUI Screenshot 92 7 3 Benutzerhandbuch Optionsmen s Um die Optionenmen s aufzurufen gen gt ein Klick auf den Programmnamen mit anschlie ender Auswahl des entsprechenden Eintrags r GnUbiMuC Optionen Meine Infos ndern Schlie en AYEIL NIIS Abbildung 7 11 Aufruf des Optionsmen s GUI Screenshot Im eigentlichen Optionsmen lassen sich diverse Einstellungen wie der Startbefehl des GNU net Daemons oder die von der Videokonferenz benutzten Ports ndern Ein Klick auf An wenden sorgt daf r dass die Einstellungen bernommen und gespeichert werden GnUbiMuC ROLDA Y x Optionen Buddig Nickname Agent Orange Agent gnunetd Befehl gnunetd d I c etc gnur is Video Port out 5000 ent g Video Port in
128. t Daemon aufgebaut und mit Hilfe dieser Verbin dung werden die Befehle zum Lesen beziehungsweise Schreiben von Werten aus der respektive in die DHT realisiert Da es sich bei GNUnet um ein in C geschriebenes Tool handelt geschieht dies ber einzel ne Funktionsaufrufe die den Erfolg beziehungsweise Misserfolg mittels eines Status Codes mitteilen Daher haben wir die einzelnen Routinen in eine C Klasse gekapselt welche die einzelnen C Funktionen benutzt und die Ergebnisse in Form einer Liste an die n chste Schicht das Verwalten der einzelnen Buddies weiterleitet Das Verwalten der einzelnen Buddies Das Ergebnis der DHT Ansteuerung ist eine Liste die ein Abbild unserer lokalen DHT dar stellt In dieser Liste sind jedoch nicht nur Informationen zu den einzelnen Personen in der Buddyliste sondern auch zu vielen weiteren Buddies vorhanden Daher muss die von der DHT erhaltene Liste gefiltert und mit den Eintr gen in der jeweilig aktuellen Buddyliste verkn pft werden Dies geschieht dadurch dass entsprechend der Eintr ge in der von der DHT stam menden Liste der Onlinestatus der Eintr ge der spezifischen Buddyliste aktualisiert wird Zus tzlich wird hier eine Art Caching realisiert um der Unzuverl ssigkeit genauer gesagt dem nicht deterministischen Verhalten der DHT entgegen zu wirken Die resultierende Bud dyliste inklusive Onlinestatus der einzelnen Buddies wird zur Weiterleitung an die GUI zus tzlich noch sor
129. t deterministisch vorhergesagt werden kann welche Antworten eingehen werden und von wo diese kommen werden Dies hat zur Folge dass durchaus nicht immer alle Werte die in der Datenstruktur im gesamten Netz vorhanden sind auch als Antwort auf die Anfrage geliefert werden In UbiMuC wird die hier beschriebene verteilte Datenstruktur genutzt um die in Abschnitt 4 3 n her erl uterte Nutzerverwaltung zu realisieren ohne daf r einen zentralen Server zu ben tigen Struktur der GNUnet DHT Jeder GN Unet Client mit aktiviertem DHT Modul sendet regelm ig P2P_ DHT__Discovery Nachrichten an das Netz um so mit anderen Knoten der Hashtabelle bekannt gemacht zu wer den An diese bekannten anderen Knoten werden dann Anfragen weitergeleitet Die Anzahl der Weiterleitungen ist zur Kompilierzeit festgelegt genau wie die Redundanz der Eintr ge welche bestimmt wie oft ein Wert im gesamten Netz gespeichert werden soll Dies gilt so wohl f r Anfragen f r das Ablegen von Daten sogenannte DHT Put Messages als auch f r Anforderungen von Daten den DHT Get Messages 33 3 Transport und Kommunikation Generell besteht jeder DHT Eintrag aus einem Daten Tripel Zum einen verf gt jeder Ein trag ber eine Lebenszeit die festlegt wie lange diese Daten bei GET Nachrichten noch gefunden werden k nnen Dieser Wert ist eine zur Kompilierzeit festgelegte Konstante und standardm ig auf zw lf Stunden voreingestellt Pakete
130. tatistischen Auswertung der Datentransfers steht in GNUnet ein gesondertes Modul bereit Dort k nnen unter anderem die versendeten und empfangenen Datenpakete in Form eines Graphen visualisiert werden Im Wesentlichen dient das Modul jedoch nur einer recht oberfl chlichen Einordnung der Netzwerkauslastung um dem Benutzer einen groben Eindruck ber den vorliegenden Datendurchsatz zu geben 20 2 3 Ad Hoc Netzwerke Nachrichtentypen und Protokolle Zur Nutzung des GNUnet Netzwerkes f r UbiMuC war es notwendig eigene Nachrichtenty pen und dazu passende Callback Funktionen innerhalb des GNUnet Serverprozesses und des Clients zu registrieren Der GNUnet Kern behandelt Nachrichten anhand ihres Typflags und ordnet sie den dazu passenden Behandlungsmethoden zu und ruft diese auf Die Zuordnung zwischen Nachrichtentyp und Callback Funktion muss daher stattgefunden haben da sonst keine Behandlung eben dieser neuen Typen m glich ist Diese neuen Nachrichtentypen werden von UbiMuC dazu benutzt um eigene Nachrichtenformate zu erstellen und selbstentwickelte Protokolle ber GNUnet zu betreiben Der modulare Aufbau von GNUnet erleichterte dabei die Realisierung der eigenen UbiMuC Nachrichtentypen Diese wurden per Namensgebung und eindeutiger Nummerierung innerhalb des Core in die entsprechende Protokolldatei eingetragen und standen dann f r die allgemeine Nutzung bereit Ohne diese vorherige Registrierung und Bekanntmachung der Typen w rden vo
131. te A und C sind durch iptables Eintr ge gegenseitig gesperrt so dass sie nicht mehr direkt miteinander kommunizieren k nnen und das Ger t B als Hop benutzen m ssen Bei der Anmerkung echter Hop wurde die Ger te so weit voneinander entfernt dass sie sich wirklich nicht mehr sehen konnten Dauer min Gesendete Daten Bytes KB s Anmerkungen 01 35 3686400 37 89 iptables 04 22 13639680 50 84 iptables 02 40 5529600 33 75 echter Hop loud 00 33 1781760 52 73 echter Hop loud auf Senderseite 05 48 18923520 53 1 echter Hop loud auf Senderseite Tabelle 4 2 Test mit GN Unet Revision 804 drei Ger te Die Ergebnisse zeigen dass sich hierbei kein gro er Unterschied zwischen den beiden Test konstellationen ergibt Beide Testkonstellationen schwanken circa zwischen 34 KB s und 53 KB s In Tabelle 4 2 sind die Ergebnisse dargestellt wobei die Anmerkung loud bedeutet dass GN Unet mit Debug Ausgaben gestartet wurde Dauer min Gesendete Daten Bytes KB s Anmerkungen 03 31 22179840 102 65 loud 05 06 33300480 106 27 loud 01 48 11243520 101 67 02 59 18493440 100 89 04 00 25067520 102 Tabelle 4 3 Test mit GNUnet Revision 1179 drei Ger te Die Tabelle zeigt die Ergebnisse der Tests mit der GNUnet Revision 1179 bei der sich der Datendurchsatz deutlich erh ht hat Hier wurde wieder mit drei Ger ten getestet und Ergebnisse um die 104 KB s
132. technische universitat dortmund PG ENDBERICHT PG 526 UbiMuC Ubiquitous Multimedia Community Fakult t f r Informatik Institut f r eingebettete Systeme Autoren Bj rn Bosselmann Markus G rlich Thomas Grabowski Nils Kneuper Michael Kupiec Lutz Krumme Fabian Marth Michael Puchowezki Markus Straube Stephan Vogt Stefan Wahoff Jens Wrede Betreuer Dr Heiko Falk Constantin Timm Abgabedatum 31 M rz 2009 Inhaltsverzeichnis 1 Einleitung E E EII E O a a o a en id dde dd dd a Y o dr Baer 1 4 Hardware und Arbeitsumgebung 1 5 Struktur des Endberichtesl e 2 Grundlagen EEE EEE ERROR ee EC EE ee AR II un a re EE ne Er EE 24 Auch DEPOR RARE nr Bier arena ee g e Sn Ee Era Sr bee a EE a Fe EE a a rer 2 7 Projektplanung des zweiten Semesters 3 Transport und Kommunikation 3 1 GNUnet Konzepte 3 1 1 NUnet Handlerl EE NN E E A E E 3 131 DHT Modull 2 2 oo Coon 3 1 3 2 Hostlisten Modull e Fr dd 4 1 Datencontainer 4 2 UbiMuC TIransportschicht 2 22 2 2 Coon nn y UN u en da qe ee ae a Me a 4 2 1 1 Nachrichtenformatel 22 2 2 2 non nn 4 2 1 2 Routingkonzepte l 2 2 2 2 Co rn nn A ee Bene eher AA 4 2 2 Implementierung 22 22 2 Coon 4 221 Handler 4 2 2 2 Paketdienst Schnittstellel 2 2222 22mm 4 2 2 3 Erstellung der UDP Socketsl 2 2222222 4 2 2 4 Kontroll Protokolll 2 22 22 2 nn nen 4 2 3 Auslastungs und Ge
133. tiert prim r nach Onlinestatus sekund r lexikalisch Anzeigen in der GUI Die so bearbeitete Liste wird daraufhin zum Anzeigen an die GUI weitergeleitet Dort werden die einzelnen Eintr ge in eine GTK kompatible Datenstruktur konvertiert und in einer Liste angezeigt Der Onlinestatus wird dabei durch eine entsprechende Farbe Gr n f r Online Rot f r Offline realisiert Als Schwierigkeit hat sich hierbei die Prozess Synchronisation erwiesen da GTK nicht thread safe ist Daher musste ber das Sperren beziehungsweise L sen eines Mutex sichergestellt wer den dass die Datenstruktur zur Speicherung der darzustellenden Eintr ge konsistent bleibt Des Weiteren stellt die GUI eine gewisse Funktionalit t zum Hinzuf gen und L schen von Bud dies sowie zum Umbenennen eben dieser bereit Dabei handelt es sich um einfache Dialoge die die entsprechenden Befehle an den Core weiterleiten um die dort befindlichen Datenstruk turen dementsprechend anzupassen 58 4 4 Chat 4 4 Chat Das UbiMuC Chatmodul soll den Benutzern der Software im Rahmen der in Abschnitt vorgestellten Anwendungsf lle und Anforderungen eine intuitiv zu bedienende und einfach gehaltene M glichkeit bieten beliebige textuelle Nachrichten untereinander auszutauschen Die Kommunikationsbeziehungen beschr nken sich dabei immer auf genau zwei Teilnehmer des Netzwerkes die miteinander in Kontakt treten m chten Es sind keinerlei Multicast Optionen oder C
134. tskonzep ten f r eine sehr hohe Vertraulichkeit und Datensicherheit innerhalb des Netzwerks sorgt Strukturell identifiziert GNUnet die einzelnen Teilnehmer des Netzwerks anhand von eindeu tigen 64 Byte langen Hashwerten die gleichzeitig als GN Unet Adressen interpretiert werden und f r den Datenaustausch unabk mmlich sind Diese Identifikation ist n tig um auf dem Public Key Prinzip gesicherte Datenkan le zwischen den einzelnen Teilnehmern aufzubauen Die Datentransfers werden innerhalb von GNUnet grunds tzlich symmetrisch verschl sselt so dass nur der designierte Empf nger die Informationen entschl sseln kann Um die Herkunft von Daten und deren Wege durch das Netzwerk zu verschleiern benutzt GNUnet innerhalb des Filesharing Moduls ein gesondertes GAP Routing siehe auch 7 Dieses Routingverfahren beinhaltet lokale Routing Tabellen bei den Teilnehmern da jeder Peer potenziel als Hop fungieren muss wenn er Anfragen erh lt und diese weiterleitet Au er dem schleust GN Unet ber das Filesharing Modul selbstst ndig Datenpakete in das Netzwerk um das allgemeine Kommunikationsaufkommen zu maskieren N heres zum Routingverfahren folgt in der Passage des Filesharing Moduls da das GAP Routing dort als fester Bestand teil eingebaut ist All diese Verfahren gew hrleisten dabei ein hohes Ma an Anonymit t und Datensicherheit ber ein potentiell unsicheres Basismedium Insgesamt ist die Struktur von GNUnet sehr modular gehalten was
135. und deswegen nicht extra abgebildet wurde Im Zusammenhang mit der folgenden Roadmap in Abschnitt H line UbiMuC 1 Einleitung wird auch noch auf urspr nglich geplante aber dann sp ter gestrichene Szenarien eingegangen und einige Hintergr nde f r die getroffenen Entscheidungen erl utert Videokonferenz Audio Video N810 Dateiaustausch N810 N810 Text Chat Quelle 2 N810 Streaming Audio Video Abbildung 1 1 UbiMuC Anwendungsf lle Zentrale Anwendungsf lle Die beiden anf nglich erw hnten Nutzungszenarien werden anhand der in Abbildung ge zeigten Videokonferenz exemplarisch dargestellt Der konzeptuelle Unterschied zwischen Text nachricht und Videostream ist aufgrund der analogen Struktur bei unterschiedlich zu inter pretierenden Daten zu vernachl ssigen 1 Camera Aufnahme Micro encodieren 2 Daten verpacken verschicken AV Transfer Ng10 1 Konferenzanfrage Best tigung 2 Parameteraushandlung N810 Aufl sung Codecs Bitraten Abbildung 1 2 Anwendungsfall der Audio Video Konferenz 1 2 Anwendungsf lle In Analogie zu einem Klingelton eines Mobiltelefons ist es vorgesehen dass eine Videokonfe renz einer vorherigen Autorisierung durch den UbiMuC Benutzer bedarf Die Optionsauswahl des Benutzers ist dabei auf die beiden Punkte Annehmen und Ablehnen beschr nkt Soll eine Konferenz aufgebaut werden initiiert ein Teilneh
136. unikation mit der WIR Schicht l uft ber einen TCP Socket ber den die zu sendenden bzw die empfangenen Daten als normale GN Unet Nachrichten aus der WIR Schicht nach GNUnet bzw in die entgegengesetzte Richtung trans portiert werden Auf der GN Unet Seite werden Handler registriert die die vorsortierten Nach richten entsprechend ihres Inhalts weiterverarbeiten 45 4 Design Da GNUnet selbst bereits beim Eingang der Daten den Typ ber ein Header Byte iden tifiziert und an die entsprechenden Handler Routinen weiterleitet erschien es uns sinnvoll keinen generischen UbiMuC Typ einzuf hren sondern gleich verschiedene Datentypen bzw deren Handler zu registrieren Da die eingehenden Daten ohnehin identifiziert werden sparen wir somit eine zus tzliche Identifizierungsfunktion und k nnen die Daten unmittelbar und typspezifisch verarbeiten Diese Handler werden beim Start von gnunetd f r die einzelnen Datentypen registriert und dann beim Eingang eines Pakets von GNUnet aufgerufen Die durch GetRoute Anfragen entstandenen Routen werden am Ausgangspunkt zwischen gespeichert und nach dem Ablauf von f nf Minuten nach dem letzten erfolgreichen Daten transfer gel scht Kommt aus der WIR Schicht ein zu versendendes Paket an wird zun chst berpr ft ob f r den Ziel Peer eine g ltige Route besteht Ist dies der Fall wird die Rou te den Daten vorangestellt und an den ersten Hop in der Route versendet Andernfalls wird ein
137. verwendeten oder angepassten Modulen von GNUnet befasst F r UbiMuC steht im Gesamtbild die Anpas sung der von GNUnet bereitgestellten und tats chlich ben tigten Funktionalit ten und deren Integration und Anpassung an die UbiMuC Anforderungen im Vordergrund Benutzer Anmeldung Die erstmalige Anmeldung an das GN Unet Netzwerk wird haupts chlich durch das Hostlisten Modul geleistet wie in Abschnitt 2 2 beschrieben wurde Der Austausch der HELLO Pakete wird in UbiMuC durch die Nutzung einer angepassten DHT Struktur realisiert Baut ein Peer eine Verbindung in das GN Unet Netzwerk auf sendet er gleichzeitig sein HELLO Paket an die modifizierte DHT und signalisiert damit seinen Onlinestatus Empf ngt ein Peer diese Daten aus der DHT kann er f r ein Zeitfenster von einigen Minuten sofern kein neues HELLO eintrifft annehmen dass der besagte Peer online und kommunikationsf hig ist Da HELLO Pakete einen Zeitstempel besitzen verfallen veraltete Pakete und k nnen nicht kontinuierlich benutzt werden Es ist also ein stetiges Auffrischen der HELLO Pakete zur Aufrechterhaltung von Kommunikationsm glichkeiten n tig 29 3 Transport und Kommunikation Datenaustausch zwischen Benutzern von UbiMuC Damit einzelne Peers gezielt Daten miteinander austauschen k nnen setzt UbiMuC auf den GNUnet internen Strukturen zum Versenden von Daten auf Allerdings wird dabei nicht das Filesharing Modul benutzt sondern werden vielmehr die unm
138. wei Teilnehmern zu starten m ssen einige Voraussetzungen er f llt werden So ist es zun chst notwendig dass beide online sind und sich derzeitig in keiner anderen Konferenz befinden Nun ist es problematisch wenn von einer Seite eine Konferenz initiiert wird und diese auf der Empfangsseite nicht abgelehnt werden kann so dass diese Kon ferenz bei Initiierung erzwungenerma en gestartet wird Daher ist ein Protokoll unumg nglich das dem Empf nger die beiden Auswahlm glichkeiten bietet diese Konferenz zu akzeptieren oder abzulehnen Dieses Protokoll kann zudem technische Abl ufe wie Einschalten des Mi krofons oder der Kamera zur Durchf hrung einer Konferenz ansto en Ein weiteres Problem existiert wenn ein Partner die Konferenz verl sst und der andere Teil nehmer weiterhin sendet Datenpakete fluten ungenutzt das Netzwerk und erreichen den Emp f nger ohne durch diesen verarbeitet zu werden Unter Umst nden kann dies zu einem Ab sturz des Empfangsclients f hren Zudem sollte eine Konferenz nur von ihren Teilnehmern beendet werden d rfen Deshalb ist neben dem Protokoll f r den Verbindungsaufbau ebenfalls ein Protokoll f r den Verbindungsabbau n tig Auch hier k nnen notwendige Vorg nge wie Abschalten der Kamera und des Mikrofons eingebunden werden All diese Funktionen m ssen beim Verbindungsaufbau bzw abbau gew hrleistet werden Im Folgenden sollen die hierzu bei UbiMuC zum Einsatz kommenden Konzepte n her beschrieben
139. wurden hier wie in Abbildung 4 7 schematisch dargestellt aufgebaut so dass jeder nur seinen Vorg nger sowie seinen Nachfolger erreichen kann Abbildung 4 8 Aufbau des Multihoptests mit f nf Ger ten Testprogramme Als erstes wurde ein Testprogramm geschrieben welches versucht eine Route aufzubauen um dann Nachrichten zu versenden Der Aufruf hierzu ist chat client peerid wobei peerid f r die Peeradresse des Chat Partners steht Nach dem Starten des Programms konnte man Nachrichten eintragen die beim Chat Partner dann auf der Konsole dargestellt wurden Dieses Programm diente nur dazu herauszufinden ob der Paketdienst es schafft eine Verbindung aufzubauen und ob er auch ber mehrere Hops routen kann 50 4 2 UbiMuC Transportschicht Um die Datenrate zu testen wurde ein Benchmarkprogramm geschrieben welches als Ser ver oder Client gestartet werden kann Der Aufruf des Benchmarkprogramms geschieht mit benchmark c s peerid wobei c oder s f r Client oder Server steht und peerid f r die Peeridentity des Empf ngers Das Testprogramm l sst als Server GN Unet eine Verbindung aufbauen und schickt dann dau erhaft Daten an den Client Auf dem Client wird die Uhrzeit des ersten empfangenen Paketes festgehalten und gemessen wie viele Daten ankommen So kann man nach dem Beenden des Tests ablesen wie viele Daten in welcher Zeit bertragen worden sind Abbildung 4 9 Testaufbau mit Konsolenverbindungen Um di
140. zen transportiert Aus den Erfahrungen der vorherigen Tests wurde die Audio bertragung direkt ausgeschaltet 78 W hrend der Testl ufe wurde eine deutliche berlastung der GUI festgestellt Die Bildqualit t hatte sich nochmal verschlechtert und der Hop in der Mitte reagierte auf jede Interaktion auf dem Ger t nur noch mit mehr als 5 Sekunden Verz gerung Das Ger t Nr 2 hatte sich aufgrund der berlastung nach 5 Minuten Laufzeit selbst neu gestartet Ergebnisse Der Chat funktionierte einwandfrei auch wenn die Ger te ber mehrere Hops miteinander kommunizieren mussten Die AV Konferenz funktionierte ordnungsgem jedoch war die Qua lit t nicht zufriedenstellend Die Anzahl der Hops hatte jedoch keinen Einfluss auf die Qualit t der bertragung Mehrere Konferenzen im Netz f hrten zu Doppelbelastungen bei den Ger ten und ergaben sehr hohe CPU Auslastungen die zu Instabilit ten f hrte 79 5 Evaluierung 80 6 Fazit Dieses Kapitel soll als kurze Zusammenfassung der vorhergehenden Kapitel dienen um einen kurzen berblick der Ergebnisse zu liefern Nach diesem berblick werden diese Resultate mit den anfangs beschriebenen Minimalzielen verglichen Abschlie end wird auch ein Ausblick gegeben bei dem aufgezeigt wird wo noch Potenziale zur Weiterentwicklung der Software bestehen 6 1 Projektzusammenfassung GNUnet UbiMuC setzt auf dem GNUnet Framework auf und benutzt dieses f r den eigenen Daten
141. zt sondern nur f r die Abstimmung eines symmetrischen Sitzungsschl ssels verwendet der dann f r die eigentliche Verschl sselung benutzt wird Durch eine periodisch angesto ene Weiterleitung von vorhandenen HELLO Paketen sorgt das Hostlisten Modul selbstst ndig f r eine Verbreitung der Teilnehmeradressen Diese Nachrich ten werden von allen verbundenen Peers zuf llig ins Netzwerk gesendet um anderen Peers von der eigenen Existenz zu berichten Auch werden empfangene HELLO Pakete von anderen Peers weitergeleitet Um eine Verbindung zu einem anderen Peer aufzubauen ist f r GN Unet daher das Vorhandensein eines besagten HELLO Pakets notwendig da sonst keine Abstim mung eines Sitzungsschl ssels stattfinden kann Das DHT Modul GNUnet besitzt eine verteilte Datenstruktur in Form einer verteilten Hashtabelle abgek rzt DHT Innerhalb dieser DHT k nnen Daten ber mehrere Peers hinweg bereitgestellt werden ohne dass eine zentralisierte Datenstruktur ben tigt wird Au erdem kann die DHT anhand von Verteilungs und Migrationsfunktionen daf r sorgen dass darin gespeicherte Inhalte dy namisch und nicht vorhersagbar unter den GNUnet Teilnehmern verbreitet werden GN Unet selbst bietet ber das DHT Modul eine Schnittstelle an die das Eintragen von Daten in die DHT sowie das sp tere Abfragen erlaubt Details zur DHT und den Schnittstellen werden in den Abschnitten B 1 3 1 und 4 3 1 2 gesondert behandelt Das Statistik Modul Zur s
142. zu speichern Dies erlaubt bei den vorhandenen 64 KB Speicherplatz in der DHT fast 1000 UbiMuC Nutzer was eine sehr gro e Netzgr e darstellt die so erst einmal nicht zu erwarten ist und entsprechend nicht zu Proble men f hren wird Au erdem sollten die PUT Nachrichten fter weitergeleitet werden so dass eine bessere Verteilung ber das Netzwerk gew hrleistet ist Hierf r wurde die entsprechende Konstante im GN Unet DHT Modul angepasst Ein weiteres Problem ist dass DHT Nachrichten normalerweise mit einer recht geringen Prio rit t vom GNUnet Dienst behandelt werden Dies f hrt dazu dass bei hoher System oder Netzwerklast DHT Nachrichten bevorzugt verworfen werden Entsprechend musste von un serer Projektgruppe die Priorit t der DHT Nachrichten derart erh ht werden dass sie von GNUnet nie verworfen werden Auch mit diesen nderungen ist die DHT keine sichere Datenstruktur da Nachrichten beim Transport noch verloren gehen k nnen Die Verl sslichkeit ist aber durch diese nderungen generell verbessert so dass die DHT f r die in Abschnitt 4 3 beschriebene Kontaktliste genutzt werden kann 3 1 3 2 Hostlisten Modul Die GNUnet interne Bekanntmachung von Peers verl uft ber HELLO Nachrichten Beim initialen Betritt zum GNUnet Netzwerk werden Hostlisten ausgetauscht die aus derartigen HELLO Nachrichten bestehen In unserem Fall wird das Finden der Peers ber den Abruf von Dienst Informationen ber Avahi siehe auch Absch
143. zu versenden Das hier benutzte Nachrichtenformat wird vom Pa ketdienst lediglich durch ein Text Typflag von anderen Datenarten wie beispielsweise den Multimediadaten des folgenden Abschnitts unterschieden 62 4 5 Multimedia 4 5 Multimedia Multimedia Funktionalit t bildet einen Kernpunkt des Projektes Dieser Abschnitt besch f tigt sich zun chst mit Konzepten und Spezifikationen Hier werden das genutzte Framework sowie genutzte Codecs und Protokolle vorgestellt Es folgen Implementierungsdetails einzelner Komponenten sowie besondere Eigenheiten und aufgetretene Probleme 4 5 1 Konzepte und Spezifikationen Vor der Implementierung mussten einige wesentliche Fragen gekl rt werden e Sollte ein integrierbares Programm oder ein Multimedia Framework verwendet werden e Welche Funktionen muss diese gew hlte Software unterst tzen e Welche Codecs und Protokolle sollten benutzt werden e Wie sollten bestimmte Konzepte wie Verbindungsaufbau und abbau umgesetzt werden Diese Fragen werden im Folgenden genauer untersucht und m gliche L sungen beschrieben 4 5 1 1 GStreamer Zur Nutzung von multimedialen Komponenten in UbiMuC war es notwendig ein geeigne tes integrierbares Programm oder Multimedia Framework zu finden Mit dem unter LGPL entwickelten GStreamer fand sich ein derartiges Framework welches nativ auf der Maemo Plattform des N810 unterst tzt wird GStreamer selbst verfolgt ein recht simples Konzept Dieses F
144. zugt gesendet und verarbeitet werden Inhaltlich stellt der Paketdienst dabei einfache Sende und Empfangsschnittstellen bereit die lediglich einen Datencontainer f r die Nutzdaten sowie eine Empfangs Adresse ben tigen Auf Anwendungsebene muss also nur ein passend typisierter Datencontainer erstellt werden der ber den Paketdienst zum Ziel transportiert wird Details wie Routenaufbau oder konkrete Behandlung der Nachrichtentypen etc sind auf An wendungsebene v llig unerheblich da dies durch den Paketdienst gekapselt wird Auswirkungen des Routings Mit Hilfe der eigens entwickelten GetRoute und GetRouteReply Methoden ist es m glich eine Verbindung zwischen zwei Teilnehmern an beliebigen Stellen des UbiMuC Netzwerkes aufzubauen Durch die automatische Weiterleitung von GetRoute ist au erdem sichergestellt dass alle momentan erreichbaren Peers benachrichtigt werden Ausnahmen stellen hier Szenarien dar in denen der Ziel Peer erst kurz nach der Bearbeitung einer GetRoute Anfrage dem Netzwerk beitritt und so in erster Instanz nicht ber cksichtigt werden kann Zum Zeitpunkt der Bearbeitung der Anfrage ist jedoch der Netzwerkzustand korrekt wiedergegeben worden da besagter Peer nicht online war Im Hinblick auf die m gliche Netzwerkgr e ist allerdings zu erw hnen dass das vorliegende Konzept der SourceRoute nicht f r gro e ausgedehnte Netze geeignet ist Mit zunehmender Pfadl nge steigt zum einen die

Endbericht - Lehrstuhl 12

Contents

Download Pdf Manuals

Related Search

Related Contents