Studienarbeit - Universität Passau

Technische Universität München
Fachgebiet
Verteilte Multimodale Informationsverarbeitung
Prof. Dr. Matthias Kranz
Studienarbeit
Benutzerlokalisierung und Statusabfragen für
Intelligentes Wohnen in Zusammenarbeit mit Skype
Autor:
Simon Koros
Matrikelnummer: —
Anschrift:
—
—
Betreuer:
Dipl.-Ing. Luis Roalter
Beginn:
2010-05-24
Abgabe:
2010-11-24
Kurzfassung
In der nachfolgenden Arbeit werden die Grundlagen, Möglichkeiten und Ergebnisse der
Benutzerlokalisierung und Statusabfragen im Rahmen des Forschungsgebiets Intelligentes
Wohnen mit Schwerpunkt auf die cross-plattform VoIP Anwendung Skype behandelt.
Ziel ist es akkurate und aktuelle Informationen unabhängig vom Aufenthaltsort oder Lage
eines Teilnehmers in ein bestehendes System zu integrieren und für weitere Anwendungen,
wie Location-Based-Services, als Dienste zur Verfügung zu stellen.
Um einen Teilnehmer zu lokalisieren und gezielt dessen Status-Informationen abzufragen,
werden Informationen vom clientseitigen Betriebssystem und ggf. weiteren peripheren
Systemen gesammelt und von einem zentralen Server-System aufbereitet. Dafür wurde im
Zuge dieser Arbeit die verfügbare Skype API analysiert und der Ap2Ap-Kanal von Skype
verwendet, welcher die gesicherte Datenübertragung via Skype ermöglicht.
Ferner wurde die Middleware Sky2ROS entwickelt, welche in Form einer Server- und einer
Client-Applikation über Skype verbunden ist und ohne Interaktion durch den Teilnehmer
kommuniziert. Diese wurde in der Skriptsprache Python geschrieben und kann über die
von Arkadiusz Wahlig bereitgestellten Skype4Py Bibliotheken mit Skype interagieren.
Zur anschließenden Verarbeitung und Integration in das bestehende System, wird auf einer Unix Server-Plattform das Open-Source Robot-Operating-System (ROS) verwendet,
welches die übertragenen Daten ausliest und als Services bzw. Topics bereitstellt.
2
Inhaltsverzeichnis
Inhaltsverzeichnis
3
1 Einleitung
1.1 Motivation und Ziel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Intelligentes Wohnen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Überblick und Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
5
6
6
2 Benutzerlokalisierung
2.1 Technische Realisierungen . . . . . . . . . . . .
2.1.1 Globales-Positionierungs-System . . . . .
2.1.2 Funkzellen- und Accesspoint-Ortung . .
2.2 Geotargeting-Verfahren . . . . . . . . . . . . . .
2.2.1 Internet Protokoll IPv4 . . . . . . . . . .
2.2.2 Positionsbestimmung . . . . . . . . . . .
2.2.3 Testergebnisse der IPInfoDB Datenbank
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8
8
8
9
11
11
13
14
3 Einführung und Analyse der Skype API
3.1 Über Skype . . . . . . . . . . . . . . . .
3.1.1 Einführung in Skype . . . . . . .
3.1.2 Aspekte des Einsatzes von Skype
3.2 Analyse der Skype API . . . . . . . . . .
3.2.1 Aufbau und Konzept . . . . . . .
3.2.2 Befehls-Protokoll-Ebene . . . . .
3.2.3 Datenübertragung mittels Ap2Ap
3.2.4 Vergleich der API Wrapper . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
15
15
15
16
18
18
18
21
22
.
.
.
.
.
.
.
.
24
24
25
26
26
29
32
34
37
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4 Entwicklung und Interaktion mit Sky2ROS
4.1 Einführung in ROS . . . . . . . . . . . . . . . .
4.2 ROS Kommunikations-Prozesse . . . . . . . . .
4.3 Entwicklung und Funktionsweise von Sky2ROS
4.3.1 Aufbau und Konzept . . . . . . . . . . .
4.3.2 Skype-Abfrage mit Ap2Ap . . . . . . . .
4.3.3 XML-Abfrage und Parsing . . . . . . . .
4.3.4 Publishing in ROS . . . . . . . . . . . .
4.3.5 Use-Cases . . . . . . . . . . . . . . . . .
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
INHALTSVERZEICHNIS
5 Problembehandlung und Historie
5.1 Skype API Bibliotheken . . . . . . . . . . .
5.2 Zeichenkodierung . . . . . . . . . . . . . . .
5.3 Testergebnisse, Performance und Ressourcen
5.4 Lösung des Deadlock-Problems . . . . . . .
4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
39
39
40
41
43
6 Zusammenfassung und Ausblick
44
A Gesprächs-Protokoll
46
Abbildungsverzeichnis
47
Tabellenverzeichnis
48
Literaturverzeichnis
49
Kapitel 1
Einleitung
1.1 Motivation und Ziel
Diese Arbeit konzentriert sich auf die Kommunikation zwischen externen Teilnehmern und
einem zentralen Server über IP-basierte Dienste. Dabei liegt der Schwerpunkt auf der
populären Voice-Over-IP Anwendung Skype, welche sich für den praktischen Einsatz aufgrund der weltweiten Verbreitung auf Personal Computers, mobilen Endgeräten sowie internetfähigen Multimedia-Geräten, gut eignet.
Ziel ist es, verfügbare und sicherheitsrelevante Informationen eines Benutzers aus der Ferne
zu erfassen oder mittels geeigneter Verfahren wie in Kapitel 2 beschrieben zu ermitteln.
Verfügbare Informationen beinhalten unter anderem:
• Mood – Festgelegte Text-Meldung durch den Benutzer
• Status – Erreichbarkeit manuell oder cognitiv bestimmt
• Personalien – Optionale Informationen zur Person
Sicherheitsrelevante Informationen, welche aus der Ferne nicht verfügbar, oder dem Benutzer nicht unmittelbar bekannt sind, müssen entsprechend ermittelt werden:
• IP-Adresse/Port – Abfrage des Accesspoints
• Standort – Lokalisierungsverfahren
Die gesammelten Informationen sollen mit Hilfe der entwickelten Middleware Sky2ROS
über das Skype-Netzwerk gesichert übertragen werden und anschließend in einem zentralen
Server zur weiteren Verwendung aufbereitet werden. Somit können diese auch weiteren
Diensten wie z.B. für Location-Based-Services (LBS) zur Verfügung gestellt werden. LBS
sind nach Zhang u. a. [14] ortsabhängige Dienste für mobile Anwendungen, welche sich in
die Kategorien Information, Unterhaltung, Not- und Werbe-Dienste aufteilen lassen.
5
Kapitel 1 Einleitung
6
1.2 Intelligentes Wohnen
Intelligentes Wohnen respektive Ambient Assisted Living bezeichnet ein breitgefächertes Forschungsgebiet, welches nach Kumar [7] eine Integration elektrischer Geräte
aller Art, in einer automatisierten und vernetzten Umgebung für den alltäglichen Gebrauch
zum Ziel hat.
Diese müssen den Anforderungen an eine intelligente Umgebung gerecht werden:
• Eingebettet: Vernetzte Geräte integriert in der Umgebung
• Kontext bewusst: Fähigkeit Person im Kontext zu seiner Situation zu erkennen
• Personalisiert: Anpassbar an individuelle Bedürfnisse
• Adaptiv: Vollständig an den Benutzer anpassbar
• Antizipativ: Fähigkeit Bedürfnisse vorherzusehen
1.3 Überblick und Aufbau
Der erste Teil dieser Arbeit erörtert die unterschiedlichen Möglichkeiten zur Benutzerlokalisierung und geht dabei gezielt auf das Geotargeting-Verfahren ein, welches Bestandteil
der entwickelten Applikation Sky2ROS ist.
Im zweiten Teil wird die Voice-Over-IP Anwendung Skype vorgestellt, welche sich innerhalb
der letzten Dekade zu einem der populärsten VoIP Clienten weltweit entwickelt hat. In
diesem Zusammenhang liegt der Schwerpunkt aber nicht auf der auditiven oder visuellen
Kommunikation sondern auf der, für den Benutzer unsichtbaren, Datenabfrage über einen
zentralen Server, welche mittels der Skype API realisiert wurde.
Kapitel 1 Einleitung
7
Dafür wurde der Aufbau und die Funktionsweise der Skype API analysiert und geeignete
Methoden für die Datenübertragung bestimmt.
Im dritten Teil wird die Funktionsweise und der Einsatz des Robot-Operating-System
(ROS) sowie Aufbau und Entwicklung der Applikation Sky2ROS erläutert. Diese wurde
im praktischen Teil dieser Arbeit in der Skriptsprache Python entwickelt und mit Hilfe
verfügbarer Python Bibliotheken der Skype API zugänglich gemacht.
Im letzten Abschnitt werden Problemfälle erörtert, welche während der Entwicklung gelöst
wurden, sowie Schwachstellen und Potentiale der Anwendung anhand protokollierter Testergebnisse untersucht. Anschließend werden in einer Zusammenfassung die wichtigsten
Punkte der behandelten Thematiken zusammengefasst und ein Ausblick auf eine zukünftige
Entwicklung gegeben.
Kapitel 2
Benutzerlokalisierung
2.1 Technische Realisierungen
Sinn und Zweck der Benutzerlokalisierung ist es, zu jeder Zeit den Aufenthaltsort einer
Person über ein mitgeführtes Gerät, welches sich in unmittelbarer Nähe befindet, mit und
ohne Kenntnis des Benutzers möglichst genau zu bestimmen.
Prinzipiell gibt es drei gebräuchliche Ansätze zur Benutzerlokalisierung mit unterschiedlichen Genauigkeiten:
• Das Satellitengestützte Globale-Positionierungs-System: 100 − 101 Meter
• Lokalisierung des Mobilfunkgeräts oder Accesspoints: 101 − 102 Meter
• Lokalisierung der IP-Adresse mittels Geotargeting-Verfahren: 103 Meter
2.1.1 Globales-Positionierungs-System
Die genaueste Ortsbestimmung lässt sich über das Globale-Positionierungs-System (GPS)
nach Köhne u. Wößner [6] bestimmen. Dabei ist die Auflösung der momentan frei verwendbaren GPS Satelliten durch deren Betreiber (Vereinigte Staaten von Amerika) auf ca.
1-10 Meter Genauigkeit begrenzt. Technisch möglich ist abhängig von Empfang und Güte
des GPS Chipsatzes eine Zentimeter genaue Ortsbestimmung. Das Prinzip der Lokalisierung mittels GPS basiert auf der Laufzeitmessung zwischen einem GPS-Gerät (Empfänger)
und mehreren Satelliten (Sendern).
Die Satelliten senden laufend ein Zeitsignal, welches nach Köhne u. Wößner [6] mit einer
Datenrate von 50 Bit/Sekunde und einer Periode von 30 Sekunden parallel mittels SpreadSpectrum Verfahren auf zwei Frequenzen ausgesendet wird. Das GPS-Gerät empfängt die
unterschiedlichen Zeitsignale und errechnet die Distanz zu den Satelliten durch Messung
der Laufzeit des Signals – genauer gesagt durch Vergleich der Uhrzeiten.
8
Kapitel 2 Benutzerlokalisierung
9
Theoretisch würde der Schnittpunkt der Kreisbahnen von drei Satelliten ausreichen um
die Position zu bestimmen, wie in Abbildung 2.1 gezeigt. Allerdings verfügen die GPSGeräte nicht über die zeitliche Genauigkeit, sodass die korrekte Position interpoliert werden
muss. Im praktischen Einsatz werden oftmals vier oder mehr Satelliten benötigt um eine
zuverlässige Positionsbestimmung zu erhalten.
Abbildung 2.1: Positionsermittlung durch Schnittpunkt aus drei bekannten Entfernungen
nach Köhne u. Wößner [6]. Dabei ergeben sich die Punkte B aufgrund von
Ungenauigkeiten der Uhr im GPS-Empfänger. Diese werden zwischen den
Punkten B interpoliert bis sich Punkt A als korrekte Position ergibt.
2.1.2 Funkzellen- und Accesspoint-Ortung
Die Ortung eines Mobilfunktelefons ist technisch gesehen durch Bestimmung der eingewählten Funkzelle und im genaueren Bereich durch Abstandsmessung zwischen benachbarten Zell-Stationen problemlos möglich. In der Praxis ist dies aber nur in Zustimmung
mit dem Eigentümer der SIM-Karte (Subscriber Identity Module) oder auf juristischem
Wege möglich und wird daher nur in Notfällen oder ähnlichen angewandt. Verfügt das
Mobilfunkgerät über keinen GPS-Chipsatz, wird für eine genauere Bestimmung mit folgenden Verfahren gearbeitet, welche analog zum GPS auf der Abstandsbestimmung durch
Messung der Signallaufzeiten beruhen:
• Timing Advance nach Wang u. a. [13]: Bei diesem Verfahren wird die Position
über den Abstand zur Funkzelle anhand des Zeitversatzes zwischen gesendeten und
empfangenen Daten ermittelt.
Kapitel 2 Benutzerlokalisierung
10
• Uplink Time Difference of Arrival nach Lopes u. a. [8]: Bei diesem Verfahren
wird die Position anhand der Laufzeiten der Signale des Endgerätes zu sogenannten
Location-Measurement-Units ermittelt, welche an der Funkzelle nachgerüstet werden
müssen.
• Enhanced Observed Time Difference nach Jonsson u. Olavesen [5]: Hier werden
Signale gemessen, welche nicht GSM bzw. UMTS typisch sind und vom Mobilfunkgerät zusätzlich zu den üblichen Kanälen unterstützt werden müssen.
Abbidung 2.2 zeigt eine Vorschau von Google Maps Mobile Version 5, welche im Dezember 2010 auf der Dive into Mobile Konferenz vorgestellt wurde und die Ortung via GPS
und Funkzelle vereint. Somit kann auch bei schwachem oder fehlendem GPS-Signal der
Standort in abgeschätzter Genauigkeit bestimmt werden.
Abbildung 2.2: Der Screenshot nach Mills [9] von Google Maps Mobile 5 zeigt eine Positionsermittlung auf Basis von Funkzellenortung und gibt die erzielte Genauigkeit an.
Eine dritte Möglichkeit ist die Wireless Accesspoint Localization, welche vor allem im
Innen-Bereich immer mehr Anwendung findest, wo oft schwache bis keine Signal-Stärken
von Mobilfunk-Zellen oder Satelliten herrschen. Begünstigt durch die zunehmend entwickelte Infrastruktur privater und öffentlicher Gebäude mit drahtlosen Zugangspunkten,
bedarf es lediglich geeigneter Algorithmen zur Positionsbestimmung eines verbundenen
Teilnehmers. Ein Algorithmus nach Wan [12] analysiert die eindeutigen Fingerprints der
verschiedenen Accesspoints eines WLAN Netzes und bestimmt mit Kombination der unterschiedlichen Fingerprints die Position des Teilnehmers im Bezug zu den installierten
Accesspoints.
Kapitel 2 Benutzerlokalisierung
11
2.2 Geotargeting-Verfahren
In dieser Arbeit ist die IP-basierte Lokalisierung von besonderem Interesse, da diese von
jedem internetfähigen Gerät aus ohne zusätzliche Ausstattung bestimmt werden kann. Im
Gegensatz zu den vorgestellten Möglichkeiten mittels GPS oder GSM ist die Genauigkeit
des Geotargeting-Verfahrens sehr gering und weist, wie in Kapitel 2.2.3 gemessen, eine
hohe Varianz auf. Weitere Voraussetzungen sind eine akkurate Datenbank sowie keine
absichtlichen Verzerrungen durch Virtual-Private-Networks (VPN) oder Proxy-Netze.
Bei dieser Art der Lokalisierung gibt es prinzipiell zwei Verfahren: Zum einem können
bekannte Accesspoints direkt identifiziert und mit Hilfe von AP-Datenbanken lokalisiert
werden. Dafür kann auf die Dienste von bspw. Skyhook oder der Wireless-GeographicLogging-Engine (WiGLE) zurückgegriffen werden, welche Datenbanken weltweiter Accesspoints bereit halten. Alternativ kann auch ohne Wissen über den Accesspoint, lediglich
anhand der IP-Adresse der Standort, des zum Endgerät verbundenen Zugangspunkts lokalisiert werden. Da dieses Verfahren bereits länger etabliert ist und unterschiedliche Datenbanken frei zur Verfügung stehen, wurde diese Variante in Sky2ROS implementiert. Die
Funktionsweise wird in Kapitel 4.3.3 näher erläutert.
2.2.1 Internet Protokoll IPv4
Jeder Internet-Teilnehmer hat eine eineindeutige IP-Adresse. Momentan ist die 4. Version
IPv4 etabliert, welche eine 32 Bit Adresse in vier Blöcken zu je 8 Bit vorsieht.
Die Größenordnung und Verteilung von IP-Adressen weltweit veranschaulicht IPligence [4]
mit Grafik 2.3. Daraus wird schnell ersichtlich, dass die vollständige Erfassung aller IP
Adressen in einem beschränkten Zeitraum mit der aktuellen Technologie nicht möglich ist.
Abbildung 2.3: Verteilung in 2007 erfasster IP-Adressen weltweit nach IPligence [4].
Kapitel 2 Benutzerlokalisierung
12
Zahlreiche Netze untergliedern sich in weitere Subnetze. Abbildung 2.4 zeigt ein Beispiel
einer möglichen Netz-Hierarchie mit verschiedenen Knoten (Teilnehmer) mit inkrementeller
Adress-Zuordnung.
Abbildung 2.4: Untergliederung der Netz-Knoten in Subnetze.
Damit soll deutlich werden, dass größere Addressräume wie bspw. das wissenschaftliche
Leibnitz-Rechen-Zentrum München (LRZ) existieren, welche eine Vielzahl von Knoten
vereinen. Diese Knoten teilen sich gemäß dem Geotargeting-Verfahren denselben Standort
des LRZ Servers in Garching.
Daraus wird schnell ersichtlich, dass die Präzision beim Geotargeting stark variiert und sich
kaum bestimmen lässt. Dennoch stellt Geotargeting ein einfaches und schnelles Verfahren
mit sehr niedrigem Aufwand dar, welches für eine erste Abschätzung ausreicht und sich
auch mit anderen Lokalisierungs-Verfahren gut kombinieren lässt.
Kapitel 2 Benutzerlokalisierung
13
2.2.2 Positionsbestimmung
Über verschiedene kommerzielle und freie Datenbanken, können die Werte von IP-Adressen
regionalen Standorten nach Ländern, Bundesländern und Städten zugeordnet werden. Diese Datenbanken müssen empirisch aufgebaut und aktualisiert werden. Die limitierenden Faktoren sind die Vollständigkeit und die Genauigkeit der Daten, sowie die Leistungsfähigkeit der Server und dem notwendigen Aufwand zur Pflege.
Die unternommenen Anstrengungen werden aber zunehmend größer, da große InternetUnternehmen wie Google gezielt kommerzielle Vermarktung mittels online Dienste wie
Google AdWords anbietet, indem Werbung auch nach regionalen Kriterien gezielt geschaltet werden kann.
Für diese Arbeit wurde die frei verfügbare IP Location API von IPInfoDB verwendet. Der
Anbieter stellt auf seiner Website Abfrage APIs zur Verfügung, welche über ein HTMLFormular oder durch Übergabe der IP-Adresse in der URL angefordert werden können.
Wird auf diese Weise eine Anfrage übermittelt, fragt ein quelloffenes PHP-Skript die
MySQL Datenbank des Anbieters ab, welche Informationen über zugehörige Länder, Städte
und Zeitzonen gespeichert hat. Die APIs sowie eine regelmäßig aktualisierte MySQL Datenbank stehen in den Sprachen Javascript, Ruby, ASP, Python und PHP frei zur Verfügung.
Um nun eine IP-Adresse den Geoinformationen der Datenbank zuzuordnen, wird diese
mit der folgenden Formel in eine ganzzahlige Dezimalzahl konvertiert. Angenommen die
IP-Adresse setzt sich aus A.B.C.D zusammen. Die Formel lautet dann:
IP = ((A · 256 + B) · 256 + C) · 256 + D.
Für die IP 74.125.45.100 (Google.com) ergibt sich damit zum Beispiel folgender Wert:
IP = ((74 · 256 + 125) · 256 + 45) · 256 + 100 = 1249717604.
Die resultierende Antwort der Abfrage würde wie folgt aussehen:
1249717604kU SkU nitedStatesk06kCalif orniakM ountainV iewk94043k37.4192.
Dieser Standort entspricht einem Google Server in Mountain View, Kalifornien.
Kapitel 2 Benutzerlokalisierung
14
2.2.3 Testergebnisse der IPInfoDB Datenbank
Um die Genauigkeit und die Varianz der Ergebnisse des Geotargeting-Verfahrens abzuschätzen, wurden verschiedene Abfragen der IPinfoDB Datenbank durchgeführt. Dabei
wurden von unterschiedlichen Standorten aus diverse Zugänge getestet und die resultierende Abweichung der Entfernung zum tatsächlichen Standort in Luftlinie berechnet.
Hard- oder Software Parameter haben auf die Ergebnisse keinen Einfluss und werden daher
nicht explizit erwähnt. Anzumerken ist, dass die Dauer einer Abfrage im Mikro-Sekunden
Bereich liegt.
TestNummer
#1
#2
#3
#4
Tatsächlicher Ort
Lokalisierter Ort
Accesspoint
Dez. Koordinaten
IP-Adresse
Host-Adresse
München/Sendling
Deutschland/München
Arcor DSL Anschluss
N 48.7 E 13.4667
188.104.102.190
188.104.102.190
München/Sendling
Deutschland/Garching
VPN-Verbindung über LRZ
N 48.25 E 11.65
129.187.173.194
h194.tum.vpn.lrz.de
München/Maxvorstadt
Deutschland/München
TU München LAN
N 48.15 E 11.5833
138.246.2.180
host180-2.natpool.mwn.de
München/Maxvorstadt
Deutschland/Garching
VPN-Verbindung über LRZ
N 48.25 E 11.65
129.187.173.42
h042.tum.vpn.lrz.de
EntfernungsAbweichung
157, 43 · 103 m
17, 66 · 103 m
1, 1 · 103 m
12, 82 · 103 m
Tabelle 2.1: Testergebnisse.
In diesem Testlauf wurde bei Test Nummer 1 fälschlicherweise der Ort München im niederbayerischen Landkreis Passau ermittelt, vermutlich aufgrund fehlender weiterer Differenzierung, womit sich eine Abweichung von über 150 Kilometern ergab. Dafür ergab Test
Nummer 3 eine Abweichung von lediglich einem Kilometer.
Daraus werden zwei Hauptmerkmale des Geotargeting deutlich: Zum einen zeigt die
Übereinstimmung von IP-Adresse und Host ob es sich um einen einzelnen oder einen
größeren Anschluss handelt, wie dies beim VPN-Zugang über das öffentliche LeibnizRechenzentrum der Fall ist. Zum anderen ist die Varianz der Entfernungs-Abweichung
schon bei einer sehr geringen Anzahl von Tests sehr hoch. Trotz der hohen Varianz und
der Ungewissheit über die Genauigkeit der Ergebnisse, kommt dem Geotargeting aufgrund
der schnellen Auswertung und des geringen Aufwands an Hardware und Software für eine
erste Einschätzung eine große praktische Bedeutung zu.
Kapitel 3
Einführung und Analyse der Skype API
3.1 Über Skype
3.1.1 Einführung in Skype
Skype ist eine etablierte Voice-Over-IP Anwendung, welche es verschiedenen Anwendern
ermöglicht über kostenlose Sprach- und Videoanrufe oder Instant-Messaging zu kommunizieren, sowie weitere Datenpakete zu übertragen. Ferner können auch kostenpflichtige
Sprach- und Videoanrufe in das weltweite Fest- und Mobilnetz getätigt werden, welche für
diese Arbeit allerdings nicht von Interesse sind.
Im Jahr 2003 gründeten nach Skype [11] die schwedischen Unternehmer Niklas Zennström
und Janus Friis das Unternehmen Skype und ließen das gleichnamige Programm unter der
Leitung der estländischen Entwickler Ahti Heinla, Priit Kasesalu und Jaan Tallinn entwerfen. Diese schrieben als erste Skype-Core-Entwickler den, bis heute nicht offengelegten
Quellcode.
Skype verwendet eigene proprietäre Protokolle sowie hochqualitative Audio- und Videocodecs, welche die dezentrale Kommunikation zwischen den Clients ohne einen speziellen
Server ermöglichen. Daher rührt angeblich auch der Name Skype von Sky Peer-to-Peer.
Zusätzlich gibt es eine zentrale Datenbank welche alle registrierten Skype-Benutzer enthält,
die Zugriff auf die kostenlosen und kostenpflichtigen Dienste von Skype haben.
Skype ist auf vielen gängigen Plattformen und Betriebssystem wie Microsoft Windows,
Mac OS, Linux sowie für Mobilfunkgeräte unter Windows Mobile, Android, Symbian, iOS
etc. verfügbar und zählt laut eigenen Angaben mehr als 20 Millionen registrierte Benutzer.
Das Programm wird in regelmäßigen Zyklen gewartet bzw. weiterentwickelt und ist auf
einer zunehmenden Anzahl an Endgeräten verfügbar. Zu den neusten Entwicklung zählt
neben einer mobilen Version von Skype für Smartphones auch eine embedded Version auf
aktuellen Televisionsgeräten von Samsung Technologies.
15
Kapitel 3 Einführung und Analyse der Skype API
16
3.1.2 Aspekte des Einsatzes von Skype
Für die technische Entwicklung mit Skype ergeben sich einige Vor- und Nachteile, von
denen die entscheidenden Aspekte im folgenden Abschnitt kurz erläutert werden sollen.
Der Hauptkritikpunkt an Skype ist die Ablehnung der Hersteller zur Offenlegung des
Quellcodes sowie der verwendeten Protokolle und Codecs. Dies war lange Zeit Gründe
für Großunternehmen wie der Siemens AG auf den Einsatz und das Einsparpotential aus
Sicherheitsgründen gänzlich zu verzichten. Erst durch die starke Verbreitung und die
fortgeschrittene technische Ausgereiftheit wurde Skype wegen seiner Kostenfreiheit und
dominierender Übertragungsqualität sowie Kompatibilität, von Privatanwender und Unternehmen gleichermaßen genutzt.
Der proprietäre Quellcode und die darauf beanspruchten Urheberrechte machen eine Weiterentwicklung bzw. Modifikation von Skype für die Öffentlichkeit oder für eigene Zwecke
prinzipiell unmöglich. Auch die starke Popularisierung der Open-Source Bewegung machen
proprietäre Programme aus technischer und ethnischer Sicht bei Anwendern und Entwicklern unbeliebter.
Aus diesem Grund ist die, im folgenden Kapitel 3.2 vorgestellte Skype API, die einzige
Möglichkeit auf die Funktionen von Skype zuzugreifen und für die eigenen Zwecke anzupassen. Für extern entwickelte Skype-Plugins gab es zu einem früheren Zeitpunkt einen
offiziellen Markt, welcher aber wieder von Skype geschlossen wurde. Dies sind die Hauptgründe welche aus Entwicklersicht gegen den Einsatz von Skype sprechen.
Auf der anderen Seite bestehen folgende entscheidende Vorteile, welche nach Cao u. a. [3]
für die Verwendung von Skype als Middleware sprechen:
• Alle End-to-End Datenströme sind durch eigene Verschlüsselungs-Algorithmen
gesichert sowie jeder User mit einem eindeutigen digitalen Zertifikat versehen.
• Skype ist in der Lage problemlos Network-Address-Translation (NAT) und
Firewalls zu passieren.
• Skype routet die Datenströme intelligent und dynamisch um geringe Latenzzeiten
zu erreichen. Auch während einer aktiven Verbindung kann neu geroutet werden.
• Skype stellt seine Entwicklungs API frei zur Verfügung, die es jedem erlaubt Plugins zu entwickeln, die auf alle Funktionen Zugriff haben.
Aufgrund des fortgeschrittenen Reifegrades und der professionell betriebene Entwicklung,
ist Skype zu einem der qualitativ hochwertigsten kostenlosen VoIP Programmen herangereift. Zudem ist Skype die weit verbreiteste Software seiner Art und ist damit für den
breiten Einsatz in vielen Anwendungsgebieten für unterschiedliche Zielgruppen gut geeignet.
Kapitel 3 Einführung und Analyse der Skype API
17
Abbildung 3.1 zeigt eine Einschätzung der Brockmann & Company Analyse- und Unternehmensberatung aus Boston über die Entwicklung der Benutzerzahlen von 2007 bis 2010.
Abbildung 3.1: Abschätzung der Skype User Entwicklung von 2007 bis 2010 nach Brockmann&Company [2].
Dank der rasant wachsenden Entwicklung und der genannten technischen Vorteile ist
Skype für den Einsatz im Anwender Bereich multimodaler Informationssysteme besonders geeignet. Die verwendeten Routing-Algorithmen ermöglichen eine IP-gestützte
Paketübertragung ohne, dass zusätzliche Anwendungen entwickelt und verteilt werden
müssen.
Dies hat einen großen Vorteil, da sich neue Anwendungen am Consumer-Markt meist nur
langsam etablieren und bei mangelnder Distribution oft unter Versions-Konflikten leiden.
Somit ist Skype als ausgereifte, leicht verfügbare und etablierte Anwendung die optimale
Grundlage für die Zwecke dieser Arbeit.
Kapitel 3 Einführung und Analyse der Skype API
18
3.2 Analyse der Skype API
3.2.1 Aufbau und Konzept
Die Skype API wird direkt vom Hersteller herausgegeben und ist unter der Entwickler
Rubrik der Website frei einsehbar. Prinzipiell gibt es zwei Ebenen auf denen externe
Programme mit Skype kommunizieren:
• Die Befehls-Protokoll-Ebene ist ein text-basierter Sprach Paradigma, auf dessen Grundlage eine externe Anwendung mit Skype kommunizieren kann, nachdem
ein Kommunikationskanal auf der Kommunikations-Ebene hergestellt wurde. Diese
Sprache ist plattformunabhängig und enthält alle Befehle, welche Skype bereithält.
• Die Kommunikations-Ebene ist eine Sammlung von Objekten für externe Anwendungen um eine Verbindung mit dem Skype Client herzustellen und mit diesem
zu kommunizieren. Diese baut auf der Befehls-Protokoll-Ebene auf und ist Plattform abhängig, d.h. sie unterscheidet sich in der Implementierung auf verschiedenen
Betriebssystemen.
Die zugrunde liegende Befehls-Protokoll-Ebene basiert auf asynchronen Sprach-Befehlen,
welche mit Skype ausgetauscht werden und für alle Betriebssysteme gleich sind. Die darauf aufbauende Kommunikations-Ebene besteht aus einem sogenannter Wrapper, der
in verschiedenen Sprachen die Skype API als Objekte mit Eigenschaften und Methoden
implementiert. Dies erlaubt die Bedienung aller Funktionen auf höherer Ebene in Form
diverser Bibliotheken, welche im Abschnitt 3.2.4 vorgestellt werden.
3.2.2 Befehls-Protokoll-Ebene
Im folgenden Abschnitt wird die Befehls-Protkoll-Ebene anschaulich erläutert, auf welcher
später die Skype API Wrapper aus Kapitel 3.2.4 basieren. Die Kommunikation auf dieser
Ebene findet stets sequentiell statt. Das bedeutet, dass ein neuer Befehl erst gesendet wird,
wenn die Antwort des vorherigen vorliegt.
Die allgemeine Befehls-Syntax ist folgendermaßen aufgebaut:
<BEFEHL>[*<Argument>][<BEFEHL>][<Argument>]
Die Antwort von Skype besteht, abhängig vom gesendeten Befehl, aus optionalen Parametern zur Bestätigung in folgender Form:
[<BEFEHL ANTWORT>][*<Argument>][<BEFEHL>][<Argument>]
Kapitel 3 Einführung und Analyse der Skype API
19
Ein einfacher Befehl auf Befehls-Protokoll-Ebene lautet zum Beispiel:
GET USER echo123 ONLINESTATUS
Dieser Befehl liest die angegebene Eigenschaft eines Users aus der Skype Datenbank aus.
Die Antwort von Skype besteht aus dem gesendeten Befehl und einem Rückgabewert. Die
Antwort bezieht sich damit direkt auf den zuvor gesendet Befehl:
USER echo123 ONLINESTATUS ONLINE
Die häufigsten Befehlsarten sind in Tabelle 3.1 mit Syntax und Beispiel aufgeführt.
Befehl /
Beispiel
Einzelbefehl
<BEFEHL>
MINIMIZE
Falscher Befehl <KEIN BEFEHL>
ASDF
GET-Befehl
GET <VARIABLE>
GET USERSTATUS
SET-Befehl
SET <OBJEKT><ID>
<PARAMETER><WERT>
SET SMS 123 BODY Hallo!
ALTER- Befehl ALTER <OBJEKT><ID>
<PARAMETER>
ALTER SMS 123 SEND
Antwort /
Beispiel
<ANTWORT>
WINDOWSTATE MINIMIZED
ERROR <NUMMER><MELDUNG>
ERROR 2 Unknown command
<VARIABLE><ANTWORT>
USERSTATUS ONLINE
<OBJEKT><ID>
<PARAMETER><WERT>
SMS 123 BODY Hallo!
ALTER <OBJEKT><ID>
<PARAMETER>
ALTER SMS 123 SEND
Tabelle 3.1: Skype API Syntax Tabelle
Bei längeren Befehlsketten wie z.B. einem Sprachanruf findet die Kommunikation asynchron statt d.h. es folgen auf einem Befehl mehrere Antworten von Skype. Ein kurzes
Beispiel soll den Ablauf einer typischen Befehlskette auf Befehls-Protokoll-Ebene veranschaulichen.
Kapitel 3 Einführung und Analyse der Skype API
20
In diesem vereinfachten Beispiel wird ein Sprachanruf zum Konfigurations-account Echo123
getätigt und nach erfolgreicher Verbindung wieder beendet. Die eingerückten Codeblöcke
sind die Befehls-Antworten, welche von Skype empfangen wurden.
// Audio - Verbindung mit dem Skype User echo123
-> CALL echo123
// Anruf mit der ID 14662 ist eingegangen
<- CALL 14662 STATUS UNPLACED
// Anruf wird zum Ziel - User durchgestellt
<- CALL 14662 STATUS ROUTING
// Verbindung hergestellt
<- CALL 14662 STATUS RINGING
// Ziel - User antwortet
<- CALL 14662 STATUS INPROGRESS
//
<<<-
Bestehende
CALL 14662
CALL 14662
CALL 14662
Verbindung
DURATION 1
DURATION 2
DURATION 3
// Verbindung abgebaut
<- CALL 14662 STATUS FINISHED
Quellcode 3.1: Aufzeichnung des Befehls-Protokoll bei einem Sprachanruf.
Im Anhang A befindet sich das vollständige Protokoll, welches mit dem Programm
Tracer.exe durchgeführt und aufgezeichnet wurde.
Kapitel 3 Einführung und Analyse der Skype API
21
3.2.3 Datenübertragung mittels Ap2Ap
Das Application-to-Application Feature von Skype kurz Ap2Ap genannt, ermöglicht es unsichtbar für den Benutzer, Informationen zwischen Skype Instanzen auszutauschen. Dafür
muss auf jedem System der betreffenden Instanz eine entsprechende Plugin-Anwendung
mit identischen Namen (maximal 32 Bytes) gestartet und mit Skype verbunden sein.
Die Informationen werden über einzelne Streams paketweise zwischen den Instanzen ausgetauscht und können bis zu 64 KB pro Stream betragen. Ein Stream kann Text-Daten und
Datagramme enthalten. Datagramme werden allerdings von Skype als unsichere Pakete
eingestuft und haben eine geringere Sicherheit korrekt versendet zu werden. Da alle Daten
in UTF-8 kodiert werden, müssen binäre Daten vor der Übertragung in UTF-8 Strings
konvertiert werden.
Um Informationen über einen Stream zu übertragen, muss nach erfolgreicher Verbindung
der Plugin-Anwendung zu Skype über ATTACH zunächst mit dem Befehl:
CREATE APPLICATION <appname>
eine Applikation mit identischem Namen auf beiden Skype-Instanzen erstellt werden. Anschließend wird auf der Server-Instanz durch den Befehl:
ALTER APPLICATION <appname> CONNECT <skypename>
eine Verbindung zu einer Client-Instanz mit einem eindeutigen Usernamen hergestellt. Um Daten in einen Stream zu schreiben wird über den Befehl:
ALTER APPLICATION <appname> WRITE <skypename>: <id><text>
beliebige Text-Daten mit einer eindeutigen ID gesendet, die sich aus dem Usernamen der Client-Instanz und einer inkrementellen ID zusammensetzt.
Wenn die Verbindung beendet wird bevor der Empfänger die Nachricht empfangen hat,
oder es nach 8 Minuten zu einem Timeout durch Skype kommt, gehen die gesendeten
Daten verloren. Das Problem tritt bspw. dann auf wenn der Sender die Verbindung
schließt ohne auf die Rückmeldung des Empfängers zu warten. Daher muss in einer Ap2Ap
Implementierung stets eine kontrollierte Datenübertragung sichergestellt werden.
Kapitel 3 Einführung und Analyse der Skype API
22
3.2.4 Vergleich der API Wrapper
Um nun auf der Kommunikations-Ebene aus Kapitel 3.2 eine Verbindung zu Skype herzustellen und auf dieser mit Skype zu kommunizieren, werden für die Entwicklung von
Plugin-Applikationen sogenannte Wrapper verwendet, welche Klassen mit Methoden und
Eigenschaften sowie Events in verschiedenen Sprachen bereitstellen. Damit können Entwickler auf alle Funktionen von Skype zugreifen ohne die Regeln der Befehls-Ebene beachten zu müssen.
Momentan gibt es drei etablierte Wrapper: Skype4COM, Skype4Java und Skype4Py.
Diese werden im folgenden Teil kurz vorgestellt und sind in Tabelle 3.2 zusammengefasst.
Skype4COM ist ein offizieller von Skype veröffentlichter Wrapper, welcher als ActiveX
Component-Object-Model (COM) nur für Windows Betriebssystem bereitsteht. Über das
Skype4COM Interface können alle COM-fähigen Sprachen wie Visual Studio oder Delphi
auf Skype zugreifen.
Skype4Java wird von der Skype Community als open-source Wrapper unter der Apache
2.0 Lizenz entwickelt und offiziell von Skype unterstützt. Die Java Bibliotheken können via
Java-Virtual-Machine (JVM) crossplattform auf Windows, Linux und Mac OS Systemen
verwendet werden. Allerdings ist dieser seit mehreren Jahren nicht mehr geupdatet worden
und aufgrund zahlreicher unbehobener Bugs im Ap2Ap Bereich für diese Arbeit nicht
brauchbar.
Skype4Py wird ebenfalls von der Skype Community als open-source Wrapper unter der
Berkeley-Software-Distribution Lizenz (BSD) bereitgestellt. Die Python Bibliotheken sind
ebenso crossplattform fähig und bauen direkt auf dem objektorientierten Skype4COM
Interface auf. Skype4Py ist der am meisten gewartete Wrapper und wurde in dieser Arbeit
auch aufgrund der Kompatibilität zum Robot-Operating-System verwendet.
Kapitel 3 Einführung und Analyse der Skype API
Skype4Py
Windows
Linux
Mac OS
Lizenz
Proprietär
Berkeley Software
Distribution
Herausgeber
Skype
Community
Community
Sprache
COM
Java
Python
API Version
3.2
2.5
3.6
Letzte Version / 1.0.33 am
1.0 am
1.0.32.0 am
Release
29.10.2009
30.09.2006
26.09.2009
Besondere
Offizieller Wrapper.
Keine neuen Updates. Häufigste Updates.
Merkmale
Bereits in Installation Enthält nicht
enthalten.
behobene Bugs.
Plattformen
Skype4COM
Windows
Skype4Java
Windows
Linux
Mac OS
Apache 2.0
23
Tabelle 3.2: Übersicht Skype Wrapper
Kapitel 4
Entwicklung und Interaktion mit
Sky2ROS
4.1 Einführung in ROS
Das Robot-Operating-System ist kein eigenständiges Betriebssystem wie der Name vermuten lässt, sondern ein open-source Meta-Framework, welches auf Basis eines zugrunde liegenden Betriebssystemen wie bspw. Linux implementiert ist. Das System wurde
ursprünglich 2007 von den Stanford-Artifical-Intelligence-Laboratories entwickelt und ein
Jahr später vom Willow-Garage Labor für Robotik in gemeinschaftlicher Entwicklung mit
verschiedenen Einrichtungen weiterentwickelt. Moore [10] zitiert die Beschreibung der
ROS-Core Entwickler über das System:
“ROS is an open-source, meta-operating system for your robot. It provides the services
you would expect from an operating system, including hardware abstraction, low-level device control, implementation of commonly-used func- tionality, message-passing between
processes, and package management.”
Das Zusammenspiel verschiedener Applikationen in ROS beruht auf einer GraphArchitektur wie in Abbildung 4.1 zu sehen ist. Dabei stellen Nodes die Prozesse als
Knoten dar, welche Daten als Topics in Form von Services oder Messages über ihre
Kanten austauschen. Das System selbst besteht aus einem festen Kern (ROS-Core) und
einer Sammlung zusätzlicher Benutzer-spezifischer Funktionen Packages genannt, welche
in C++ oder Python geschrieben sind.
Der große Vorteil von ROS für die Entwicklung im Kontext mit verteilten externen Anwendungen wie Skype ist, dass die Datenströme zwischen den Prozessen (Nodes) besonders
leicht ersichtlich und beeinflussbar sind. Dafür dienen eingebettete GUIs wie der rxgraph
aus Abbildung 4.1 oder direkte Manipulation in Echtzeit. Die zur internen Kommunikation
benötigten Topics, Messages und Services werden im folgenden Kapitel kurz erläutert.
24
Kapitel 4 Entwicklung und Interaktion mit Sky2ROS
25
Abbildung 4.1: Darstellung von Nodes und Topics in der ROS GUI rxgraph.
4.2 ROS Kommunikations-Prozesse
Die zwei Ansätze zur internen Kommunikation in ROS sind:
• Subscriber-Publisher Kommunikation via Messages
• Service-Client Kommunikation via Services
Beide enthalten eine Ansammlung grundlegender Datentypen wie Ganzzahlen, Gleitkommazahlen, Zeichenketten und weitere:
• int8, int16, int32, int64
• float32, float64
• string
• time, duration
• andere Messages
• header Daten
• array[ ] mit variabler Länge und array[C] mit fixer Länge
Der Nachrichtenaustausch über eine Subscriber-Publisher Semantik läuft wie folgt
ab: Ein Prozess (Node), welcher Informationen benötigt, abonniert (Subscriber) ein
gewünschtes Thema (Topic) oder veröffentlicht (Publisher) Informationen in diesem. Dabei sind die Themen völlig unabhängig von Art oder Anzahl der beteiligten Prozesse.
Bei einer Services-Client Kommunikation ruft der abfragende Prozess (Client) mit seinen
Input-Parametern den betreffenden Prozess (Server) auf und liest die Antwort direkt aus.
Der klare Vorteil dieser Abläufe liegt darin, dass Daten entkoppelt von deren Prozessen
gelesen und geschrieben werden können. So tritt kein Fehler auf wenn ein abzufragender
Prozess beendet wird, da das zugehörige Thema autark ist und weiterhin existiert.
Kapitel 4 Entwicklung und Interaktion mit Sky2ROS
26
Ein Beispiel für eine einfache Message könnte folgendermaßen aussehen:
Header
string
string
string
header
user
status
mood
Diese Message enthält die Variable header vom Typ Header und enthält Metainformationen
über den aktuellen Status der Nachricht wie z.B. eine Timestamp. Des weiteren werden
drei Werte user, status und mood vom Typ String bereitgestellt. Ein Beispiel für einen
Service könnte folgendermaßen aussehen:
Header
string
--Header
string
header_request
request
header_response
response
Dieser Service enthält die Variablen header request und header response vom Typ Header
sowie request und response vom Typ String. Dabei sind der Input (oben) und der Output
(unten) durch drei Bindestriche getrennt.
4.3 Entwicklung und Funktionsweise von Sky2ROS
4.3.1 Aufbau und Konzept
Die im Zuge dieser Arbeit entwickelte Middleware Sky2ROS besteht aus mehreren Python
Modulen, welche zwei zentrale Aufgaben erfüllen:
• Kommunikation zwischen zwei Skype Instanzen
• Bereitstellung der Informationen über zentralen ROS-Core
Die grundlegende Funktionsweise ist in Abbildung 4.2 abgebildet und läuft wie folgt ab:
Im Serverseitigen Betriebssystem wird entweder direkt über die Standard-Eingabe durch
Aufruf des Python Skripts test.py(user,infos) oder durch eine der ROS-Nodes die Abfrage
nach Informationen über einen externen User an Sky2ROS gestartet:
• info talker.py – Publisher-Node
• info server.py – Server-Node
Kapitel 4 Entwicklung und Interaktion mit Sky2ROS
27
Das gesamte Package besteht aus Services, Messages sowie mehreren Python Modulen inklusive der Skype4Py Bibliothek, welche im folgenden Abschnitt genauer erläutert werden.
Sky2ROS überprüft zunächst ob der angegebene Skype User in der Kontaktliste des Servers existiert. Ist dies nicht der Fall gibt Sky2ROS eine entsprechende Fehlermeldung und
die verfügbaren User zurück. Ist der User verfügbar, versucht Sky2ROS die gewünschten
Informationen auf zwei Wegen abzurufen. Zuerst werden die Informationen abgerufen,
welche direkt über Skype verfügbar sind wie bspw. Status, Mood, City. Für diese Abfrage
benötigt der Client keine Plugin-Applikation und kann sogar offline sein, da diese Informationen in der User-Datenbank von Skype gemäß der letzten Aktualisierung gespeichert
sind.
Anschließend versucht Sky2ROS eine Verbindung über den Skype Ap2Ap-Kanal mit dem
angegeben User herzustellen. Voraussetzung dafür ist, dass der User online ist und die
clientseitige Ap2Ap-Anwendung getInfo.py mit dessen Skype-Instanz verbunden ist. Ist
auch diese Voraussetzung erfüllt, liest der Ap2Ap-Client den String der Anfrage aus und
ermittelt die angefragten Informationen aus zwei verschiedenen Quellen. Zuerst werden
Informationen aus den Umgebungsvariablen wie die lokale Uhrzeit, Prozessor, RechnerArchitektur etc. vom Betriebssystem abgefragt. Anschließend werden externe Informationen aus dem Internet abgerufen. Dabei werden unter anderem die IP-Adresse und die
zugehörigen Geoinformationen über die online API von IPInfoDB abgerufen, welche über
das Geotargeting-Verfahren aus Kapitel 2.2 ermittelt werden. Dazu zählen Angaben über
den Staat, Bundesland, Stadt, Zeitzone, etc. in der sich der Benutzer befindet.
An dieser Stelle sollte in zukünftigen Versionen auch die Erfassung von Geoinformationen
über GPS-Empfänger, Mobilfunktelefone oder Wireless Accesspoint Localization, wie in
Kapitel 2 beschrieben, herangezogen werden und durch entsprechende Implementierung
in ROS als eigene ROS-Nodes integriert werden. Auch die Kombination aus mehreren
Quellen ist sinnvoll. Somit können Teilnehmer im Innen- und Außenbereich redudant
geortet werden. Anzumerken ist, dass diese Verfahren technisch bereits möglich, aber aus
rechtlicher Sicht und Gründen der Privatsphäre noch nicht etabliert sind.
Sind alle externen Daten gesammelt, werden diese als String an die Server Applikation
zurückgegeben. Anschließend fügt das Server-Skript die lokalen und externen Informationen zusammen und gibt diese entweder direkt über stdout (Monitor-Terminal) aus oder
stellt diese in ROS als Messages oder Services zur Verfügung.
Bei diesem Prozess wird der deutliche Vorteil von Skype ersichtlich. Bei der Entwicklung
mussten weder Kriterien für die Verbindungs-Herstellung noch das Routing der Pakete
berücksichtigt werden, da diese durch die Skype Verbindung bereits sichergestellt sind.
Abbildung 4.2 veranschaulicht den Intra- bzw. Inter-Informationsfluss zwischen Server
und Client.
Es können mittels Ap2Ap auch User abgefragt werden, welche sich nicht in der Kontaktliste
der Server Skype-Instanz befinden, aber online mit dem Skype-Netzwerk verbunden sind.
Dies wurde in diesem Fall aber vorausgesetzt und somit sichergestellt, dass das notwendige
Kriterium für eine erfolgreiche Abfrage gegeben ist.
Kapitel 4 Entwicklung und Interaktion mit Sky2ROS
28
Das serverseitige Package Sky2ROS/nodes beinhaltet die Module:
• info server.py – Server
• info client.py – Client
• info talker.py – Publisher
• info listener.py – Subscriber
Diese Module stellen die abgerufenen Informationen als Services bzw. Messages in ROS
zur Verfügung. Für die Abfrage der Daten beziehungsweise die Kommunikation zwischen
den Skype-Instanzen dienen die Bibliotheken von Skype4Py sowie die Module:
• getParams.py – Abfrage der verfügbaren Parameter
• getInfo.py – Abfrage von Informationen über einen User
Im clientseitigen Package Sky2ROS/client befinden sich die Module:
• getInfo.py – Abfrage des Betriebssystems sowie Internet-Diensten
• getGeo.py – XML-Abfrage von Geoinformationen
Diese verwenden wiederum die XML-Bibliothek SAX sowie den Skype4Py Wrapper.
Abbildung 4.2: Schichtenmodell Sky2ROS Client und Server. Die Skype Instanzen kommunizieren über den Ap2Ap-Kanal, welcher von Skype geroutet wird. Über
die Skype4Py Bibliotheken steuert Sky2ROS die eigene Skype Instanz und
stellt die abgefragen Informationen in ROS zur Verfügung.
Kapitel 4 Entwicklung und Interaktion mit Sky2ROS
29
4.3.2 Skype-Abfrage mit Ap2Ap
Der erste Schwerpunkt des praktischen Teils dieser Arbeit liegt auf der Übertragung
von Meta-Daten über Skype nach ROS. Im folgenden Abschnitt wird der Ablauf einer
vollständigen Abfrage anhand von relevanten Code-Ausschnitten der beteiligten Module
vorgestellt. Anschließend wird näher auf die Verarbeitung und Aufbereitung von Geoinformationen über eine XML-Abfrage eingegangen.
Dies ermöglichen die gleichnamigen Module getInfo.py von Server und Client. Zuerst
stellt der Server die Verbindung zwischen der eigenen und der externen Skype Instanz her.
Dabei wird dem Skype Objekt der Event-Handler SkypeEvents() übergeben, welcher die
notwendigen Events für die Ap2Ap-Übertragung auslöst.
# instatinate Skype object and set our event handlers
global skype
skype = Skype4Py . Skype ( Events = SkypeEvents ())
skype . On At ta ch me nt St at us = OnAttach
Danach wird geprüft ob der übergebene User existiert und im negativen Fall eine entsprechende Rückmeldung mit Vorschlägen ausgegeben. Existiert der User in der Kontaktliste, werden zunächst die lokalen Parameter von dessen Skype Konto ausgelesen und in
der Variable local gespeichert.
# get skype information without ap2ap
local = getLocalInfo ( reqUser , params )
In der Funktion getLocalInfo(reqUser,params) wird zunächst der Suchstring aufbereitet
und anschließend nach Schlüsselwörter für die einzelnen Parameter durchsucht.
# ## SKYPE INFORMATION ###
if not req . find ( " status " )== -1 or all :
result += uprofile . OnlineStatus
if not req . find ( " mood " )== -1 or all :
result += uprofile . MoodText
if not req . find ( " fullname " )== -1 or all :
result += uprofile . FullName
if not req . find ( " country " )== -1 or all :
result += uprofile . Country
if not req . find ( " timezone " )== -1 or all :
result += str ( uprofile . Timezone )
[...]
return result
Kapitel 4 Entwicklung und Interaktion mit Sky2ROS
30
Dabei wird weder die Groß- und Kleinschreibung noch die Reihenfolge oder Abgrenzung
der Schlüsselwörter berücksichtigt. Dies vereinfacht die generische und manuelle Eingabe
erheblich. Der Suchstring status+mood+fullname liefert z.B. das gleiche Ergebnis wie
StatusMoodFullname.
Anschließend werden die externen Parameter über den Ap2Ap-Kanal abgerufen. Dafür
wird zunächst die Verbindung zur externen Skype-Instanz hergestellt und anschließend
eine Wartezeit über event.wait(5) eingelegt, welche mit Antwort des Clients endet oder
nach 5 Sekunden abgebrochen wird. Im Falle eines Abbruchs wird am Ende des Skripts
eine Fehlermeldung generiert und mit der lokalen Antwort zurückgegeben.
# obtain reference to Application object
app = skype . Application ( ’ SKY2ROS ’)
# create application
app . Create ()
# connect application to user
app . Connect ( reqUser )
# wait until event handlers do the job
event . wait (5)
Ist die Verbindung erfolgreich hergestellt wird das Event ApplicationStreams durch den
Event-Handler ausgelöst. Die Funktion prüft ob der obligatorische Stream vorhanden ist
und übermitteln dann über den Befehl streams[x].Write eine Nachricht vom Typ String
über den Stream.
# Send and recieve data
class SkypeEvents :
def Ap pl ic ati on St re am s ( self , app , streams ):
if streams :
streams [0]. Write ( " SKY2ROS_REQUEST : " + params )
Das Auslesen des Suchstrings und die Verkettung der Daten zu einem Antwortstring
verläuft auf dem clientseitigen Skript analog zur oben beschriebenen getLocalInfo(infos)
Funktion. Sobald eine Antwort-Nachricht vom Client über den Stream empfangen wird,
liest die Funktion ApplicationReceiving den Stream aus und beendet die Wartezeit über
event.set().
# Incoming Answer
def A p p l i c a t i o n R e c e i v i n g ( self , app , streams ):
for s in streams :
global answer
answer = s . Read ()
event . set ()
Kapitel 4 Entwicklung und Interaktion mit Sky2ROS
31
Abschließend werden die lokale und die externe Antwort aneinandergefügt und als UTF-8
kodierter String, wie in Kapitel 5.2 beschrieben, zurückgegeben.
# return stream from local and ap2ap
local += answer
local = local . encode ( ’utf -8 ’)
[...]
return temp
Die beschriebenen Funktionen beschränken sich auf die reine unidirektionale Übertragung
von Meta-Daten. Damit sind die Möglichkeiten aber noch lange nicht ausgeschöpft, welche
Sky2ROS mit Hilfe des Ap2Ap-Kanal bieten kann. Die Übertragung von beliebigen Nutzdaten (Payload), bspw. zur Synchronisation von Datenbanken oder für Backup-Lösungen,
könnten bestehende Anwendungen oder Protokolle wie Microsoft Exchange ergänzen oder
sogar ersetzen.
Eine weitere Möglichkeit wäre eine Remote-Code-Execution, bei der zum Beispiel PythonModule auf Client-Systeme übertragen und ausgeführt werden können. Hier wird die
Bedeutung des untersuchten Ap2Ap-Kanals ersichtlich, welcher auf Basis der im Zuge
dieser Arbeit implementierten Statusabfragen, auch auf viele weitere Anwendungen und
Dienste erweiterbar ist.
Kapitel 4 Entwicklung und Interaktion mit Sky2ROS
32
4.3.3 XML-Abfrage und Parsing
Der zweite Schwerpunkt dieser Arbeit liegt auf der Benutzerlokalisierung. Diese wird wie
in Kapitel 2.2 beschrieben, über das Geotargeting-Verfahren mit Hilfe der Geolocation API
des Anbieters IPInfoDB ermöglicht. Dafür sind zwei Prozesse von besonderem Interesse.
Zuerst ruft ein Skript die Geolocation API auf und gibt die Daten im XML-Format
zurück. Diese werden im Modul getGeo.py ausgelesen und entsprechend aufbereitet, wie
in Tabelle 4.1 zu sehen ist. Die Funktion geoDict() erstellt zuerst ein Objekt der Klasse
geoHandler, welche die nötigen Methoden zur Verarbeitung (Parser) einer XML-Datei der
SAX-Bibliothek bereitstellt.
Anschließend liest der XML-Parser den Dateinamen ein – in diesem Fall die URL der
IPInfoDB http://ipinfodb.com/ip query.php – und wandelt die XML-Einträge in Datenpaare vom Typ Dictionary um. Der Eintrag Status der XML-Vorlage wird vor der
Rückgabe wieder entfernt, da dieser in Konflikt mit dem Status-Parameter von Skype ist.
def getDict ( dateiname ):
handler = geoHandler ()
parser = sax . make_parser ()
parser . se tConte ntHand ler ( handler )
parser . parse ( dateiname )
# Parameter conflict with skype status
del handler . ergebnis [ " Status " ]
return handler . ergebnis
Die beschriebene Funktion getDict() wird über das Modul getInfo aufgerufen, in welcher
das zurückgegebene Objekt vom Typ Dictionary dem Ergebnis-Array hinzugefügt wird.
# ## GEO INFORMATION ###
# Returns dictionary with geo information
geoDict = getGeo . getDict ( dateiname =[...])
# Adds matching parameters to result
for key in geoDict :
if not req . find ( key . lower ())== -1 or all :
result . append ( geoDict [ key ])
Tabelle 4.1 zeigt die Daten im XML-Format und als geparstes Dictionary Objekt.
Kapitel 4 Entwicklung und Interaktion mit Sky2ROS
XML Ausgabe von IPInfoDB
<? xml version=“1.0” encoding=“UTF-8” ?>
<Response>
<Ip>129.187.205.238</Ip>
<Status>OK</Status>
<CountryCode>DE</CountryCode>
<CountryName>Germany</CountryName>
<RegionCode>02</RegionCode>
<RegionName>Bayern</RegionName>
<City>München</City>
<ZipPostalCode />
<Latitude>48.7</Latitude>
<Longitude>13.4667</Longitude>
<Timezone>0</Timezone>
<Gmtoffset>0</Gmtoffset>
<Dstoffset>0</Dstoffset>
</Response>
33
Dictionary Objekt nach Parsing
{
Ip‘:‘129.187.205.238‘ ,
’
Status‘:‘OK‘ ,
’
CountryCode‘:‘DE‘,
’
CountryName‘:‘Germany‘ ,
’
RegionCode‘:‘02‘ ,
’
RegionName‘:’Bayern’ ,
’
‘City’:‘München’ ,
‘ZipPostalCode’ : ‘’,
Latitude‘:’48.7‘ ,
’
Longitude‘:’13.4667‘ ,
’
Timezone‘:0 ,
’
‘Gmtoffset’:0 ,
‘Dstoffset’:0
}
Tabelle 4.1: Meta-Daten vor und nach XML-Parsing.
Kapitel 4 Entwicklung und Interaktion mit Sky2ROS
34
4.3.4 Publishing in ROS
Um nun die gewünschten Informationen in ROS zu kommunizieren, welche in den Kapiteln 4.3.2 und 4.3.3 vom Server abgefragt wurden, finden die Module info server.py als
Service oder info talker.py Modul als Publisher Verwendung. Im folgenden Abschnitt
wird das Publisher-Modul info talker.py genauer erläutert, welches den Vorteil bietet alle Informations-Parameter eines Skype Users als separate Topics bereitzustellen, wie in
Abbildung 4.3 gezeigt.
Abbildung 4.3: ROS Graph mit Informations-Topics der einzelnen User. Jeder Parameter wird für jeden User als eigenes Topic angelegt und kann von einem
Subscriber oder Publisher abbonniert bzw. beschrieben werden.
Kapitel 4 Entwicklung und Interaktion mit Sky2ROS
35
Zunächst soll die Message infos.msg betrachtet werden, die als Klasse für Topics dient,
welche vom Modul info talker.py veröffentlicht werden. Die Message enthält ein header
Objekt, in dem Headerdaten wie eine Timestamp gespeichert sind sowie alle Parameter,
die über Sky2ROS abgerufen werden können.
Header
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
header
status
mood
fullname
country
timezone
datetime
architecture
network_name
processor
os
geoip
geostatus
geocountrycode
geocountryname
georegioncode
georegionname
geocity
geozippostalcod
geolatitude
geolongitude
geotimezone
geogmtoffset
geodstoffset
Zuerst erstellt das Modul info talker.py einen Node in ROS mit der Bezeichnung skype.
Anschließend wird versucht ein Objekt der getData Klasse – welche im folgenden Abschnitt
genauer erläutert wird – zu instanziieren und dessen Funktion Loop() aufzurufen, welche
solange existiert wie der zuvor erstellte Node.
if __name__ == ’ __main__ ’:
rospy . init_node ( ’ skype ’)
try :
data = getData ()
data . Loop ()
except rospy . R O S I n t e r r u p t E x c e p t i o n : pass
Kapitel 4 Entwicklung und Interaktion mit Sky2ROS
36
Die Klasse getData legt bei Instanziierung die folgenden Objekte an:
• msg: Objekt vom Typ info(), welche alle Parameter der infos.msg enthält.
• pub: Dient als Array für alle Topics und User welche iterativ veröffentlicht werden.
• dat,upd : Dienen als Array für alle Informationen der zugehörigen Topics.
from skypeApp . msg import info
class getData ():
def __init__ ( self ):
self . msg = info ()
self . pub = [ ]
self . dat = [ ]
self . upd = [ ]
# Get parameter array
self . params = getParams . Gparams ()
Die oben genannte Funktion Loop(), welche kontinuierlich aktiv ist solange das Skript in
ROS existiert, läuft wie folgt ab: Zuerst werden die verfügbaren User mit Hilfe des Moduls
getAvUsers.py in ein Array geladen. Anschließend werden in einer Schleife, welche durch
die geladenen User iteriert, alle verfügbaren Informationen der User abgefragt.
Dafür werden zunächst die Sonderzeichen Punkt, Komma und Bindestrich – welche zwar in
einem Skype-Namen erlaubt sind aber nicht von ROS als Topic-Namen akzeptiert werden
– eliminiert und durch Platzhalter substituiert. Ist dies geschehen, wird ein neuer Topic
update für jeden User erstellt. Dieser hat die Aufgabe bei Aufruf (eigentlich durch Beschreiben mit dem Boolean-Wert True) die Daten aller Topics eines Users zu aktualisieren,
sprich neu zu veröffentlichen.
# Eliminates , . name = name . replace ( " ," ," CC " )
name = name . replace ( " . " ," PP " )
name = name . replace ( " -" ," MM " )
# Updatelistener
self . update = rospy . Subscriber ([...])
Danach werden alle verfügbaren Informationen pro User über das Modul getInfo.py abgerufen und als Array gespeichert. Die Informationen werden nun einzeln extrahiert und
zusammen mit deren Bezeichnung in der, im Array params festgelegten Reihenfolge, in
einem neuen Topic veröffentlicht.
Der Name des Topics setzt sich dabei aus (skype/user/<user >/<info >) zusammen und
wird als Message vom Typ info gespeichert. Dabei werden die Marker LOCAL RESPONSE
und EXTERN RESPONSE an den Positionen 0, 6, 7 und 26 des Info Arrays übersprungen,
da diese der Konvention des Protokolls geschuldet sind und keine Informationen beinhalten.
Kapitel 4 Entwicklung und Interaktion mit Sky2ROS
37
Zuletzt werden die gesammelten Informationen aller User, welche das Array dat beinhaltet
in das Array upd kopiert, damit die letzten Informationen auch während eines erneuten
Abrufes bereitstehen und nach erfolgreicher Abfrage neu übernommen werden. Auf diese
Weise wird sichergestellt, dass stets die aktuellste Informationen bereitstehen und keine
Lücken bzw. veraltete Datensätze entstehen.
def _Update ( self , data ):
print data
for i in range (0 , len ( self . upd )):
self . pub [ i ]. publish ( self . upd [ i ])
rospy . sleep (3.0)
4.3.5 Use-Cases
Mittels dem Skript test.py können alle Informationen auch ohne ROS manuell abgerufen
werden und die Zugriffszeiten optional gemessen werden. Um die internen Abläufe besser
zu verstehen und die Datenübertragung gezielt zu testen wird in diesem Abschnitt die
manuelle Bedienung und die möglichen Zustände beschrieben.
Um eine manuelle Abfrage zu starten muss über die Konsole der Python Interpreter das
Skript test.py mit den Parametern User und Infos starten. Das Skript liest die übergebenen
Argumente aus und ruft die Funktion getUserInfo im Modul getInfo auf. Anschließend wird
die Rückgabe direkt in der Konsole ausgegeben.
Tabelle 4.2 zeigt alle möglichen Fälle, welche bei einem Aufruf der getUserInfo(user,info)
Funktion, auftreten können.
Kapitel 4 Entwicklung und Interaktion mit Sky2ROS
Eingabe (User,Infos)
User = {}
Infos = {}
38
Ausgabe
*Sky2ROS* Please
enter two arguments:
Username, Parameter
Negativ-Bedingung
Keine
*Sky2ROS* Skype
is not running.
Please start client.
*Sky2ROS* Requested
user doesn’t exist.
Please check spelling
of user name.
Availables users are:
<list of users>
*Sky2ROS*
No valid local
parameters.
*Sky2ROS*
No valid extern
parameters.
*Sky2ROS*
No Sky2ROS
Client found.
LOCAL RESPONSE
[. . . ]
Skype Instanz ist
nicht gestartet
User = beliebig
Infos = {}
User = {}
Infos = beliebig
User = beliebig
Infos = beliebig
User = U
Infos = I
User = U
Infos = I
User = U
Infos = I
User = U
Infos = I
User = U
Infos = I
User U
existiert nicht
I enthält keine
gültigen lokalen
Parameter
I enthält keine
gültigen externen
Parameter
Keine Verbindung
zum externen
Sky2ROS Client
Tabelle 4.2: Eingabe/Ausgabe Tabelle.
Kapitel 5
Problembehandlung und Historie
5.1 Skype API Bibliotheken
In der erste Version von Sky2ROS wurde die Sprache Java gewählt und mit den verfügbaren
Bibliotheken des Skype4Java Wrapper implementiert. Java ist als objektorientierte Sprache auf vielen Plattformen etabliert und findet auf zahlreichen Multimedia-Endgeräten
Verwendung. Die Entwicklung auf Grundlage von Java wurde aber aus zwei Gründen
wieder eingestellt.
Zum einen aus mangelnder Kompatibilität von Java zu ROS. Die ermittelten Informationen hätten zwar von Java in Python via temporären Dateien, Datenbank, oder ähnlichen
übertragen werden können, was aber zu negativen Auswirkungen auf die Performance und
die Möglichkeit einheitlich zu Debuggen geführt hätte. Zum anderen konnte folgendes gravierendes Problem bei der Datenübertragung nicht gelöst werden, welches vermutlich auf
einen ungelösten Fehler des veralteten Skype4Java Wrapper zurückzuführen ist:
Nachdem eine Verbindung zwischen zwei Instanzen hergestellt wurde, schlug der erste Versuch einen Stream herzustellen nach jedem Neustart fehl. Dieses Problem wurde auch im offiziellen Forum der Skype Community gemeldet und blieb bis Dato ohne Lösungsvorschlag.
Ein User schrieb folgenden Beitrag in der Skype Developer Community [1]:
“Thanks for the suggustion, i just succeeded in sending datagram messages with app2app
using the Skype4COM library and .net framework 4.0 after discovering that it rarely
connects on the first try. it took two tries to get a stream to send by and after the stream
was setup, it just worked. for future reference to anyone else who has had this problem, the
Skype4Java api seems to be a bit out of date in the App2App section.”
In der zweiten Version wurde Sky2ROS komplett in Python reimplementiert und konnte
mit dem Skype4Py Wrapper problemlos eine Verbindung zwischen zwei Skype Instanzen
herstellen. Leider enthielt die aktuelle Skype4Py Version 1.0.32.0 API auch einen Fehler der
es nicht erlaubte das notwendige skype Objekt mit einem Eventhandler zu instanziieren.
39
Kapitel 5 Problembehandlung und Historie
40
# instatinate Skype object and set our event handlers
global skype
skype = Skype4Py . Skype ( Events = SkypeEvents ())
Der Grund – in der skype Klasse ist das SkypeEvents() Argument nicht korrekt vorgesehen,
sodass der Python-Interpreter die folgende Fehlermeldung zurückgab:
Traceback ( most recent call last ):
File " [...]/ app2app_server . py " ,
[...]
self . _S e t Ev e n t Ha n d le r O bj ( Events )
AttributeError : ’ Skype ’ object has
no attribute ’ _S e t Ev e n tH a n dl e r O bj ’
Da dieser Fehler bereits gemeldet, aber noch nicht behoben worden ist, wurde für die Entwicklung die funktionsfähige Vorgänger-Version 1.0.31.0 verwendet, welche für die Ap2Ap
Funktion einwandfrei funktioniert.
5.2 Zeichenkodierung
Ein weiteres Problem, welches zu lösen galt, war die diverse Zeichenkodierungen. Python speichert die Einträge in Listen literal als ASCII-Zeichen ab. z.B. wird folgendes
Array [0 ä0 ,0 ö0 ,0 ü0 ] als [\x84, \x94, \x81] gespeichert. Skype auf der anderen Seite kodiert
nach Kapitel 3.2.3 alle auf dem Ap2Ap-Kanal übertragenen Daten in UTF-8.
Um die Kompatibilität beim Datenaustausch zwischen Python, Skype und ROS sicherzustellen und alle in UTF-8 möglichen Zeichen korrekt übertragen zu können, wurden
zur Übertragung alle Arrays in Python in Zeilenweise separierte Strings umgewandelt und
als unicode dekodiert. Anschließend können die Strings durch die Methode split() ohne
Informationsverlust in Arrays zurückgewandelt und wieder in UTF-8 rekodiert werden.
# Convert UTF -8 array into unicode string
for i in range (0 , len ( result )):
[...]
uni += ’ NA \ n ’
else :
uni += result [ i ] + ’\ n ’
[...]
return temp . decode ( ’utf -8 ’)
Kapitel 5 Problembehandlung und Historie
41
5.3 Testergebnisse, Performance und Ressourcen
Im folgenden Abschnitt wird in Kürze auf die relevanten Ressourcen Zeit- und Speicherkapazität von Sky2ROS und deren Anwendungen eingegangen.
Das Skript wird von einem Python Interpreter ausgeführt und wird für die
Ausführungsdauer als eigener Prozess gestartet. Dafür werden für Server und Client Skript unterschiedlich viel Kapazitäten benötigt. Python allokiert zwischen 4 bis 7
Megabyte Arbeitsspeicher und ist damit auf aktuellen Desktop PCs vernachlässigbar.
Die ebenfalls geringe CPU-Auslastung hat sich bei der Ausführung des Skripts nicht
signifikant verändert (δ ≤ 5%).
In Tabelle 5.2 und 5.3 befinden sich die gemessenen Werte für die CPU-Auslastung und
die Dauer der Skripte mit folgender Hardwarekonfiguration:
Architektur
Arbeitsspeicher
Prozessoren
Betriebssystem
Kernel
x86
3,0 GB
2 x Intel Pentium 4 3,00 GHz
Ubuntu 10.04
Linux 2.6.3.2-65
Tabelle 5.1: Hardwarekonfigurations.
Die benötigte Dauer für eine Sky2ROS Abfrage wurde über eine Erweiterung des test.py
Skripts gemessen und ausgewertet. Über eine repräsentative Anzahl an Versuchen wurden
dabei die Maxima, Minima, Arithmetisches Mittel und Schwankungen der Prozessdauer
bestimmt. Dabei wurden auch die Kompatibilität zwischen verschiedenen Betriebssystemen getestet und keinerlei Probleme oder Abweichungen festgestellt.
Server
Client
HDD-Speicher 1,72 MiB 1,32 MiB
RAM-Speicher 2,8 MiB 3,3 MiB
Tabelle 5.2: Messwerte Speicher-Bedarf.
Vor allem die Dauer, welche für die Anwendung besondere Relevanz hat, verhält sich nicht
konstant. Bei den Messungen wurden Schwankungen um bis zu 400% festgestellt.
Dabei war hingegen der ersten Annahme die Art oder Anzahl der Informationen statistisch
unabhängig von der Dauer. Das lässt darauf schließen, dass diese hauptsächlich von der
Paketübertragungsdauer abhängt und nicht vom lokalen System. Bei einer Abfrage ohne
externen Sky2ROS Client wird stets bis zum Timeout von 5 Sekunden gewartet. Hier sind
Peaks kaum noch sichtbar, da aus der Messung mit verbundenem Client die mittlere Dauer
unter 5 Sekunden liegt.
Kapitel 5 Problembehandlung und Historie
Mit Client
Anzahl der Abfragen 1 K
Arithmetisches Mittel 0,82 s
Maximum
7,20 s
Minimum
0,10 s
Schwankung
400%
42
Ohne Client
1K
5,14 s
5,20 s
5,11 s
1%
Tabelle 5.3: Messwerte Zeitwerte.
Mögliche erste Lösungsansätze für dieses Deadlock-Problem werden im folgenden Kapitel
5.4 vorgestellt. Dank der geringen Speicher-Anforderung und CPU-Auslastung, genügen
die ausgeführten Python-Skripte auch geringen Hardware Ausstattungen von mobilen Endgeräten. Inwiefern diese zukünftig von Werk aus Python-Dienste unterstützen ist noch
nicht absehbar. Da aber mobile Betriebssysteme wie Android oder iOS auf Linux basieren,
ist die Grundlage für eine Python Unterstützung durchaus gegeben. Dennoch wären auch
zweit Implementierungen in Java oder ActiveX für Microsoft Systeme interessant.
Kapitel 5 Problembehandlung und Historie
43
5.4 Lösung des Deadlock-Problems
Aus den bekannten und gemessenen Werten wird der limitierende Zeit-Faktor besonders
ersichtlich. Die feste Timeout-Dauer von 5 Sekunden bei Skype Instanzen ohne Sky2ROS
ist in der momentanen Implementierung die einfachste Lösung, würde aber ein erhebliches
Problem für die Performance darstellen.
Dies bedeutet, dass bei einer größeren Anzahl von Abfragen wie bspw.
in der
3
Größenordnung von 10 , folglich 5000 Sekunden, d.h. über 80 Minuten vergehen können.
Unter der Annahme, dass ein gewöhnlicher User volatile Informationen wie Status, Mood
oder Location in einem Intervall von 30 Minuten ändert, wären damit die Informationen
um bis zu einer Stunde veraltet. Um dieses Deadlock-Problem zu lösen wurden zwei
theoretische Ansätze entwickelt.
Ein erster praktikabler Lösungsansatz sieht vor, dass jeder bekannte Teilnehmer in ROS
ein Prüf-Bit setzt ob dieser Sky2ROS verwendet oder nicht. Ist dies nicht der Fall, kann
der Timer sofort zurückgesetzt und die Abfrage vorzeitig beendet werden. Damit ist sichergestellt, dass der Abfrage-Prozess nicht unnötig blockiert wird.
Eine zweite Möglichkeit wäre es an Stelle der permanent-statischen Abfrage aller Daten
in einer festen Reihenfolge, diese dynamisch abzufragen. Sprich Informationen einzeln
und nur nach einer Änderung gezielt zu aktualisieren. Die in der Skype API vorgesehen
Events könnten so verwendet werden, dass sie den Server darüber informieren sobald der
Benutzer seine Daten seit dem letzten Aufruf geändert hat. Zum Beispiel beim Wechsel des
Status oder des Aufenthaltsort. Dafür müsste das bestehende System so erweitert werden,
dass gemäß dem vereinbarten Protokoll definierte Events in ROS durch den Teilnehmer
ausgelöst werden.
Eine weitere Alternative könnte eine multi-tasking Abfrage sein. Inwiefern Skype und
der Ap2Ap-Kanal diese unterstützen ist nicht bekannt und müsste durch Versuchsweise
Implementierung auf Durchführbarkeit, Performance und Stabilität getestet werden.
Kapitel 6
Zusammenfassung und Ausblick
In dieser Arbeit wurden die Grundlagen und Möglichkeiten für die Datenübertragung mittels Skype untersucht und in einem ersten Ansatz erfolgreich implementiert. Mit Hilfe der
entwickelten Middleware Sky2ROS, welche eine dezentrale End-to-End Übertragung zweier
Skype Instanzen über den Ap2Ap-Kanal ermöglicht, können beliebige Daten transferiert
werden ohne sich mit den Problematiken wie Verbindungaufbau, Kanalzugriff, Routing
etc. konfrontieren zu müssen.
Neben den Informationen, welche Skype oder das lokale Betriebssystem über einen Teilnehmer bereitstellen, können auch Sensor-Daten einer intelligenten Umgebung wie bspw. einem Wohnraum, Büro oder Auto über Skype übertragen und in ROS integriert werden. Eine weitere Möglichkeit wäre es den bisherigen Kanal bidirektional zu nutzen, sodass Server
und Teilnehmer über die reine Status-Abfrage hinaus, in der Lage sind intelligent miteinander zu kommunizieren. In diesem Fall könnten weitere Dienste wie Daten-Synchronisation
oder Backup-Lösungen zusätzlich angeboten werden.
Von besonderem Interesse sind auch die unterschiedlichen Möglichkeiten der Benutzerlokalisierung. Satelliten-gestütztes GPS, Wireless Accesspoint Localization sowie das verwendete Geotargeting-Verfahren können in Kombination eine zuverlässige und präzise Ortung
für weiterführende Dienste wie bspw. Location-Based-Services gewährleisten. Hier knüpft
diese Arbeit direkt an den zunehmenden Trend mobiler Geo-Anwendungen an, die auf aktuellen mobilen Endgeräten mittels GPS-Chipsatz, Hochgeschwindigkeits-Datenverbindung
und einer verbesserten Infrastruktur ermöglicht werden.
Das Hauptkriterium der bisherigen Anwendung ist die Dauer der Abfrage eines beliebigen
Teilnehmers. Würde diese den gemessenen worst-case Wert von 5 Sekunden pro Abfrage
annehmen, wäre eine größere Anzahl an Clients nicht mehr praktikabel zu verwalten. Für
dieses Deadlock-Problem wurden zwei Lösungsansätze theoretisch aufgestellt, die auf einer intelligenten Interaktion der Clients beruhen. Diese Ansätze sind zwar zum jetzigen
Zeitpunkt realisierbar, beschränken sich allerdings auf die von Skype vorhergesehen Methoden und Events. Je nach Anwendung könnte Sky2ROS insofern erweitert werden, dass
Änderungen und Aktionen des Benutzers wie z.B. ein Ortswechsel erkannt und gezielt
abgefragt werden können.
44
Kapitel 6 Zusammenfassung und Ausblick
45
Die hier behandelten Thematiken sind also nur der Ausgang für weitere Forschungen und
Entwicklungen, und schaffen in praktikabler Art und Weise die Grundlagen für neue Anwendungen mit immer größeren Nutzen im alltäglichen Leben.
Anhang A
Gesprächs-Protokoll
Auszug des Gespräch-Protokolls, welches beim Anruf des Skype Test-Dienstes Echo123 mit
der Anwendung Tracer.exe protokolliert wurde.
CONNSTATUS ONLINE
CUR RENTUS ERHAND LE es - key -02
USERSTATUS ONLINE
CALL echo123
CALL 1165 STATUS UNPLACED
CALL 1165 STATUS UNPLACED
GROUP 330 NROFUSERS 0
CALL 1165 STATUS ROUTING
GROUP 298 NROFUSERS 1
CALL 1165 STATUS RINGING
CALL 1165 STATUS INPROGRESS
[...]
CALL 1165 DURATION 1
CALL 1165 DURATION 2
[...]
CALL 1165 DURATION 9
CALL 1165 DURATION 10
CALL 1165 VIDEO - SEND - STATUS NOT - AVAILABLE
CALL 1165 VIDEO - STATUS VIDEO - SEND - ENABLED
CALL 1165 DURATION 11
CALL 1165 DURATION 12
[...]
CALL 1165 DURATION 56
CALL 1165 DURATION 57
CALL 1165 FAILUREREASON 14
CALL 1165 DURATION 58
CALL 1165 STATUS FINISHED
Quellcode A.1: Aufzeichnung des gesamten Befehls-Protokoll eines Sprachanrufs.
46
Abbildungsverzeichnis
2.1
2.2
2.3
2.4
3.1
4.1
4.2
4.3
Positionsermittlung durch Schnittpunkt aus drei bekannten Entfernungen
nach Köhne u. Wößner [6]. Dabei ergeben sich die Punkte B aufgrund von
Ungenauigkeiten der Uhr im GPS-Empfänger. Diese werden zwischen den
Punkten B interpoliert bis sich Punkt A als korrekte Position ergibt. . . .
Der Screenshot nach Mills [9] von Google Maps Mobile 5 zeigt eine Positionsermittlung auf Basis von Funkzellenortung und gibt die erzielte Genauigkeit
an. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Verteilung in 2007 erfasster IP-Adressen weltweit nach IPligence [4]. . . . .
Untergliederung der Netz-Knoten in Subnetze. . . . . . . . . . . . . . . . .
10
11
12
Abschätzung der Skype User Entwicklung von 2007 bis 2010 nach Brockmann&Company [2]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
Darstellung von Nodes und Topics in der ROS GUI rxgraph. . . . . . . . .
Schichtenmodell Sky2ROS Client und Server. Die Skype Instanzen kommunizieren über den Ap2Ap-Kanal, welcher von Skype geroutet wird. Über die
Skype4Py Bibliotheken steuert Sky2ROS die eigene Skype Instanz und stellt
die abgefragen Informationen in ROS zur Verfügung. . . . . . . . . . . . .
ROS Graph mit Informations-Topics der einzelnen User. Jeder Parameter
wird für jeden User als eigenes Topic angelegt und kann von einem Subscriber
oder Publisher abbonniert bzw. beschrieben werden. . . . . . . . . . . . . .
47
9
25
28
34
Tabellenverzeichnis
2.1
Testergebnisse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
3.1
3.2
Skype API Syntax Tabelle . . . . . . . . . . . . . . . . . . . . . . . . . . .
Übersicht Skype Wrapper . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
23
4.1
4.2
Meta-Daten vor und nach XML-Parsing. . . . . . . . . . . . . . . . . . . .
Eingabe/Ausgabe Tabelle. . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
38
5.1
5.2
5.3
Hardwarekonfigurations. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Messwerte Speicher-Bedarf. . . . . . . . . . . . . . . . . . . . . . . . . . .
Messwerte Zeitwerte. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
41
42
48
Literaturverzeichnis
[1] Anonym: Skype4Java Ap2Ap problems. http://forum.skype.com/index.php?
showtopic=688593, August 2010
[2] Brockmann&Company: Skype Statistics 1H 2010. http://www.brockmann.com/
communications/voip/2112-skype-statistics-1h2010, August 2010
[3] Cao, Shoufeng ; He, Longtao ; Li, Zhongxian ; Yang, Yixian: SkyF2F: Censorship Resistant via Skype Overlay Network. In: WASE International Conference on
Information Engineering (2009), Juli
[4] IPligence: Internet World Map 2007. http://www.ipligence.com/worldmap, Oktober 2007
[5] Jonsson, Dan K. ; Olavesen, J.: Estimated accuracy of location in mobile networks
using E-OTD. http://student.grm.hia.no/master/ikt02/ikt6400/g17/report/
report_eotd.pdf, 2002
[6] Köhne, A. ; Wößner, M.: Bestimmung der Position beim GPS-System - Laufzeitmessung. http://www.kowoma.de/gps/Positionsbestimmung.htm, November 2007
[7] Kumar, Nipun: Intelligent Spaces. In: DM Lecture Series (2009), S. 4
[8] Lopes, L. ; Viller, E. ; Ludden, B.: GSM standards activity on location. In: Novel
Methods of Location and Tracking of Cellular Mobiles and Their System Applications
(1999)
[9] Mills, Elinor: Google Maps for Mobile adds ’My Location’ feature. http://news.
cnet.com/8301-10784_3-9824546-7.html, November 2007
[10] Moore, Christian: Toward a Decentralized approach. http://www.seas.upenn.edu/
~cpm2/cm_qual.pdf, Juni 2010
[11] Skype:
2010
About Skype: Janus Friis. http://about.skype.com/janusfriis.html,
[12] Wan, Zhiqing: Localization Using Wireless Access Points. 2010
[13] Wang, Chuen-Ching ; Liang, Ming-Cheng ; Hwang, Nann-Luh ; Tai, Shen-Chuan:
Mobile location by time advance for GSM. In: Microwave Conference, 2001. APMC
2001. 2001 Asia-Pacific (2001), Dezember
49
LITERATURVERZEICHNIS
50
[14] Zhang, Wenyan ; Cui, Ximing ; Li, Dengfeng ; Yuan, Debao ; Wang, Mengru:
The Location Privacy Protection Research in Location-Based Service. In: Geoinformatics, 2010 18th International Conference on Geoinformatics for GIScience (2010),
September