software ubiquitärer systeme - ess.cs.tu-dortmund.de · homes and offices across the country“....

11

Software ubiquitärer SystemeÜbung 5: Infrastruktur des Internets

Christoph Borchert und Michael EngelArbeitsgruppe Eingebettete Systemsoftware

Lehrstuhl für Informatik 12TU Dortmund http://ess.cs.uni-dortmund.de/~chb/

http://ess.cs.tu-dortmund.de/DE/Teaching/SS2011/SuS/

SuS Übung 5 – Infrastruktur des Internets 22

Inhalt● Die Vision des Internets

● Peer-to-Peer (P2P)● Herausforderungen für ubiquitäre Systeme

● Ubiquitäre Anwendungen● Anbindung an das Internet


3. Juli 1969 – Geburt des Internets● ARPANET: Advanced Research Projects Agency Network

● Welche Eigenschaften stellte sich Leonard Kleinrock 1969 für die revolutionären 'computer utilities' vor?

„As of now, computer networks are still intheir infancy. But as they grow up and becomemore sophisticated, we will probably see the

spread of 'computer utilities' which, like presentelectric and telephone utilities, will service individual

homes and offices across the country“. – Leonard Kleinrock [1]


Vision des Internets● 5 grundlegende Elemente [1]:

1. The Internet technology will be everywhere.2. It will be always accessible.3. It will be always on.4. Anyone will be able to plug in from any location with

any device at any time.5. It will be invisible.

● Welche dieser Elemente sind heutzutage erfüllt /nicht erfüllt?


4. … any device at any time● Beschreibt die Fähigkeit, jedes Gerät immer überall an

das Internet anzuschließen.

● Doch was ist mit IP-Adressen?- Behält jedes Gerät seine IP-Adresse, egal wo es sich befindet?

- Hierarchisches Routing?

- Erschöpfung des Adressraumes?

● Lösungen:- RFC 5944 - IP Mobility Support for IPv4 („Mobile IP“)

- Classless Inter-Domain Routing (CIDR)

- IPv6

● Wie ist hier der aktuelle Stand?


5. It will be invisible● Die Technologie rückt in den Hintergrund

● Kernkonzept von ubiquitären Systemen● vgl. Mark Weiser (erste Übung)

● Heutzutage steht das Internet eher im Vordergrund● Explizite Nutzung („Internet Explorer“)● Expliziter Zugang

- Telefonanschluss → DSL-Modem → Router …

- WLAN i.d.R. nur mit passendem Benutzerkonto/Passwort

- Gleiches gilt für GPRS, UMTS, ...


The Invisible Global Infrastructure● Finales Konzept von Kleinrocks Vision

● Aus welchen drei Bestandteilen setzt sich die Vision der „Invisible Global Infrastructure“ zusammen?


The Invisible Global Infrastructure (2)

[1]


Nomadicity● Benutzer bewegen sich von Ort zu Ort

● Benötigen komfortablen und transparenten Internetzugang

● Welche Herausforderungen gibt es für aktuelle Systeme?

„When a user arrives at a ‘‘foreign’’ destination,that user appears to be an alien in that environment.Our nomadic technology must provide the ability for

the user to easily gain access as a ‘‘friendly’’ in thisnew environment.“ [1]


Nomadicity● Benutzer bewegen sich von Ort zu Ort

● Benötigen komfortablen und transparenten Internetzugang

● Herausforderungen:● Verschiedenste Geräte (Laptops, Handys, Tablets, PDAs, …)● Variable Netzqualität (niedrige Datenrate, evtl. gar kein Zugang)● (Re-)Konfiguration der Software (IP-Adresse, Netzmaske, Proxy, ...)

„When a user arrives at a ‘‘foreign’’ destination,that user appears to be an alien in that environment.Our nomadic technology must provide the ability for

the user to easily gain access as a ‘‘friendly’’ in thisnew environment.“ [1]


Nomadicity – Ideen zur Verwirklichung● Intelligente Netze

