Technische Universitat MunchenFakultat fur Informatik

Lehrstuhl fur Netzwerkarchitekturen, Telematik, Telekooperation (I 8)Prof. A. Feldmann

Ausarbeitung

zum

Systementwicklungprojekt

Entwicklung eines UPnP SDK

Aufgabensteller: Prof. A. Feldmann

Betreuer: Dipl.-Inf. M. WischySiemens AG

Bearbeiter: Stefan Gersmann, 2216997Ungererstraße 66, 80805 MunchenDiplom Informatik im 10. Fachsemester

Eingereicht am: 15. Juni 2004

Inhaltsverzeichnis

Abbildungsverzeichnis 3

1 Einleitung 41.1 Uberblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2 Hintergrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3 Aufgaben im Rahmen des SEP . . . . . . . . . . . . . . . . . . . 5

2 Das UPnP Protokoll 62.1 Uberblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 Der UPnP Protokol–Stack . . . . . . . . . . . . . . . . . . . . . . 6

3 Weiterentwicklung einer UPnP-Implementierung 93.1 Uberblick uber die existierende Implementierung . . . . . . . . . . 93.2 Notwendinge Anderungen an der Implementierung des UPnP–

Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.3 Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4 Entwicklung eines Code–Generators fur UPnP–Devices und ControlPoints 174.1 Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.2 Control Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.3 Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.4 Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5 Entwurf und Implementierung eines UPnP Gateway 215.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215.2 Realisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

6 Fazit 23

Literaturverzeichnis 25

2

Abbildungsverzeichnis

1 UPnP Kontrollfluß . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Der UPnP Protokoll Stack . . . . . . . . . . . . . . . . . . . . . . 83 Uberblick uber das Modell (vereinfacht) . . . . . . . . . . . . . . 94 Uberblick uber die Schnittstellen zur Implementierung von spezi-

ellen Control Points und Devices . . . . . . . . . . . . . . . . . . 105 Uberblick uber die Pakete . . . . . . . . . . . . . . . . . . . . . . 116 Das Objekt–Modell fur Complex Types . . . . . . . . . . . . . . . 157 Der verwendete additive Hash–Algorithmus . . . . . . . . . . . . . 168 Aufbau der SSDP–Notify Nachricht . . . . . . . . . . . . . . . . . 179 Beispiel einer Aktions-Behandlungsroutine . . . . . . . . . . . . . 1810 Beispiel der Implementierung einer Proxy-Methode . . . . . . . . 1911 Die Klassenstrukur des generierten Codes am Beispiel eines Bina-

ryLightDevice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2012 Architektur des UPnP Gateway Services . . . . . . . . . . . . . . 22

3

1 Einleitung

Gegenstand dieses Systemsentwicklungsprojektes (SEP) ist die Erweiterung einerexistierenen Implementierung des UPnP Protokoll-Stacks, sowie die Erstellung ei-nes Werkzeuges zur automatischen Generierungvon Quellcode fur die Implemen-tierung von UPnP Geraten. Desweiteren wurde eine prototypische Implementie-rung eines sogenannten UPnP Gateways erstellt, auf die spater noch genauereingegangen wird.

Das SEP wurde bei Siemens Corporate Technology – Abteilung Software & En-gineering – im Zeitraum von Dezember 2003 bis Mai 2004 durchgefuhrt undbetreut.

1.1 Uberblick

Der Trend, daß viele unterschiedliche, vernetzte und oft auch mobile Gerate zu-nehmende Verbreitung finden, wurde schon vor einigen Jahren erkannt. Dies wirdbegunstigt, durch eine de facto Standardisierung der Netzwerke auf die Nutzungvon Internetprotokollen, als auch die kostengunstige Verfugbarkeit neuer Tech-nologien wie Wireless LAN. Dabei hat man auch erkannt, daß durch den Ein-satz mobiler Gerate, und die Verbreitung konventioneller vernetzter Gerate inUmgebungen, die durch nicht-technikaffine Benutzter gepragt werden, die Frageder Konfiguration und Administration dieser heterogenen Netzwerktopologien einzunehmendes Problem darstellt. Die Interoperabilitat dieser Gerate wird durchproperitare Protokolle auf der TCP/IP- und Andwendungsebene des ISO/OSI-Schichtenmodells verhindert, oder erschwert.

Aus diesem Grund wurden von verschiedenen Firmen und Konsortien mehre-re Middelware-Technologien entwickelt, die das Deployment, Dienstlokalisierungund teilweise auch eine Gerateinteraktion ermoglichen. Zu diesen Technologiengehoren unter anderem JINI von Sun Microsystems (Sun Microsystems, 2004),Salutation (The Salutation Consortium, 1999), das Service Location Protokoll,Rendezvous von Apple Computers (Zeroconf IETF Working Group) und auchUPnP, welches initial von Microsoft enwickelt wurde und nun im UPnP Forumbetreut wird (UPnP Consortium, 2004b). Diese Technologien haben gemeinsam,daß sie es ermoglichen sollen, Gerate ohne Interaktion des Benutzers in Netzwer-ken einzusetzten (sogenanntes plug and play).

Wahrend JINI hier eine Vorreiterrolle ubernommen hatte, hat es sich doch nichtdurchsetzten konnen – wahrscheinlich wegen seiner hohen Komplexitat und diestarke Kopplung an die JAVA-Laufzeitumgebung. Rendevous ist eine Erweite-rung des Internet DNS-Systems auf ad-hoc Umgebungen (mDNS ) und spezifi-ziert ein Protokoll zur automatischen IP-Konfiguration, fur den Fall, daß eine

4

solche Konfiguration nicht fest vorgegeben ist (z.B. durch statische IP-Adressen,oder einen DHCP-Server). Rendezvous gibt allerdings kein Protokoll als Basisder Gerateinteraktion vor. Das Service Location Protokoll, ist ein einfaches Pro-tokoll zur Dienstlokalisierung, das vor allem im Linux/Unix-Umfeld Verbreitunggefunden hat. UPnP ermoglicht die automatische Konfiguration, Diensteerken-nung und Interaktion auf Basis verbreiteten Technologien – wie AutoIP (analogzu Rendezvous), HTTP und SOAP – die entsprechend erweitert wurden.

1.2 Hintergrund

Die Aufgaben im Rahmen des SEPs basieren auf einer Implementierung desUPnP–Standards der Version 1.0, die bei Siemens Corporate Technology erstelltwurde. Dazu gehoren auch eine Beispielanwendung und Diagnosetools. Diese Im-plementierung ist in der Programmiersprache Java erstellt und basiert auf derJava 2 Mobile Edition Laufzeitumgebung in der sog. Connected Device Configu-ration. Die Configuration spezifiziert die verfugbaren Schnittstellen (APIs), diein diesem Fall großtenteils auf denen der Java 2 Standard Edition in der Version1.3 basieren. Weitere Merkmale sind eine eingschrankte Leistungsfahigkeit undbeschrankter zur Verfugung stehender Arbeitsspeicher.

