1. PROGRESS project EES5413: Internet Control and Monitoring of Embedded Systems System Architecture and Networking Affiliation 1) Eindhoven University of Technology Department of Mathematics and Computer Science HG 6.57, P.O. Box 513, NL-5600 MB, Eindhoven, The Netherlands Analysis and Improvements of Eventing Protocol for Universal Plug and Play Author: Yarema Mazuryk 1, Co-author: Johan Lukkien 1 About the Author Yarema Mazuryk received his M.Sc. in Computer Science from the Department of Computer Science and Engineering of National Technical University in Lviv, Ukraine. In 2003 Yarema started as a researcher project within the SAN group of Computer Science Department, TU/e. 2. UPnP Evaluation 6. Conclusions  UPnP is not suitable for the development of the data-centered services, which can be accessed by multiple clients simultaneously;  Decoupling events from service state variables and transferring event-specific data along with the event notification strengthen expressive power of UPnP;  Changing transport solution from TCP-based to UDP-based one significantly improves the performance of UPnP eventing mechanisms; 1. Introduction The figure compares event notification delivery delay for traditional and improved UPnP implementations. 4. Improved Eventing Protocol for UPnP Measurements conditions -Clocks at the machines are synchronized; -Service exposes 4 events, which are generated with different frequencies; Wireless LAN Firewire (IEEE1394) Bluetooth Ethernet Powerline G G G G UPnP is a growing interoperability standard, which allows networked devices to cooperate in an autonomous fashion by using functionality found on the network. Requirements to MDP  GENA based protocol to minimize and localize changes in UPnP API; 5. Performance Comparison Usability evaluation  UPnP is a control architecture, and therefore doesn’t suit well for data-centric applications;  Only blocking actions calls are possible;  Action arguments are bound to service state variables;  Data types are limited to simple types;  Events can only be signals about changes of state variables;  Clients cannot subscribe to individual events; Performance evaluation  TCP transport results in significant overhead for every event notification;  High mobility of devices may result in the situations when notifications have to be delivered to unavailable subscribers – resulting in excessive TCP timeouts; UPnP Device UPnP Control Point Volume Service Actions: + volumeUp() + volumeDown() State Variables: - volume:integer Surfing Service Actions: + channelUp() + channelDown() State Variables: - channel:integer SSDP advertise 1 SSDP search 1 SSDP response 2 SOAP action request 2 SOAP response 2 GENA subscription request 2 GENA event notifcation 2 1 - multicast UDP messages 2 - TCP messages In this work we evaluated UPnP as a platform for data-centric applications in terms of usability and performance. To identify the weak points of UPnP a simple file sharing service was implemented. GENA HTTP TCP GENA MDP TCP The key components in UPnP are devices, services, and control points. Example of the UPnP system MDP state machine 3. Proposed Solutions  Modify GENA subscription mechanisms;  Decouple events from state variables;  Transmit event-specific data along with the notification;  Use UDP-based transport;  Mechanisms for coupling request –response pairs provided by the protocol;  Deals with faulty nature of UDP - resilient against duplicated and out-of-order messages (see figure);