● Zurzeit steckt (fast) alle Intelligenz in den Endgeräten● Das Netz selbst ist „dumm“ und befördert nur Pakete● Der Nutzer muss sich also an das Netz anpassen● Idee: Adaptive Netzzugänge, die sich den variablen Bedürfnissen

der Nutzer autonom anpassen

● Nomadic Enabled Applications● Anwendungen müssen mit unterschiedlichen Situationen rechnen

- z.B. drastische Änderungen der Datenrate, Latenz, Paketverluste

● Illusion einer permanenten Internetverbindung erzeugen, selbst wenn zwischenzeitlich keine Verbindung besteht


Embeddedness● Alltägliche Gegenstände verbunden mit dem Internet

● „Smart Spaces“● Intelligente Umgebungen durch eingebettete Systeme

● Cyber-Physical-Systems (vgl. erste Übung)


Ubiquity● Internetzugang überall

● Mobilfunk● Relativ geringe Datenraten pro Nutzer● Teure Lizenzen für das Frequenzspektrum

- UMTS (2,1 GHz): 32 Milliarden €

- LTE (800 MHz): 3,5 Milliarden €

→ teure Netzzugänge für den Nutzer

● WLAN● Hohe Datenrate, aber geringe Reichweite● I.d.R. günstige oder kostenlosen Zugänge

● MANets: Mobile Ad-hoc Networks


The Invisible Global Infrastructure (3)

[1]


Die Zukunft?● Nomadicity, Embeddedness und Ubiquity

● Definiert nur die (globale unsichtbare) Infrastruktur

● Es fehlen noch die Anwendungen!● Roaming Unterstützung● Kontextabhängige Dienste

- Variabel je nach Ort

- Variabel je nach Benutzer

● Nomadic Enabled Applications● …

→ „Distributed Intelligence“


Ausgangspunkt - Grundform des Internet (1969-1995)


Ausgangspunkt - WWW-dominiertes Internet (1995-1999)


Ausgangspunkt - Peer-to-Peer (1999-??)


Definition P2P● Ein System kann als Peer-to-Peer bezeichnet werden

wenn,● eine gemeinsame Nutzung von Ressourcen stattfindet

- Teilsysteme können sowohl Informationsanbieter als auch Informationskonsument sein

● jedes Teilsystem einen gewissen Grad an Autonomie besitzt- Keine zentrale Kontrolle oder Nutzung von zentralen Diensten

● die einzelnen Teilsysteme nicht permanent mit dem Gesamtsystem verbunden sein müssen- Selbstorganisation des Systems

● die einzelnen Teilsysteme keine permanente Netzwerkadresse benötigen- Von der Netzwerkschicht unabhängige Adressierung


Probleme von P2P● Generelle Probleme

● Hohe Dynamik- Ständig wechselnde Kommunikationswege, Dienste, Dienstgüte

● Verfügbarkeit von Diensten und Informationen- Peers können beliebig auftauchen und verschwinden

- Insbesondere in drahtlosen Netzwerken

● Probleme mit P2P im aktuellen Internet● Asymmetrische Verbindungen

- Download-Datenrate >> Upload-Datenrate (Faktor 10 bei DSL, UMTS)

● Adressvergabe- Oft nur eine IP-Adresse pro Teilnehmer

- Dienste auf mehreren Rechnern daher nicht direkt ansprechbar

- Bei mehreren Geräten ist NAT und Port-Mapping erforderlich


Probleme von P2P für Embedded Syst.● Ressourcenbeschränkungen

● Speicher: wenig Informationen verfügbar, wenig Cache/Buffer- Oft komplexe Software-Stacks, z.B. Sun JXTA

- zwei Größenordnungen zu groß für MSP430...

● Energie: ständiges Empfangen und Senden nicht möglich● Echtzeit: ständig wechselnde Wege zwischen Peers in drahtlosen

Netzen- Keine Vorhersage über Paketlaufzeiten machbar

● Netzwerk: Oft Netze mit niedriger Bandbreite- Wenige Daten pro Zeiteinheit

- Kanalkonkurrenz bei vielen Teilnehmern im Netz

● Verfügbarkeit: Peers nicht permanent verfügbar- Software muss mit Ausfällen und langen Wartezeiten zurechtkommen