1.3 Aufgaben im Rahmen des SEP

Die Aufgaben im SEP beziehen sich auf die Weiterentwicklung des bestehendenUPnP-SDKs. Dazu gehorten:

• Die Anpassung und Erweiterung des UPnP-Stacks gemaß der Version 1.1der UPnP-Spezifikation (siehe Abschnitt 3).

• Entwicklung eines Quellcode-Generators, der aus gultigen Device- undService-Beschreibungen automatisch die Implementierung eines Devicesund Control Points inklusive der Stubs und des Skeletons generiert, sodaß lediglich die auf Methoden projizierten Actions implementiert werdenmussen (siehe Abschnitt 4).

• Eine prototypische Implementierung eines Gateway-Devices und eines ent-sprechenden Control Point, so daß entsprechend dem Proxy–Prinzip dieUPnP-Devices in einem Netzwerk transparent uber eine gesicherte Verbin-dung mit einem Gateway-Device lokalisiert und kontrolliert werden konnen(siehe Abschnitt 5).

5

2 Das UPnP Protokoll

2.1 Uberblick

Das UPnP-Protokoll basiert auf TCP/IP und baut auf die Internet-ProtokolleTCP und UDP auf der Netzwerkebene und HTTP(U) auf der Anwendungsebeneauf. Das Protokoll erlaubt es Geraten ein Netzwerk dynamisch zu betreten undzu verlassen, ohne ungewollte Zustandsinformationen zu hinterlassen. Es soll dieautomatische Konfiguration, die Ankundigung und Lokalisierung, und den Kon-trollfluss zwischen so genannten UPnP Devices und Control Points ermoglichen.Ein Device (manchmal auch Controlled Device genannt) wird von einem ControlPoint gesteuert und agiert ublicherweise als Server. Ein UPnP Device kann einreales Gerat reprasentieren, es konnen aber auch mehrere UPnP Devices in einemGerat als so genannte Embedded Devices implementiert sein. Der Control Pointkann die Devices im Netzwerk entdecken und steuern, sowie Benachrichtigungenfur das Eintreten von Ereignisse abonnieren. Ein reales Gerat kann auch gleichzei-tig ein Device und einen Controlpoint implementieren. So wird auch die Kommu-nikation von Geraten untereinander ermoglicht (Peer-to-Peer-Kommunikation).

Da die definierten Protokolle auf TCP/IP und HTTP basieren sind Implementie-rungen von UPnP betriebssystemunabhangig, leichtgewichtig und interoperabel.Sollte ein Gerat keinen IP-Stack unterstutzen, sollte eine UPnP-Implementierung(wenn gewunscht) uber eine sog.

”Brucke“ realisiert werden.

2.2 Der UPnP Protokol–Stack

Das UPnP-Protokoll beschreibt mehrere Schritte fur den erfolgreichen Netzwerk-betrieb (siehe Abb. 1).

Der erste Schritt ist besteht aus der Konfiguration des Netzwerkinterfaces. Hierzuwird entweder ein im Netzwerk befindlicher DHCP-Server verwendet, oder – fallskein DHCP-Server vorhanden ist – das AutoIP -Protokoll, welches in ZEROCONFWorking Group (2004) beschrieben ist.

Im zweiten Schritt wird das Simple Service Discovery Protokoll (SSDP) als Pro-tokoll zur Servicelokalisierung (Discovery) verwendet (siehe Abb. 2). SSDP machtein Device und seine Services bekannt und dient der Erkennung anderer Devi-ces im Netzwerk. SSDP benutzt hier HTTP over multicast and unicast UDP(HTTPMU) und definiert spezielle HTTP-Header Erweiterungen.

Ein Device, das das Netzwerk betritt sendet SSDP-Advertisement-Nachrichtenuber multicast UDP (ssdp:alive) fur das Device, die Embedded Devices undseine Services, die die Device- und Service-Typen enthalten. Wenn ein Control

6

1. Addressing

2. Discovery

3. Description

4a. Control 4b. Eventing 4c. Presentation

Abbildung 1: UPnP Kontrollfluß

Point das Netzwerk betritt, kann dieser eine multicast SSDP-Search-Nachrichtversenden und die Devices, auf die der angeforderte Typ zutrifft senden per uni-cast UDP die SSDP-Advertisement-Nachrichten an den Control-Point. Die SSDP-Nachrichten enthalten spezielle Header Erweiterungen, in denen essentiellle In-formationen uber die Devices und Services, wie z.B. Typ, Identifikator (UUID)und eine Gultigkeitsdauer spezifiziert werden konnen. Das Device sendet nun pe-riodisch erneute

”alive“-Nachrichten, um das Advertisement zu erneuern. Sollte

vor Ablauf der Gultigkeitsdauer keine Erneuerung des Advertisements vollzogenwerden, wird davon ausgegangen, daß das sich das Gerat nicht mehr (aktiv) imNetwerk befindet.

Im dritten Schritt kann ein interessierter Control Point die Beschreibung desDevices und der Services laden. Die Beschreibung ist uber eine URL, die in denSSDP-Nachrichten spezifiziert wurde, erreichbar und liegt im XML-Format vor.Im

”Device Description Document“ (DDD) wird das Device beschrieben. Dieses

Dokument enthalt herstellerspezifische Informationen, wie z.B. Modell-Namenund Version, eine Liste der eingebetteten Devices und Service und die (Service-spezifischen) URLs fur Control, Eventing und Presentation.

In der Service-Beschreibung – dem”Service Control Protocol Document“ (SCPD)

– werden eine Liste von aufrufbaren Aktionen (Actions) mit den zugehorigenParametern und Ruckgabewerten (Arguments), und Variablen (State Variables)ubergeben, die den Status des Services zur Laufzeit modellieren. Jeder Parameterund Ruckgabewert ist hier mit einer State Variable verknupft und somit typisiert.

Nachdem ein Control Point die Beschreibung empfangen und ausgewertet hat,kann er zum

”Control“-Schritt ubergehen und Aktionen ausfuhren. Dazu sen-

7

Abbildung 2: Der UPnP Protokoll Stack

det er eine SOAP-Nachricht per HTTP an die Control-URL des entsprechendenServices (die in der Device-Beschreibung spezifiziert wurde). In dieser Nachrichtwerden die aufzurufende Aktion und die Parameter im SOAP-Body spezifiziert.In der HTTP-Response wird eine SOAP-Nachricht ubergeben, in der die Ruck-gabewerte angegeben sind. Sollte sich durch die Aktion der Zustand des Devicesandern, werden die entsprechenden State Variables modifiziert.

