Table Of ContentDiplomarbeit
Architektur fu¨r
selbstkonfigurierende Dienste auf
Basis stark ressourcenbeschr¨ankter
eingebetteter Systeme
Eingereicht von:
Andreas Dittrich, Jon Kowal
11.07.2008
Gutachter:
Prof. Dr. Miroslaw Malek
Prof. Dr. Hans-Ulrich Heiß
Betreuer:
Dr. Jan Richling
Humboldt-Universit¨at zu Berlin
Institut fu¨r Informatik
Abstract
Die Vernetzung von Computern in Haushalten und Industrie und die Miniaturisie-
rungihrerRechentechniknimmtstetigzu.AufbauendaufihrerStudienarbeit,inder
sie das Potential des Einsatzes minimaler eingebetteter Systeme in IP-Netzwerken
zeigten,[32] m¨ochten Andreas Dittrich und Jon Kowal in dieser Arbeit die Dienst-
nutzung auf eingebetteten Systemen in den Vordergrund stellen. Besonders im
Rahmen der Heimautomation fehlt es an etablierten Technologien, die dem Nutzer
den Zugang zu dieser Welt ¨offnen. So wie schon heute jedermann in der Lage, ist
eine Kaffeemaschine anzuschließen und zu bedienen, sollte dies nach Meinung der
Autoren auch fu¨r ans Netzwerk angeschlossene Ger¨ate m¨oglich sein: Anstecken
– Anschalten – Benutzen. Jegliche Konfiguration von Netzwerkparametern sollte
einem durchschnittlichen Nutzer nicht zugemutet werden.
Die Autoren untersuchen in dieser Arbeit die Verfu¨gbarkeit vorhandener Stan-
dards fu¨r die Konfiguration, Entdeckung und Benutzung von Netzwerkdiensten.
Sie untersuchen, welche Hu¨rden fu¨r die Anwendung derselben auf eingebetteten
Systemen existieren und wie eine Implementierung auf minimalen eingebetten Sys-
temen m¨oglich ist. Daraus entwickeln sie ein Framework, das es erm¨oglicht, einfache
Dienste ohne jeglichen Konfigurationsaufwand im Netzwerk anzubieten.
Allein die Propagation eines Dienstes im Netzwerk genu¨gt nicht fu¨r die Dienstnut-
zung. Um dem Anwender die Installation spezieller Software zu ersparen, greifen
die Autoren Ideen des Web 2.0 auf, dessen moderne Dienste im Internet große
Erfolge feiern. Komplexe Applikationen k¨onnen, von einem Server ausgeliefert, im
Webbrowser des Anwenders laufen. Dieses so erfolgreiche und fu¨r den Anwender
einfache Konzept ist in lokalen Netzwerken bisher nicht anzutreffen. Die Autoren
untersuchen Szenarien und M¨oglichkeiten, Anwendern die fu¨r die Nutzung ihrer
eingebetteten Dienste notwendigen Applikationen durch die Dienstanbieter selbst
verteilen zu lassen.
Durch die Kombination der Techniken zur Autokonfiguration von Netzwerkpara-
metern, zur Entdeckung und Suche von Diensten in lokalen Netzwerken und zur
VerteilungderAnwendungen zurDienstnutzungundderen Portierungaufminimale
eingebettete Systeme ¨offnen die Autoren Raum fu¨r neue Szenarien der Vernetzung
und Integration von Diensten.
i
Inhaltsverzeichnis
Abbildungsverzeichnis ix
Tabellenverzeichnis xi
1 Einleitung 1
1.1 Problemstellung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Begriffe und Definitionen . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4 Herangehensweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.6 Hinweise zur gew¨ahlten Sprache . . . . . . . . . . . . . . . . . . . . . 10
2 Verwandte Arbeiten 11
2.1 U¨berblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Eingebettete Internetstacks . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 Eingebettete Service Discovery und Presentation Mechanismen . . . 14
2.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3 Skalierbarer und Modularer Internetstack 19
3.1 Schichtenmodelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2 Netzwerktechnologien und Protokolle . . . . . . . . . . . . . . . . . . 23
iii
3.2.1 Ethernet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.2 Internet Protocol (IP) . . . . . . . . . . . . . . . . . . . . . . 25
3.2.3 Address Resolution Protocol (ARP) . . . . . . . . . . . . . . 27
3.2.4 Multicast-IP . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.5 User Data Protocol (UDP) . . . . . . . . . . . . . . . . . . . 30
3.2.6 Transmission Control Protocol (TCP) . . . . . . . . . . . . . 31
3.3 Anforderungen an einen eingebetteten Internetstack . . . . . . . . . 35
3.3.1 Verzicht auf ein Betriebssystem . . . . . . . . . . . . . . . . . 35
3.3.2 Deterministischer Speicherbedarf . . . . . . . . . . . . . . . . 38
3.3.3 Deterministischer Programmfluss . . . . . . . . . . . . . . . . 40
3.3.4 Beschr¨ankung der Paketgr¨oßen . . . . . . . . . . . . . . . . . 43
3.3.5 Minimalisierung der Protokolle des Internetstacks. . . . . . . 44
3.3.6 Parallele Paketverarbeitung . . . . . . . . . . . . . . . . . . . 44
3.4 Architektur des nIP-Internetstacks . . . . . . . . . . . . . . . . . . . 45
3.4.1 Schnittstellen und Integration . . . . . . . . . . . . . . . . . . 45
3.4.2 Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.4.3 Programmfluss . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.4.4 Kooperatives Speichermodell . . . . . . . . . . . . . . . . . . 56
4 Service Discovery und Autokonfiguration 63
4.1 Serviceorientierte Autokonfiguration . . . . . . . . . . . . . . . . . . 63
4.1.1 Aktuelle Szenarien . . . . . . . . . . . . . . . . . . . . . . . . 63
4.1.2 Ziele einer serviceorientierten Architektur . . . . . . . . . . . 64
4.2 Adressierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.2.1 Dynamic Host Configuration Protocol (DHCP) . . . . . . . . 67
4.2.2 Automatic Private IP Addressing (APIPA)/IPv4LL . . . . . 68
4.2.3 Weitere Methoden . . . . . . . . . . . . . . . . . . . . . . . . 70
iv
4.3 Namensau߬osung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.3.1 Herk¨ommliche Methoden . . . . . . . . . . . . . . . . . . . . 73
4.3.2 Multicast DNS (mDNS) . . . . . . . . . . . . . . . . . . . . . 75
4.3.3 Link-Local Multicast Name Resolution (LLMNR). . . . . . . 79
4.3.4 Betrachtungen zur Multicast-Verwendung . . . . . . . . . . . 82
4.4 Service Discovery und Service Description . . . . . . . . . . . . . . . 83
4.4.1 Service Location Protocol (SLP) . . . . . . . . . . . . . . . . 86
4.4.2 Domain Name System based Service Discovery (DNS-SD) . . 88
4.4.3 UPnP Discovery und Description . . . . . . . . . . . . . . . . 91
4.5 BewertungetablierterProtokollfamilienfu¨rdienstbasierteUmgebungen 95
4.5.1 Spezielle Anforderungen im eingebetteten Bereich . . . . . . 97
4.5.2 Entscheidung fu¨r eine Technologie im Rahmen dieser Arbeit . 100
4.6 Architektur des nIP-Zeroconf-Frameworks . . . . . . . . . . . . . . . 100
4.6.1 Adressierung . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
4.6.2 Namensau߬osung . . . . . . . . . . . . . . . . . . . . . . . . . 101
4.6.3 Service Discovery und Description . . . . . . . . . . . . . . . 107
4.6.4 Fehlermodell bei Speichermangel . . . . . . . . . . . . . . . . 108
5 Service Deployment und ubiquit¨are Pr¨asentation 111
5.1 Szenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
5.2 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
5.2.1 Techniken der Pr¨asentation . . . . . . . . . . . . . . . . . . . 112
5.2.2 Auslagerung rechenintensiver Operationen . . . . . . . . . . . 114
5.2.3 Verteilte Pr¨asentation . . . . . . . . . . . . . . . . . . . . . . 116
5.3 Ansatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
5.3.1 Beschr¨ankungen in AJAX . . . . . . . . . . . . . . . . . . . . 117
5.4 nIP-Web-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
v
5.4.1 nIP-Web-Framework . . . . . . . . . . . . . . . . . . . . . . . 119
5.4.2 nIP-Web-Tunneldienst . . . . . . . . . . . . . . . . . . . . . . 120
5.4.3 nIP-Web-Plugindienst . . . . . . . . . . . . . . . . . . . . . . 123
5.4.4 Pr¨asentation innerhalb der Webseite . . . . . . . . . . . . . . 125
5.4.5 Weitere Features, als Erweiterung m¨oglich, Ausblick . . . . . 128
6 Evaluierung der Realisierbarkeit 129
6.1 Hardwareumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
6.2 Umfang der Implementierung . . . . . . . . . . . . . . . . . . . . . . 131
6.3 Statischer Speicherbedarf . . . . . . . . . . . . . . . . . . . . . . . . 134
6.4 Dynamischer Speicherbedarf . . . . . . . . . . . . . . . . . . . . . . . 136
6.4.1 Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
6.4.2 Heap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
6.5 Hardwareanforderungen einer nIP-Web-Umsetzung . . . . . . . . . . 142
6.5.1 Anforderungen des nIP-Web-Frameworks . . . . . . . . . . . 143
6.5.2 Anforderungen des nIP-Web-Plugindienstes . . . . . . . . . . 144
6.5.3 Anforderung des nIP-Web-Tunneldienstes . . . . . . . . . . . 144
6.5.4 Betrachtungen zur Leistungsf¨ahigkeit. . . . . . . . . . . . . . 146
6.5.5 Beispielanwendung: Heizungssteuerung . . . . . . . . . . . . . 147
7 Fazit 151
A Internetstack Schnittstellen 155
A.1 Systemschnittstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
A.2 Anwendungsschnittstellen . . . . . . . . . . . . . . . . . . . . . . . . 156
Abku¨rzungsverzeichnis 159
Quellenverzeichnis 163
vi
Stichwortverzeichnis 171
vii
Description:sie das Potential des Einsatzes minimaler eingebetteter Systeme in IP-
Netzwerken zeigten,[32] . 4.5.2 Entscheidung für eine Technologie im Rahmen
dieser Arbeit . 100 . 5.2 Ablauf der TCP-Kommunikation über den den nIP-Web-
Tunneldienst 124 dementsprechend kann es mehrere Endpunkte pro Host
geb