- Ausfall eines Peers soll möglichst wenige Auswirkungen haben

- Redundanz ist machbar, aber teuer (Speicherplatz, Netzkapazität)


Einsatz von P2P in UbiComp● Paradebeispiel: Drahtlose Sensor-Netzwerke

● Aufgabe: Erfassung von Meßwerten, verteilt über eine Fläche● Herausforderung: Fehlen von Infrastruktur

- Keine Stromversorgung- Batteriebetrieb oder alternative Stromquellen (Solarzellen, Energy Harvesting)

- Optimierung auf niedrigen Energieverbrauch für lange Laufzeit

- Kein kabelgebundenes Netzwerk- Drahtlose Netzverbindung erforderlich (→ Energieverbrauch)

- P2P-Kommunikation und Selbstorganisation notwendig

● Herausforderung: Kosten- Hunderte oder tausende Sensorknoten im Einsatz

- Dadurch: günstige Komponenten notwendig- 8- oder 16-Bit Mikrocontroller (z.B. Atmel AVR, TI MSP430)

- Hardware auf Aufgabe spezialisiert

- Beispiel: Motes (UC Berkeley), Btnodes (ETH Zürich), ESB Embedded Sensor Boards (FU Berlin)


Protokolle● Vorherige Übung: SimpliciTI

● Spezialisierter Netzwerkstack, wenig Funktionalität● Proprietär: Kommunikation mit anderen Systemen nicht möglich

● Herausforderung: Offene Protokolle● Verschiedene Forschungsprojekte existieren● Ergebnis nicht absehbar

● Ist TCP/IP als offener Standard sinnvoll implementierbar?● Vorteile

- Bekannte Protokolle

- Skalierbar

- Einfache Schnittstelle zum Internet

● Nachteile- Codegröße – typ. TCP/IP-Implementierung: mehrere 10k LOC

- Komplexität: TCP-Implementierung aufwendig


TCP/IP in Linux-2.6.33● Statische Konfigurierung des TCP/IP-Stacks (KConfig)

● Unkomprimierte Binärgröße für i386

TCP/IP Networking (IPv4) 240 KB

The IPv6 Protocol 175 KB

IPv6: IPSec 262 KB

IP: IPSec 255 KB

IP: Multicast Routing 9 KBIP: Multicasting (IGMP) 7 KB

„size arch/x86/boot/compressed/vmlinux.bin“


# $OpenBSD: GENERIC,v 1.154 2010/03/22 […] $#

[…]

option INET # IP + ICMP + TCP + UDPoption ALTQ # ALTQ baseoption INET6 # IPv6 (needs INET)option IPSEC # Ipsec

[…]

option TCP_SACK # Selective Acknowledgements for TCPoption TCP_ECN # Explicit Congestion Notificationoption TCP_SIGNATURE # TCP MD5 Signatures#option TCP_FACK # Forward Acknowledgements for TCP

Linux – kein Einzelfall● BSD-Unix Derivate auch nur grob granular konfigurierbar

/usr/src/sys/conf/GENERIC


uIP – Micro IP [2]● Minimale TCP/IP Implementierung

● Ethernet, ARP, IPv4, TCP (nicht konfigurierbar)- Kein Sliding Window

● Portabel: Mehr als 20 Portierungen verfügbar (MSP430, AVR, ...)● Ausgelegt auf minimale Codegröße

- ca. 7500 LOC

- ca. 7 KB Binärgröße auf x86

● Sehr geringer RAM-Verbrauch, konfigurierbar zur Compilezeit- Minimal: wenige 100 Bytes

● Forschungsprojekt [2]● Ist TCP/IP-basierte Kommunikation für Sensornetze machbar?● Adam Dunkels, Swedish Institute of Computer Science (SICS)


lwIP – lightweight IP [2]● Ermöglicht Konfiguration der Protokolle

● Binärgröße von lwIP-1.32 für x86 (insgesamt 23,2 KB)

● Deutlich geringere Funktionalität als Linux und BSD● Kein Paketfilter, dyn. Routing, Tunneling, TCP-Options (SACK), ...