Ein Control Point kann auch Benachrichtigungen abonnieren, die angestoßen wer-den, wenn sich der Wert einer der State Variables andert. Dies erfolgt uber einProtokoll namens General Event Notification Architecture (GENA) welches eben-falls HTTP und XML basiert. Um die Benachrichtigungen zu abonnieren sen-det der interessierte Control Point einen speziellen HTTP-Request (SUBSCRIBE)an das Device. Die URL dieses Requests wird wie beim Control in der Device-Beschreibung angegeben. In dieser Nachricht wird in einem HTTP-Header eine(oder mehrere) Callback-Addresse ubergeben, an die die Events ausgeliefert wer-den, sowie eine Lease-Time nach der das Abonnement auslauft, falls es nicht vorderen Ablauf erneuert wird. Sobald sich der Zustand einer State Variable einesServices andert, werden die Control Points, die Benachrichtigungen abonnierthaben durch eine Event-Nachricht in einem XML-Format benachrichtigt, in derdie betroffenen State Variables und ihre aktualisierten Werte ubergeben werden.Dadurch kann der Status eine Devices auf mehreren Control Points konsistentgehalten werden.

Schließlich kann ein Device noch eine sog. Presentation Page-URL spezifizieren.Von dieser URL kann ein Browser eine (X)HTML-Seite laden und das Devicekann – abhangig von seinen Fahigkeiten – uber diese Seite kontrolliert werden.

8

Die URL kann aber auch auch eine externe Seite zeigen.

In Abb. 2 werden die verwendeten Protokolle in einer Ubersicht dargestellt. Aus-gehend vom DDD und den SCPDs konnen im UPnP-Forum Profile fur eine Klas-se von UPnP-Geraten standardisiert werden. Im Device Control Protocol (DCP)werden dann das Verhalten, das Device und die Embedded Devices und die Ser-vices definiert.

3 Weiterentwicklung einer UPnP-Implementierung

3.1 Uberblick uber die existierende Implementierung

Argument()

getName()

getDirection()

isReturnValue()

getRelatedStateVariable()

getValue()

Argument getServices()

getDevices()

addDevice()

addService()

getDeviceType()

getDeviceVersion()

getModelName()

getUDN()

getPresentationURL()

isRootDevice()

getLeaseTime()

Device

StateVariable()

getName()

getDataType()

getDefaultValue()

isSendingEvents()

getAllowedValues()

getValue()

getAllowedValueRange()

StateVariable

getDevice()

addAction()

getActions()

addStateVariable()

getStateVariables()

getServiceType()

getMaxVersion()

getServiceID()

getControlURL()

Service

Action()

getService()

getName()

setName()

getArguments()

Action

ArgumentList()

addElement()

size()

getOutputArguments()

getInputArguments()

ArgumentList

# device

0..1

# service

0..1

# arguments0..1

Abbildung 3: Uberblick uber das Modell (vereinfacht)

In der existierenden Implementierung modellieren die Hauptklassen Device,Service, Statevariable, Action und Argument ein abstraktes UPnP-Deviceund die Services (siehe Abb. 3).

Die Implementierung des konkreten Devices und Control Points ist jeweils un-abhangig realisiert.

9

getServices()

getDevices()

addDevice()

addService()

getDeviceType()

isRootDevice()

Device

getDevice()

addAction()

getActions()

addStateVariable()

getStateVariables()

getServiceType()

Service

HostedDevice()

announce()

setAnnounced()

processPostRequest()

processGetRequest()

getRequestHandler()

generateConfigID()

HostedDevice

ProxyDevice()

getControlPoint()

ProxyDevice

HostedService()

setActionListener()

processActionRequest()

getSubscriptionTimeout()

getSubscriptions()

addStateVariable()

HostedService

ProxyService()

ProxyService()

createStateVariable()

createStateVariable()

submitActionRequest()

requestSubscription()

cancelSubscription()

ProxyService

shutDown()

createDevice()

addUPnPEventListener()

addUPnPSearchListener()

searchAsync()

ControlPoint

shutDown()

announce()

announce()

remove()

addWebRequestHandler()

getWebRequestHandler()

DeviceHost

# device

0..1

# controlPoint0..1 - deviceHost0..1

Abbildung 4: Uberblick uber die Schnittstellen zur Implementierung von speziel-len Control Points und Devices

Die Klasse ControlPoint ist als Singleton (Gamma et al., 1995) realisiert undsteuert zentral alle Aufgaben eines Control Points. Es bietet eine Schnittstelle zurSuche nach UPnP-Devices und zum Erzeugen eines Proxies fur ein Device. DieKlassen ProxyDevice und ProxyService, die von Device und Service abgelei-tet sind implementieren ein Device und einen Service auf der Control Point-Seite(siehe Abb. 4). Diese Klassen konnen verwendet werden, um ein entferntes Deviceanzusprechen. Der Zustand der State Variables wird fur den Anwender transpa-rent konsistent gehalten. Es steht das Interface UPnPStateChangedListener zurVerfugung, um eine Benachrichtigung bei Zustandsanderungen zu ermoglichen.

Die Klasse DeviceHost – die ebenfalls als Singleton implementiert ist – ist einContainer fur konkrete Devices und ihre Services. Sie ubernimmt zentrale Aufga-

10

ben, wie das Announcement der Devices und Services und behandelt die SOAP-und GENA-Requests, die es bei Bedarf an die Services weiterleitet. Die Klas-sen HostedDevice und HostedService implementieren generische UPnP-Devicesund bieten eine Schnittstelle zur Implementierung der Actions eines Services undder

”Presentation Page“. Hierfur werden die Interfaces UPnPActionListener und

UPnPPresentationPageHandler zur Verfugung gestellt, deren Implementierungbei einem HostedService, bzw. HostedDevice angemeldet werden konnen. Im Kon-struktor der Klasse HostedDevice kann eine URL ubergeben werden, die auf einDevice Description Document verweist, so daß das Device und die Services ausden in diesen Dokumenten enthaltenen Informationen erzeugt werden.

SSDP

DH CP

SOAP

DH CP

GENA

DH CP

WebServer

UPnPPresentationPageHandler

DeviceHost

ControlPoint

Implementiert UPnPPresentationPageHandler und UPnPActionListener

UPnPActionListener

CustomDeviceImplementation

Abbildung 5: Uberblick uber die Pakete

