10 likes | 130 Views
G. G. Volume Service. Surfing Service. Actions: + channelUp() + channelDown() State Variables: - channel:integer. Actions: + volumeUp() + volumeDown() State Variables: - volume:integer. Wireless LAN. Firewire (IEEE1394). Bluetooth. Ethernet. Powerline.
E N D
G G Volume Service Surfing Service Actions: + channelUp() + channelDown() State Variables: - channel:integer Actions: + volumeUp() + volumeDown() State Variables: - volume:integer Wireless LAN Firewire (IEEE1394) Bluetooth Ethernet Powerline Analysis and Improvements of Eventing Protocol for Universal Plug and PlayAuthor: Yarema Mazuryk 1, Co-author: Johan Lukkien 1 1. Introduction • 3. Proposed Solutions • Modify GENA subscription mechanisms; • Decouple events from state variables; • Transmit event-specific data along with the notification; • Use UDP-based transport; UPnP is a growing interoperability standard, which allows networked devices to cooperate in an autonomous fashion by using functionality found on the network. 4. Improved Eventing Protocol for UPnP GENA GENA Requirements to MDP • GENA based protocol to minimize and localize changes in UPnP API; The key components in UPnP are devices, services, and control points. HTTP MDP SSDP advertise1 UPnP Device TCP TCP SSDP search1 SSDP response2 UPnP Control Point SOAP action request2 • 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); SOAP response2 GENA subscription request2 GENA event notifcation2 1- multicast UDP messages 2- TCP messages Example of the UPnP system 2. UPnP Evaluation 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. MDP state machine 5. Performance Comparison The figure compares event notification delivery delay for traditionaland improved UPnP implementations. • 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; • Measurements conditions • Clocks at the machines are synchronized; • Service exposes 4 events, which are generated with different frequencies; • 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; • 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; 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. 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