Basisfunktionen 5260 Byte

IPv4 1645 Byte

UDP 1334 Byte

ICMP 1194 Byte

TCP 13753 Byte


lwIP – Konfigurierbarkeit● Durch Präprozessor realisiert → „#ifdef-Hölle“

#if LWIP_NETIF_HWADDRHINT netif->addr_hint = NULL;#endif /* LWIP_NETIF_HWADDRHINT*/ } else#endif /* LWIP_UDPLITE */ { /* UDP */ LWIP_DEBUGF(UDP_DEBUG, ("udp_send: UDP packet length %"U16_F"\n", q->tot_len)); udphdr->len = htons(q->tot_len); /* calculate checksum */#if CHECKSUM_GEN_UDP if ((pcb->flags & UDP_FLAGS_NOCHKSUM) == 0) { udphdr->chksum = inet_chksum_pseudo(q, src_ip, dst_ip, IP_PROTO_UDP, q->tot_len); /* chksum zero must become 0xffff, as zero means 'no checksum' */ if (udphdr->chksum == 0x0000) udphdr->chksum = 0xffff; }#endif /* CHECKSUM_CHECK_UDP */ LWIP_DEBUGF(UDP_DEBUG, ("udp_send: UDP checksum 0x%04"X16_F"\n", udphdr->chksum)); LWIP_DEBUGF(UDP_DEBUG, ("udp_send: ip_output_if (,,,,IP_PROTO_UDP,)\n")); /* output to IP */#if LWIP_NETIF_HWADDRHINT netif->addr_hint = &(pcb->addr_hint);#endif /* LWIP_NETIF_HWADDRHINT*/ lwip-1.3.2/src/core/udp.c


lwIP – Querschneidende Belange● Implementierung einzelner Belange über viele Dateien

verstreut● Keine Trennung der Belange!

$ grep -c LWIP_IGMP \ `grep -l -r LWIP_IGMP *`api/api_lib.c:2api/tcpip.c:4api/sockets.c:8api/api_msg.c:2core/udp.c:4core/netif.c:10core/ipv4/igmp.c:2core/ipv4/ip.c:6core/init.c:5include/lwip/api_msg.h:4include/lwip/netif.h:2include/lwip/memp_std.h:2include/lwip/udp.h:2include/lwip/sockets.h:2include/lwip/api.h:4include/lwip/opt.h:5include/ipv4/lwip/ip.h:1include/ipv4/lwip/igmp.h:5

$ grep -c \ LWIP_NETIF_HWADDRHINT \ `grep -l -r \ LWIP_NETIF_HWADDRHINT *`core/tcp_out.c:12core/raw.c:4core/udp.c:8core/netif.c:2core/ipv6/ip6.c:2core/ipv4/ip.c:2include/lwip/netif.h:2include/lwip/opt.h:3include/ipv6/lwip/ip.h:2include/ipv4/lwip/ip.h:4netif/etharp.c:28


lwIP – Querschneidende Belange (2)● Problem der Konfigurierbarkeit

● Es muss Code an verschiedenen Stellen eingefügt werden● Kontrollfluss wird beeinflusst

1 2 3 4 5

Belang

1 2 3 4 5

Belang


CCiiAOAO – CiAO is Aspect-Oriented● Betriebssystemfamilie mit hochgradig konfigurierbarem

TCP/IP-Stack● Aspektgewahre Implementierung (AspectC++)

- CiAO Entwurfsprinzipien: welche waren das nochmal?

● Komplexität der Konfigurierbarkeit durch AOP reduziert● Lesbarkeit, Wartbarkeit und Wiederverwendbarkeit des Quellcodes

1 2 3 4 5 1 2 3 4 5 A

Belang Belang


Beispiel: Network Byte Order● Alle Internet-Protokollheader verwenden Big-Endian

● Konvertierung auf Little-Endian Systemen nötig (z.B. IA-32)

● BSD, Linux, uIP und lwIP → Makros● Zugriff auf Protokollheader über htons(uint16), ntohs(uint16), …

- Je nach Architektur leere Makros oder Konvertierungsfunktion