Die grundlegende Funktionalitat und die Implementierung der SSDP–,GENA–,und SOAP–Protokolle sind auf verschiedene Pakete aufgeteilt. Hier sind wiederdie Implementierungen der Device–, bzw. Control Point–Funktionalitat weitest-gehend voneinander getrennt (sofern dies Sinn machte) (siehe Abb. 5).

Der Webserver nimmt SOAP–, GENA– und Presentation Page–Requests an denDeviceHost entgegen und verteilt die Anfragen an die entsprechenden Hand-ler. Die zentralen Klassen sind hier auf DeviceHost–Seite fur SOAP– die KlasseDeviceRequestHandler, die einen SOAP–Request an den entsprechenden Ser-

11

vice weiterleitet und fur GENA–Requests die Klasse DHGenaSocket, die GENA–Requests bearbeitet und die Subscriptions verwaltet. Die DeviceHost–Instanzenthalt eine Instanz der Klasse DHSsdpSocket uber die die SSDP–Komponentezuganglich ist, die das SSDP–Protokoll implementiert. Uber diese Komponnentekonnen ein Root–Device und seine Embedded Devices und Services angekuendigtwerden und die SSDP–Search–Requests werden hier bearbeitet.

Die Control Point–Funktionalitat der SOAP–, GENA–, und SSDP–Protokolle istuber die Klassen CPSoapSocket, CPGenaSocket und CPSsdpSocket verfugbarund wird von den Klassen ControlPoint, ProxyDevice und ProxyService fur denAnwender transparent verwendet.

3.2 Notwendinge Anderungen an der Implementierung desUPnP–Frameworks

Im Zuge der Erweiterung des Stacks von UPnP 1.0 auf UPnP 1.1 ergaben sichmehrere Anderungen in der Spezifikation der einzelnen Komponenten, die zuimplementieren waren.

3.2.1 Der Discovery–Mechanismus

Im SSDP–Protokoll wurden mehrere Anderungen vorgenommen, die vor allem diePerformance und Skalierbarkeit des Discovery– (und Description–) Mechanismus,sowie die Ubertragung einiger Zustandsinformationen, betreffen.

Um die unnotige wiederholte Ubertragung des DDDs und der SCPDs zu ver-hindern wurde in die SSDP–Announcement Nachrichten der zusatzliche HeaderCONFIGID.UPNP.ORG eingefugt, in dem ein Integerwert die Konfiguration einesDevices und seiner Services eindeutig kennzeichnet. Dieser Wert bleibt auch ubermehrere Announcements persistent, solange sich das DDD und die SCPDs nichtandern. Diese Maßnahme fur zu einer deutlich niedrigeren Belastung der Devi-ces und des Netzwerkes nach dem Announcement eines Devices, da sich dieseDokumente ublicherweise selten oder gar nicht andern.

Um einen unplanmaßigen Absturz eines Devices (ohne Senden der”Device Un-

available“–Nachrichten) zu erkennen, wurde das Header-Feld BOOTID.UPNP.ORG

eingefuhrt, in dem ein Integerwert den dynamischen Zustand eines Devices iden-tifiziert. Dieser Wert wird bei jedem Boot-Vorgang neu gesetzt (ublicherweise dieSystemzeit in Sekunden).

Um eine”Liveliness“–Uberprufung per SSDP zu ermoglichen, ohne das Netz-

werk durch Multicast–Search Nachrichten zu belasten muß jeden UPnP–DeviceUnicast SSDP–Nachrichten behandeln. Der Standard–UDP–Port des Sockets ist

12

1900. Sollte der Port schon belegt sein, muß das Device den zu verwendendenPort im SEARCHPORT.UPNP.ORG bekanntmachen.

Zusatzlich wird in der SSDP–Anouncement Nachricht noch die Version des Devi-ces oder Services im Headerfeld MAXVERSION.UPNP.ORG spezifiziert, um das De-vice oder den Service aus Grunden der abwartskompatibilitat mit der niedrigstenunterstutzten Version im

”Notification Type“ Headerfeld ankundigen zu konnen.

Da UDP bekanntermaßen keine Ubermittlung der Pakete garantiert, wurden beiUPnP 1.0 alle Announcement–Nachricht im Abstand von einer Sekunde dreimalubertragen. Diese Ubertragung wurde nach einem festgelegten Zeitintervall (ubli-cherweise 1800 Sekunden) wiederholt. Um die Netzwerkbelastung zu veringernund glichzeitig eine schnellere Erkennung von Devices durch Control Points ohneexplizite Search–Nachrichten zu ermoglichen werden diese Nachrichen jetzt nachdem erstmaligen Announcement uber die bisherige Zeitspanne verteilt gesendet.

3.2.2 Complex Types

In UPnP 1.0 ist die Typisierung von State Variables (und damit auch der Pa-rameter der Actions) auf einen Satz von elementaren Datentypen beschranktgewesen. Sollten komplexere Datentypen verwendet werden, so mussten dieseentsprechend z.B. als String codiert werden (z.B. per Base64–Codierung oder alsEscaped XML). Um diese Beschrankung zu umgehen, wurde die Spezifikationdes SCPDs so angepasst, daß es moglich ist, als State Variable–Typen ComplexTypes zu definieren und in SOAP– und GENA– Nachrichten zu verwenden. EinComplex Type wird fur gewohnlich in einer XML Schema Definition–Instanz de-finiert. Dies fuhrt zu einer erheblich erhoten Flexibilitat bei der Definition vonServices.

3.2.3 IPv6

Die Spezifikation der Protokolle wurde um die Kompatibilitat zu IPv6 erweitert.Dies betrifft vor allen Dingen das SSDP–Protokoll, da sich aufgrund der Gultig-keitsbereiche der IP–Addressen und der Multicast–Gruppen Anderungen ergebenund die IPv6–Addressen ein anderes Format haben.

3.2.4 HTTP

Wahrend von UPnP 1.0 nur eine Kompatibilitat zu HTTP 1.0 verlangt, setztUPnP 1.1 eine HTTP 1.1–kompatibele Implementierung voraus. Darunter falltunter anderem eine Implementierung von Chunked–Encoding.

13

3.2.5 SOAP

Einige kleiner Anderungen wurden am SOAP–Message Format vorgenommen,um eine SOAP 1.1 Kompatibilitat zu erreichen.

3.2.6 Description

Fur das Device Description Document (DDD) und das Service Control ProtocolDocument (SCPD) wurden XSL-Schemata erstellt, um eine WS-I Kompatibilitatzu erreichen. Zusatzlich wurde in das DDD dem <device> – Element ein Attributhinzugefugt, in dem die ConfigID des Dokuments angegeben ist.

3.3 Implementierung

3.3.1 Anforderungen

Die in Abschnitt 3.2 beschriebenen Anderungen waren in die existierende Im-plementierung zu intergrieren. Dabei sollten die entstehenden Interfaces nichtverandert werden. Erweiterungen waren nur zulassig, wenn die Abwartskompa-tibilitat gewahrt wurde. Gleichzeitig sollte die Implementierung kompatibel zuJava 2 Micro Edition im CDC Profil sein und ein moglichst geringer Resourcen-verbrauch gewahrt werden.

Auf Details der Implementierung soll hier nur soweit eingegangen werden, als daßsich großere Anderungen, Probleme oder Besonderheiten ergeben haben.

3.3.2 Complex Types

Um generische Complex Types zu unterstutzen musste ein DOM -ahnliches Mo-dell implementiert werden, welches als Datenstruktur fungierte. Hier wurde dieabstrakte Klasse Node implementiert, von der die Klassen ComplexType, Elementund CharData abgeleitet wurden. Dies entspricht dem Composite–Pattern nach(Gamma et al., 1995) (siehe Abb. 6).

Zusatzlich musste die Klassen StateVariable und Argument und die Parser desSCPD um die Unterstutzung von Complex Types erweitert werden. Anderungenwaren auch in den Parsern der SOAP– und GENA– Nachrichten notig. Der exi-stierende XML–Parser war ein SAX–Parser, so daß eine direkte Umstetzung inein DOM–Modell nicht moglich war. Es war jedoch trotzdem relativ einfach, dieUmsetzung mittels eines Kellers zu erreichen.

14

getNode()

size()

NodeList

CharData()

getType()

getValue()

getXML()

setValue()

CharData

Element()

addAttribute()

getAttribute()

getName()

getType()

getXML()

setChildren()

Element

ComplexType()

ComplexType()

getDataType()

getName()

getType()

getXML()

setChildren()

setDataType()

setName()

ComplexType

addChild()

getAttribute()

getChild()

getChildByTagName()

getChildCount()

getChildren()

getDataType()

getFirstChild()

getName()

getType()

getValue()

getXML()

isLeaf()

getParent()

setParent()

Node

- parent

1

- children0..*

Abbildung 6: Das Objekt–Modell fur Complex Types

3.3.3 IPv6

Um eine IPv6-Kompatibilitat zu erreichen waren signifikante Anderungen in derSSDP– und GENA–Implementierung vonnoten. Dies resultierte vor allem aus derNotwendigkeit mehrere Netzwerk-Interfaces und IP–Addressen zu unterstutzen.Da die SSDP–Nachrichten nur einmal generiert wurden mußten fur jedes Inter-face die Nachrichten mit den jeweiligen IP–Addressen generiert werden. Zudemmussten mehrere Server Socket verwendet werden, um nachvollziehen zu konnen,uber welches Interface SSSP–Search Nachrichten empfangen wurden um in denResponse–Nachrichten die korrekte IP–Addresse verwenden zu konnen. Die Pro-blematik, daß non-blocking IO von Java 2 Micro Edition nicht unterstutzt wird,fuhrte leider dazu, daß hierzu mehrere Threads verwendet werden mußten.

Auch aufgrund des unterschiedlichen Formates von IPv4 und IPv6–Addressenwaren einige Anderungen notwending.

15

public void add(String s) {for (int i = 0; i < s.length(); i++)

hash = ((hash << 5) + hash) + (byte)s.charAt(i);}

public void add(StringBuffer s) {for (int i = 0; i < s.length(); i++)

hash = ((hash << 5) + hash) + (byte)s.charAt(i);}

Abbildung 7: Der verwendete additive Hash–Algorithmus

3.3.4 Discovery & Description

Die meisten Anderungen am SSDP–Protokoll ließen sich ohne großeren Aufwandimplementieren. Die sog. CONFIGID der Description–Dokumente wurde durcheinen Hashalgorithmus realisiert. Leider ließ sich aus Performance–Grunden derinterne String–Hash von Java nicht verwenden, da zuerst die unterschiedlichenDokumente zu einem String hatten zusammengefugt werden mussen. Daher wur-de ein einfacher, robuster additiver Hash-Algorithmus verwendet (siehe Abb. 7).

Um die Description XML–Dokumente zwischenzuspeichern und unnotige HTTP–Requests zu vermeiden wurde das Laden der Dokumente intern uber einen Proxyrealisiert. Dieser Proxy ladt und speichert die Dokumente (sofern noch nicht vor-handen) im Dateisystem und verwaltet die Meta–Daten – zu denen die ConfigIDgehort – in einer seperaten XML–Datei. Die Dokumente werden fur eine konfi-guriertbare Zeitspanne aufbewahrt und nach dieser Zeitspanne entfernt. Da dieAPI nicht verandert werden sollte, aber nur die Description–URL an die Factory–Methode zum Erzeugen von Proxy Devices ubergeben wurde, wurde das interneModell so erweitert, daß nachtraglich eine Zuordnung von Description–URL zueiner Gerate–ID und ConfigID moglich ist.

3.3.5 HTTP

Um die Implementierung von HTTP chunked encoding in den Stack zu integrierenmußten die HTTP – Requests und Responses in den einzelnen Komponeneten –deren Implementierung bisher jeweils unabhangig implementiert waren – gekap-selt werden. Hierzu wurde das Einlesen von HTTP–Requests und Responses indie Klasse HTTPInputReader verlagert und die Requests wurden nochmals in derKlasse HTTPRequest gekapselt.

16

NOTIFY * HTTP/1.1 HOST: 239.255.255.250:1900CACHE-CONTROL: max-age = seconds until advertisement expiresLOCATION: URL for UPnP description for root deviceNT: search targetNTS: ssdp:aliveSERVER: OS/version UPnP/1.1 product/versionUSN: advertisement UUIDBOOTID.UPNP.ORG: number increased each time device reboots\

(can be boot time or counter)CONFIGID.UPNP.ORG: number used for caching description informationMAXVERSION.UPNP.ORG: number identifies highest version of\

announced device/serviceSEARCHPORT.UPNP.ORG: number identifies port on which device\

responds to unicast MSEARCH

Abbildung 8: Aufbau der SSDP–Notify Nachricht

4 Entwicklung eines Code–Generators furUPnP–Devices und Control Points

Um die Entwicklung von UPnP Devices und Control Points zu vereinfachen undzu beschleunigen und gleichzeitig den Support–Aufwand zu verringern, sollte einCode–Generator entwickelt werden. Ausgehend von den DDDs und den entspre-chenden SCPDs sollten generiert werden:

1. Ein Interface fur jeden Servicetyp, in dem Aktionen auf Methoden abgebil-det sind;