● Nachteile:● Schlecht lesbar durch häufiges Vorkommen der Makros● Fehleranfällig (Makro vergessen?)


tcp_in.c

etharp.c

etharp.h

icmp.cinet.c

inet_chksum.c

inet.hip_addr.h

ip.c

ip_frag.c

ip.h

tcp.c

tcp.h

tcp_out.c

udp.c

Byte Order Konvertierung in lwIP● Makros (htons, ntohs, htonl, ntohl)

● 210 Mal in 15 Dateien

● Querschneidender Belang● nicht separat implementiert


Byte Order Konvertierung in CiAO

aspect Little_Endian {

pointcut Network_to_Host_Short() = "% ipstack::IPv4_Packet::get%()" || "% ipstack::UDP_Packet::get%()" || "% ipstack::TCP_Segment::get%()";

advice execution(Network_to_Host_Short()) && result(res) : after(UInt16 res){ // convert return value *tjp->result() = ntohs(res); }};

● Paketklassen enthalten get- und set-Methoden● Sichtbare Übergänge

● Konvertierung bei set-Methoden ist analog


Variantenmodell in pure::variants


Speicherkosten CiAO IP-Stack (x86)


Senden Empfangen0

100

200

300

400

500

600

700

800

900

1000

uIPlwIPCiAO IP-StackLinux

Da

tenr

ate

[MB

i t/s]

TCP-Performance● Cross-over Gigabit Ethernet


Ubiquitäre Anwendungen● HP Cooltown

● Fragestellung: Schnittstelle Web ↔ „echte“ Welt● Konvergenz von Webtechnologien, drahtlosen Netzen und portablen

Geräten● Forschungsprojekt 2000–2004

● Idee● Verwendung von URLs zur Adressierung, Signalisierung

physikalischer Geräte, sensorisches „Entdecken“ von URLs● Schnittstelle zu ortsspezifischen Webservern● Ortsgewahres, ubiquitäres System zur Unterstützung „nomadischer“

Benutzer


Cooltown: Infrastruktur● x


Cooltown: Museumsführer● URLs von drahtlosen

„Beacons“ an Mobil-geräte gesendet

● Beacon: Infrarot-Transceiver i.d. Nähevon Bildern, Statuenetc.

● URLs verweisen aufWebinformationenzu jeweiligem Objekt

● Physikalische Zuord-nung: ein Beacon proExponat → eine URL

● Auslagerung v. Meta-Informationen ins Web


Cooltown: Kritik● Zu primitive Technik?

● Infrarot erfordert spezielle Hardware, störanfällig● Zu teuer: IR-Beacon pro phys. Präsenz erforderlich

● Alternativen?● Ausnutzen der Weiterentwicklung mobiler Endgeräte● Bluetooth: Nahbereichsfunk, z.B. in Mobiltelefonen

- Nachteil: weiterhin aktiver Sender pro phys. Präsenz erforderlich

● Digitalkamera: Sensoren von 1–8 Megapixel- In fast allen aktuellen Mobiltelefonen

- Auch in MP3-Playern (z.B. iPod nano)

- Vorteil: kein aktiver Sender mehr notwendig, nur visuelle Information

- Herausforderung: Codierung von Informationen, so dass wenig Rechenleistung erforderlich ist, um möglichst viel Information zur Verfügung zu stellen

- Komplexe Bilderkennungsverfahren oder Schrifterkennung via OCR auf eingebetteten Systemen nicht machbar


QR-Codes● Weiterentwicklung von (1D-)Barcodes● QR = „quick response“● zweidimensionaler Code (2D-Code)

● Entwickelt 1994 von japanischer Firma Denso Wave● Entwickelt zur Markierung von Baugruppen und Komponenten für

die Logistik in der Automobilproduktion

● Quadratische Matrix aus schwarzen und weißen Punkten● Binärdarstellung der kodierten Daten● spezielle Markierung in drei der vier Ecken gibt Orientierung vor

● Daten im QR-Code durch einen fehlerkorrigierenden Code geschützt● Selbst wenn bis zu 30% des Codes zerstört sind, kann

er noch dekodiert werden

● Text „QR Code“ in QR-Code:


QR-Codes: Details● Symbolelemente sind Quadrate

● Mindestens 21×21 und maximal 177×177 Elemente im Symbol● Max. Informationsgehalt: 23624 Bit (2953 Byte)

- Entspricht 7089 Dezimalziffern oder 4296 alphanumerischen Zeichen

● Patentiert● Aber: kommerzielle Nutzung des QR-Codes ist lizenzfrei

● möglichst hoher Kontrast wichtig, ideal: schwarz auf weiß- Auch (mehrere) Farben möglich auch mit mehreren Farben

- Code muss als Halbtonbild bzw. als Strichbild gesehen gleichmäßigen Kontrast aufweisen

● vier Fehlerkorrektur-Levels- Rekonstruktion von 7% bis

zu 30% beschädigter Daten

- Reed-Solomon-Codierung

(Quelle: Wikipedia)


QR-Codes: Beispiele● QR-Codes auf Häusern und Plakatwänden in Japan


QR-Codes: Anwendungen● Zusatzinformationen zu Zeitungsartikeln

● November 2007: „Welt“ Kompakt● QR-Code enthält Webadressen

mit weiteren Informationen zum jeweiligen Artikel

● Interaktive Lernerfahrung im Zoo [5]● Zusatzinformationen und Videos

zu versch. Tieren

● Codierung kompletter SMS● Nur noch Absenden erforderlich

→ kein Eintippen● z.B. für Premium SMS-

Dienste (Bestellungen, Gewinnspiele etc.)


QR-Codes: Anwendung (2)● Mobile Anwendungen für Android

● z.B. in Zeitschriftenartikeln, auf Webseiten etc.● Eintippen von URL oder Suche im Android Market: aufwendig

● Spezielle Scan-Software erforderlich● Liest und decodiert 2D-Barcodes → URL für Market● Ruft entsprechende Anwendung (z.B. Market, Browser) auf● Open Source: ZXing ("Zebra Crossing") → sourceforge

● Generierung● Viele Anwendungen, z.B.: http://zxing.appspot.com/generator/

https://addons.mozilla.org/en-US/firefox/addon/2780/

● Beispiel: App-Review-Webseiten:


Zusammenfassung● Internet & ubiquitäre Systeme

● Das Internet definiert die globale Infrastruktur zur Vernetzung● Wichtig für Interoperabilität von ubiquitären Systemen● Entscheidend für Realisierung von Ubiquitous Computing

● Protokolle für P2P und Netzwerkkommunikation● Herausforderungen: typische Embedded-Beschränkungen● Ansätze für eine Schnittstelle zum Internet: uIP, CiAO

● Ubiquitäre Anwendungen● Verbinden physikalische Welt mit virtueller Welt des Internet● Schnelle, einfache Verbindung durch „Tags“● Hardware-Entwicklung (Kameras) machen tagging einfach, schnell

und kostengünstig


Referenzen1. Leonard Kleinrock. An Internet vision: the invisible global

infrastructure. Ad Hoc Networks, 2003

2. Adam Dunkels: „Full TCP/IP for 8-Bit Architectures“In Proceedings of the first international conference on mobile applications, systems and services (MOBISYS 2003), San Francisco, May 2003

3. Margaret Fleck et al: „Ubiquitous Systems in Interactive Museums“http://www.hpl.hp.com/research/papers/2002/ubiquitous.pdf

4. John Barton, Tim Kindberg: „The Cooltown User Experience“http://www.hpl.hp.com/techreports/2001/HPL-2001-22.pdf

5. Jose Rouillard, Mona Laroussi: „PerZoovasive: contextual pervasive QR codes as tool to provide an adaptive learning support“In Proceedings of CSTST 2008, Cergy-Pontoise, France

http://www.hpl.hp.com/research/papers/2002/ubiquitous.pdf

http://www.hpl.hp.com/techreports/2001/HPL-2001-22.pdf

software ubiquitärer systeme - ess.cs.tu-dortmund.de · homes and offices across the country“....

Documents