2. ein lauffahiges UPnP Device, die Implementierung des InterfacesUPnPActionListener fur jeden Service des Devices – verantwortlich furdas Marschalling/Unmarshalling der Parameter und den Aufruf der Imple-mentierung des Services – und eine

”Blanko“-Implementierung des Service-

Interfaces;

3. ein Gerust fur eine Controlpoint-Implementierung und Proxies fur jedenService des Devices, die das entsprechende Service-Interface implementie-ren.

Hierbei mussen mehrere Aspekte berucksichtigt werden. Naturlich werden fur dieImplementierung eines UPnP Devices und Control Points die generischen Klassendes Stacks verwendet. Diese mussen jedoch initialisiert und konfiguriert werden.Gleichzeitig sollen aber auch einige Standardaufgaben, wie die Implementierungder Interfaces UPnPSearchListener und UPnPEventListener, automatisiert wer-den.

17

// Handle action: setTargetif (action.getName().equalsIgnoreCase("setTarget")) {

try {// Input Parametersboolean newTargetValue = SOAPHelper.convertToBoolean(

inArgumentList.getArgumentByName("newTargetValue").getValue());

// Call service implementation methodservice.setTarget(newTargetValue);

} catch (Exception e) {throw new SOAPException(SOAPHelper.INVALID_ARGS,

"Exception while processing. Cause: " + e.getMessage());}

}

Abbildung 9: Beispiel einer Aktions-Behandlungsroutine

Die in UPnP verwendeten einfachen Datentypen konnen weitestgehend in JavaDatentypen umgesetzt werden. Da UPnP Actions mehrere Ruckgabewerte ent-halten konnen, muß fur Aktionen mit mehr als einem Ruckgabewert noch eineContainer-Klasse generiert werden.

4.1 Device

Ein Device kann soweit generiert werden, daß lediglich die Methoden der Servicesimplementiert werden mussen.

Hierzu wird fur jeden Service die Implementierung des InterfacesUPnPActionListener generiert. In der Methode processActionRequest(ActionupnpAction) wird die zu behandelnde Aktion ubergeben. Fur die auszufuhrendeAktion werden die Parameter als Strings extrahiert, mit Hilfe von Standard-Javamethoden oder Hilfsklassen umgewandelt und an die implementierendeMethode ubergeben. Die Ruckgabewerte werden ihrerseits wieder in Stringsumgewandelt und an die Action-Instanz ubergeben (siehe Abb. 9).

4.2 Control Point

Bei der Generierung des Control Points wird fur die Services des Devices eineProxy-Klasse generiert, die das gleiche Service-Interface implementiert. Hierbeiwird der UPnP-spezifische Anteil vor dem Anwender des Stacks weitestgehendverborgen. Intern wird die eine ProxyService-Instanz verwendet. Im Methoden-

18

// Implementation of ’setTarget’ action proxypublic void setTarget(boolean newTargetValue) throws SOAPException {

//get actionAction currentAction = service.getActionByName("setTarget");ArgumentList inArgumentList = currentAction.getArguments()

.getInputArguments();ArgumentList outArgumentList = currentAction.getArguments()

.getOutputArguments();

inArgumentList.getArgumentByName("newTargetValue").setValue(SOAPHelper.convertToString(newTargetValue));

//submit requestservice.submitActionRequest(currentAction);

}

Abbildung 10: Beispiel der Implementierung einer Proxy-Methode

rumpf werden die Parameter in Strings umgewandelt und an die der Aktion ent-sprechende Action-Instanz ubergeben. Der Aufruf der Aktion wird initiiert unddie Ruckgabewerte werden extrahiert und analog zum ActionHandler im Devicein die entsprechenden (falls vorhanden) Java Datentypen umgewandelt.

Zusatzlich werden dem Entwickler die erforderlichen Schritte zur Discovery derDevices und zum Erzeugen der Proxies abgenommen. Es wird also eine typisier-te Schnittstelle – im Gegensatz zur generischen Schnittstelle des Stacks – zurVerfugung gestellt. Die Interfaces, die fur den Discovery-Mechanismus implemen-tiert werden mussen, werden auch durch den generierten Code implementiert.Es muß lediglich noch ein Listener-Interface implementiert werden, so daß dieMoglichkeit der Benachrichtigung bei der Erkennung eines Devices zur Verfugungsteht. Diese Implementierung muß am (spezifischen und generierten) ControlPoint als Eventhandler angemeldet werden. Hierfur wird noch eine Container-Klasse generiert, in der das ProxyDevice und die Service-Proxies ubergeben wer-den. Das ProxyDevice wird bei der Erkennung automatisch instantiiert.

4.3 Implementierung

Die Implementierung es Codegenerators wurde vor allem dadurch erleichtert, daßdas Generator-

”Frontend“ durch das Objektmodell und der XML-Parser der UP-

nP Devices und Services durch den Stack schon verfugbar gewesen ist. Die meistenParameter, wie die verwendeten Klassennamen und das Java-Package werden ausden Service- und Devicenamen, bzw. anderen variablen Werten abgeleitet und zuBeginn in einer Klasseninstanz mit Konfigurationsinformationen gespeichert.

19

Die abstrakte statische Struktur des zu erzeugenden Codes wurde auf ein Klassen-modell abgebildet und wird dementsprechend aus Device- und Servicebeschrei-bung aufgebaut. Die letztendliche Erzeugung des Quellcodes der Klassen undInterfaces ist entsprechend des Kontextes auf unterschiedliche Klassen aufgeteiltund gekapselt. Dabei wurde Wert darauf gelegt, wenn moglich Bestandteile desQuellcodes wiederzuverwenden, so z.B. die Methodensignaturen.

Die Erzeugung des Codes fur die Konvertierung der UPnP– in Java– Daten-typen, die mir Hilfe von Methoden der Java–Library und Hilfsklassen erreichtwurde, wurde in eine eigene Klasse ausgelagert. Diese enthalt mehrere statischeMethoden, die als Paramter die Datentypen (Java/UPnP) ubergeben bekommenund den entsprechenden Datentyp, bzw. Codebestandteile fur die Konvertierungfestlegt. So kann der Generator leicht um die Unterstutzung weiterer Typen er-weitert werden.

cp: ControlPoint

devices: HashMap

foundDevices: Vector

listeners: Vector

BinaryLightControlPoint()

addBinaryLightListener()

deviceRemoved()

newDeviceAnnounced()

newDeviceSearchResponse()

newServiceAnnounced()

newServiceSearchResponse()

removeBinaryLightListener()

searchTimeout()

serviceRemoved()

shutDown()

BinaryLightControlPoint

service: ISwitchPowerService

SwitchPowerServiceSkeleton()

processActionRequest()

SwitchPowerServiceSkeleton

BinaryLight()

announce()

getSwitchPowerService()

remove()

BinaryLight

device: ProxyDevice

switchPowerService: SwitchPowerServiceProxy

BinaryLightDevice()

getDevice()

getSwitchPowerService()

BinaryLightDevice

deviceAnnounced()

deviceRemoved()

«interface»IBinaryLightListener

service: ProxyService

SwitchPowerServiceProxy()

getService()

getStatus()

setTarget()

SwitchPowerServiceProxy

status: StateVariable

SwitchPowerServiceImpl()

getStatus()

setTarget()

SwitchPowerServiceImpl

getStatus()

setTarget()

«interface»ISwitchPowerService

processActionRequest()

«interface»UPnPActionListener

ProxyService

+ service

0..1

- switchPowerService 0..1

- switchPowerService0..1

Abbildung 11: Die Klassenstrukur des generierten Codes am Beispiel eines Bina-ryLightDevice

4.4 Beispiel

In Abb. 11 ist exemplarisch am sog. Binary Light Device (ein einfaches Bei-spiel eines UPnP–Devices) die statische Struktur des generierten Codes sichtbar.Das Interface ISwitchPowerService definiert die Aktionen des SwitchPower-Service. Dieses Interface wird sowohl von der Klasse SwitchPowerServiceProxy

20

fur den Control Point, als auch durch die Klasse SwitchPowerServiceImpl, dielediglich ein Stub fur die reale Implementierung ist, implementiert. Die KlasseSwitchPowerServiceSkeleton hat hier die Aufgabe, die Action-Requests entge-genzunehmen und an die entsprechende Methode der Implementierung zu uber-geben.

Die Klasse BinaryLightControlPoint uber nimmt hierbei die Aufgabe der Suchenach Devices von Typ BinaryLight:1 und der Instantiierung der ProxyDevice

und BinaryLightDeviceProxy Objekte. Sobald ein Device gefunden wurde,wird eine Instanz der Klasse BinaryLightDevice an Event–Listener des TypsBinaryLightListener ubergeben.

5 Entwurf und Implementierung eines UPnPGateway

5.1 Motivation

Die Verwendung von UPnP–fahigen Endgeraten ist aufgrund der verwendetenTechniken wie multicast UDP und auch durch NAT-Router auf lokale Netze be-schrankt – und sollte dies aus Sicherheitsgrunden auch sein. Da ein bedeutendes(und primares) Anwendungsfeld von UPnP aber die Heimvernetzung (eHome)ist, ware es wunschenswert auch mobil auf diese Gerate zugreifen zu konnen.Dies ermoglichte eine ganze Reihe von Szenarien, ist aber nicht ohne zusatzli-chen Aufwand moglich. Auch fur die Realisierung von sogenannten

”Residential

Gateways“ ist zusatzliche Funktionalitat erforderlich, um z.B. Service–Providerneinen Zugriff auf die UPnP–Gerate eines Kunden zu ermoglichen.

Diese Funktionalitat kann z.B. durch einen OSGi–Service (OSGi Alliance, 2004)erbracht werden., aber auch eine native UPnP–Losung ist hier denkbar. DerDevice Secutity and Security Console–Standard (UPnP Consortium, 2004a)ermoglicht einen durch Public Key Cryptography abgesicherten Zugriff auf UPnP–Gerate, wodurch ein sicherer UPnP–Gateway realisiert werden kann.

Leider ist die sichere Ubertragung von Events uber das GENA–Protokoll zur Zeitnoch nicht moglich. Da GENA aber unter Umstanden bald durch einen SOAP ba-sierten Notofikationsmechanismus ersetzt wird, konnen dann auch Events sicherubermittelt werden.

Hier wurde die zweite Moglichkeit gewahlt und ein rein UPnP–basierter Gatewayrealisiert. Dies hat unter anderem den Vorteil, existierende Control Points leichtso anpassen zu konnen, daß sie nicht direkt, sondern uber den Gateway, auf dieDevices zugreifen. Es wurde auch nicht die komplette Funktionalitat realisiert,

21

sondern nur eine Teilmenge, die die Realsierbarkeit des Konzeptes unter Beweisstellen soll.

5.2 Realisierung

5.2.1 Architektur

Residential Gateway

UPnP Gateway Device

Generic Control Point

Networked Device

UPnP Device

Mobile Device

Gateway Control Point

*

-HostedDevice

*

*

*

-CP1

*

Abbildung 12: Architektur des UPnP Gateway Services

Zur Realisierung des Gateways sind mehrere Komponenten erforderlich. Zumeinen der Gateway selbst, der eine Schnittstelle zum Zugriff auf die Deviceszur Verfugung stellt. Der Gateway sollte die Phasen Discovery, Description undControl unterstutzen. Die Eventing–Funktionalitat wurde aus dem oben erwahn-ten Sicherheitsaspekt nicht berucksichtigt. Auch die Presentation–Funktionalitatwurde hier nicht berucksichtig, da dies fur den avisierten Einsatzbereich nichtunbedingt notwendig ist.

Um die Funktionalitat transparent nutzen zu konnen, wurde ein spezialisierterControl Point entwickelt, der den Benutzern den Zugriff auf die zu steuerndenDevices ermoglicht (siehe Abb. 12).

Der Gateway sollte – wie schon erwahnt – als UPnP Device realsiert werden,benotigt aber fur die Erkennung und den Zugriff auf die Devices auch die Funk-tionalitat eines Control Points. Der Gateway Control Point ermoglicht dann denZugriff auf die Devices. Um den Sicherheitsanforderungen zu genugen wurdenhier eine Implementierung des UPnP Device Security Standards verwendet, diefast die gleichen Schnittstellen zur Verfugung stellt, wie die

”normale“ Implemen-

22

tierung, die Kommunikation aber uber PKC absichert und eine Authentifizierungermoglicht.

5.2.2 Das Gateway Device

Das Gateway Device ist ein UPnP–Device, das nur einen einzigen Service,und zwar den GatewayService enthalt. Der Service stellt mehrere Aktionen zurVerfugung. Mit der Aktion EnumerateDevices kann der Gateway Contol Pointdie im Netz verfugbaren Devices in Erfahrung bringen (Dicovery). Die Descrip-tion–Phase wird durch die Aktionen GetDescription und GetServiceDescripti-on ermoglicht. Die Devices werden hier durch einen Universal Unique Iden-tifier (UUID) identifiziert, die Service durch die ServiceID, die im DDD spe-zifiziert ist. Die InvokeAction–Aktion ermoglicht es, Aktionen an die Servicesder Devices zu senden. Die Funktionalitat der EnumerateDevices–Aktion wirddurch das Gateway–Device erbracht. Dazu muß das Gateway Device die imNetz angekundigten Devices kennen. Die ubrigen Aktionen erbringen eine Proxy–Funktionalitat und werden an die entsprechenden Devices weitergeleitet.

5.2.3 Der Gateway Control Point

Der Gateway Control Point ermoglicht den Zugriff auf Devices uber den UPnPGateway. Die Schnittstelle (API), die dieser Control Point zur Verfugung stellt,ist die gleiche, wie die des klassischen Control Points. Die Klasse GatewayControl-Point ist von der Klasse ControlPoint abgeleitet und erbt dementsprechend dieSignatur. Zusatzlich wurde modifizierte Implementierungen der Klassen Proxy-Device und ProxyService realisiert. Die Funktionalitaten zur Discovery, zum In-statiieren von ProxyDevice- und ProxyService-Objekten und zum Aufrufen vonAktionen von Services sind so implementiert, daß der GatewayService transparentfur den Benutzer verwendet wird.

Diese gleichformige Schnittstelle ermoglicht eine hohe Flexibilitat und eine Wei-terverwendung existierender Control Points in einem anderen Kontext.

6 Fazit

Durch die vorgenommenen Modifikatikationen ist der UPnP-Stack flexibeler undresourcenschonender geworden. Die Flexibilitat wurde vor allem durch die Un-terstutzung von Complex Types und von IPv6 erhoht. Die Anderungen am SSDP-Protokoll haben zum einen eine Verringerung der Netzwerkbelastung nach sichgezogen, erlauben es auf der anderen Seite aber auch, wesentlich feinkorniger den

23

Status von UPnP-Devices im Betrieb nachzuvollziehen (zum Beispiel durh eineErkennung von Reboots). Durch die Unterstutzung des HTTP 1.1 Protokolls unddes SOAP 1.1 Protokolls wurden eine bessere Interoperabilitat und erweiterte In-tegrationsszenarien ermoglicht.

Die Bereitstellung eines Codegenerators fur spezielle UPnP-Device und -ControlPoint Implementierungen fuhrt hoffentlich zu einer einfacheren Verwendbarkeitdes Stacks und zu einer niedrigeren Hemmschwelle, sich mit den Vorteilen vonUPnP auch experimentell auseinander zu setzten. Der Codegenerator erlaubteine schnelle Erstellung von Prototypen, ohne sich vorher ausgiebig in die APIdes Stacks einarbeiten zu mussen (wobei die API allerdings auch nicht sonderlichkompliziert ist).

Die erstellte Implementierung eines UPnP Gateway–Devices ist als eine sog.Proof-of-concept-Implementierung aufzufassen. Eine Standardisierung eines sol-chen Gateway-Devices im UPnP Forum ware mit Sicherheit wunschenswert. Aucheine Erweiterung um einen Eventverbreitungsmechanismus ist notwendig, wur-de hier aber aus den oben genannten Grunden nicht vorgenommen. Die erstellteImplementierung soll hier eine Demostration der (einfachen) technischen Reali-sierbarkeit und als Diskussionsgrundlage dienen.

Insgesamt stellt UPnP einen interessanten Ansatz dar. UPnP zeichnet sich we-niger durch techischen Finessen und eine großen Machtigkeit, sondern durch eineinfaches Konzept und die Einbindung etablierter Technologien, wie SOAP. Lei-der

”erbt“ UPnP auch einige Probleme von den verwendeten Protokollen, wie z.B.

die schlechte Effizienz von XML/XMLSchema als Presentation Layer Protokoll(siehe Sandoz et al. (2003)). Dementsprechend ist das Einsatzgebiet von UPnPauch eher im Bereich der Heimvernetzung zu sehen, als in komplexen Netzwerk-konfigurationen.

UPnP bietet aber die realisitische Chance die Integration unterschiedlicher Gerateund Technologien zu vereinfachen. Dazu gehort naturlich auch der Plug-and-PlayGedanke, der es vor allem technisch durchschnittlich versierten Benutzern er-lauben soll Gerate in ein Netzwerk zu integrieren. Die Starke von UPnP sinddas einfache Konzept, die Wiederverwendung existierender Protokolle und seinePlattformunabhangigkeit. So existieren neben der hier vorgestellten Implemen-tierung in Java1 mehrere frei verfugbare Implementierungen fur unterschiedlichePlattformen und Sprachen2, so z.B. C und .NET.

1erhaltlich unter: http://www.plug-n-play-technologies.com2siehe: http://www.upnp.com/resources/sdks.asp

24

Literatur

Apple (2004): Dynamic Configuration of Link-Local IPv4 Addresses, MulticastDNS & DNS-Based Service Discovery.http://developer.apple.com/macosx/rendezvous/.

Gamma, E.; Helm, R.; Johnson, R. (1995): Design Patterns. Elements ofReusable Object-Oriented Software. Addison-Wesley Professional ComputingSeries. Addison-Wesley. GAM e 95:1 1.Ex.

Kim, D.-S.; Lee, J.-M.; Kwon, W. H.; Yuh, I. K. (2002): Design andimplementation of home network systems using UPnP middleware fornetworked appliances. IEEE Transactions on consumer electronics,48(4):963–972.

OSGi Alliance (2004): The OSGi service platform. Internet.http://osgi.org/resources/spec overview.asp, zugegriffen am 30.05.2004.

Sandoz, P.; Pericas-Geertsen, S.; Kawaguchi, K.; Hadley, M.;Pelegri-Llopart, E. (2003): Fast Web Services. Java Technology & WebServices News & Articles.http://java.sun.com/developer/technicalArticles/WebServices/fastWS/,zugegriffen am 12.06.2004.

Sun Microsystems (2004): Jini network technology.http://www.jini.org/about/technology.html, aufgerufen am 10. 05. 2004.

The Salutation Consortium (1999): Salutation Architecture Specification(Part 1). http://www.salutation.org, Version 2.0c.

UPnP Consortium (2004a): Device Secutity and Security Console.http://www.upnp.org/standardizeddcps/security.asp, zugegriffen am30.05.2004.

UPnP Consortium (2004b): UPnP Device Architecture. Internet.http://upnp.org/resources/documents.asp, aufgerufen am 10. 05. 2004.

Zeroconf IETF Working Group (): Zero configuration networking.http://www.ietf.org/html.charters/zeroconf-charter.html, zugegriffen am 10.05. 2004.

ZEROCONF Working Group (2004): Dynamic configuration of link-localipv4 addresses. http://files.zeroconf.org/draft-ietf-zeroconf-ipv4-linklocal.txt,zugegriffen am 15.05.2004.

25