1 / 100

Device Servers

Device Servers. Prasun Dewan. Department of Computer Science University of North Carolina dewan@unc.edu. Issues in Device Servers. Device is just a server. So what is different?. Network. Sever and network is always around - static address

gaille
Download Presentation

Device Servers

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Device Servers Prasun Dewan Department of Computer Science University of North Carolina dewan@unc.edu

  2. Issues in Device Servers • Device is just a server. • So what is different? Network

  3. Sever and network is always around - static address Centralized heavyweight scheme acceptable to give install and give unique addresses to servers Client expected to know traditional server address imap.cs.unc.edu Discovery phase possible www.cnn.com logical name to physical name can be bound dynamically Devices may be dynamically added on ad-hoc networks - dynamic address With so many dynamic devices and ad-hoc networks lightweight decentralized scheme needed Client may not know or care about device server address print to the nearest printer turn off all light bulbs Implies later binding and thus a discovery phase Addressing Devices vs. Traditional Servers

  4. Client expected to know exact server interface get mail send mail Client may not know exact server interface palm computer controlling a VCR it knows nothing about security system composer substituting Axis camera with Aibot Robot, which may not share an interface impromptu interoperability implies an interface (capability) discovery phase Communicating with Device vs. Traditional Servers

  5. Client polls for traditional server changes New mail arrived? Cannot track fast changing information Client may wish to notified of device changes current channel changed, so redisplay it Implies an eventing mechanism that is distributed can be dynamically discovered Communicating with Device vs. Traditional Servers

  6. Run preloaded client user-interface program xmh netscape Because of late binding, client UI program may not exist Implies dynamic user-interface deployment Deploying Remote User Interfaces

  7. Traditional servers not composed into a single unit Not the same as replicas Composite device may be composed out of multiple devices security system CD How to support composite and individual device services. Composing Devices

  8. UPnP (Universal Plug and Play) • Formed in 1999 with 200 vendors • Consumer electronics,Home security, Networking, Mobile devices • Late binding • Dynamic Server discovery • Dynamic Interface discover • Dynamic Event discovery • Dynamic UI Deployment • Static Service Composition • Language- and OS- Neutral Solution • Avoid trojan horses • Ship data rather than code • Open • Use existing standards

  9. UPnP Tactics • Start simple • Build in only universal things that everybody needs (and can live with) • Add as needed • Minimize requirements • Basic IP network connectivity • Common HTTP protocol stack • Leverage existing standards • HTTP, XML

  10. Today Attach it to server PC Load device driver Share printer Manually bind each client to printer Vision Just connect printer to network UPNP Examples: Installing a printer

  11. Today Attach a new disk drive to computer Vision Just connect drive to network Installing a device store

  12. Today Set alarm clock May vary depending on weekday or weekend Set thermostat Hope meeting not missed Vision Alarm clock tells PC It runs script that checks schedule and sets thermostat Intelligent Alarm clock

  13. Today Turn on entrance light Change thermostat Play answering machine messages Turn on TV Set channel to CNN Raise/lower blinds depending on before/after sunset Turn on other lights Reverse steps when turning off light Vision Light switch communicates with PC, which runs script and its inverse Arriving/leaving home

  14. Today Manually change thermostat Change water heater Close/open water valve Hold mail Set vacation message(s) Inform neighbour(s) Throw trash Vision Push button saying on vacation Could do it remotely Must still throw trash Arriving/leaving town

  15. Today Manually set all clocks Vision They automatically synchronize with an a networked atomic clock Script runs periodically or when power comes on Power outage

  16. Home theater Script to • Turn on DVD • Turn on TV • Set it to DVD channel • Set stereo to Video mode • Set stereo volume to theater levels • Dim lights

  17. Ball game Mobile device used to: • pick up traffic info on road • receive commentary at stadium • track player statistics • order food • chat with buddies at game

  18. Other apps • Appliance remotely fixed or set • Calendars of family members synchronized • Product barcode scanned to order new instance • Presentation displayed on discovered display devices

  19. UPnP Device Architecture

  20. Control Point Device Service Control Point Device Service Architecture/Terminology • Components • Control points • Controller, usually client • Device • Controlled,usually server • An actual devicemight containboth functions

  21. UPnP Enabled Device Device Service 1 Service 2 UPnP Enabled Device Control Point Device Control Point Service UPnP Enabled Device Root Device Embedded Device Service Service 1 Service 2 Control Service Server State Event Table Server Architecture

  22. Example Configuration

  23. 3 Control 4 Eventing 5 Presentation 2 Description 1 Discovery 0 Addressing Steps to UPnP Networking 0 Control point and device get addresses 1 Control point finds interesting device 2 Control point learns about device capabilities 3 Control point invokes actions on device 4 Control point listens to state changes of device 5 Control point controls device and/or views device status using HTML UI

  24. Standardized Schema Instances (Types) URLs, Model, Device # Schemas (Prog Lang) UPnP vendor UPnP Forum UPnP Device Architecture HTTPU/MU SOAP HTTP GENA SSDP GENA HTTP UDP TCP IP Name Discovery and Events State Events Capability Discovery Operation Control UPnP Protocol Stack Vendor-specific API aboveVendor-specific OS below Wire protocols Multiple http servers

  25. Steps to UPnP Networking 3 Control 4 Eventing 5 Presentation 0* Control point and device get addresses 1 Control point finds interesting device 2 Control point learns about device capabilities 3 Control point invokes actions on device 4 Control point listens to state changes of device 5 Control point controls device and/or views device status using HTML UI 2 Description 1 Discovery 0* Addressing

  26. 0 Addressing • Control point and device get address • Use a DHCP server • Else use Auto IP • What is Auto IP? • IETF Draft Automatically Choosing an IP Address in an Ad-Hoc IPv4 Network • What steps does it take? • Pick an address in 169.254/16 range • Check to see if it is used (ARP) • Periodically check for DHCP server Could use DNS and include DNS Client

  27. Overview -ad hoc

  28. Overview - configured

  29. Steps to UPnP Networking 3 Control 4 Eventing 5 Presentation 0 Control point and device get addresses 1* Control point finds interesting device 2 Control point learns about device capabilities 3 Control point invokes actions on device 4 Control point listens to state changes of device 5 Control point controls device and/or views device status using HTML UI 2 Description 1* Discovery 0 Addressing

  30. 1 Discovery: Pull (Active) vs. Push (Passive) Server Client • Client (Control point) could pull info • Servers could be dynamically added • Needs to poll for new devices • Server (Device) could push advertisement • Control points can be dynamically added • Needs to continuously send info, using network Server Client

  31. Client Server 1 Discovery: Pull (Active) vs. Push (Passive) Server • SSDP Solution: • Hybrid approach • Advertisement has lifetime • Can simulate pure push model • HTTP over UDP • What if message gets lost? • Must send UDP message 3 times • Solution over TCP planned

  32. 1 Discovery: SSDP Sidebar • What is SSDP? • IETF Draft Simple Service Discovery Protocol • Key design principles • Administratively-scoped multicast • Unicast responses • UDP • Very simple advertisements • Very simple search

  33. Control point finds interesting device 0 get address 1 discover device Advertise / find typed devices (services) Guarantee of minimal capabilities Simple Devices Advertise when added Refresh advertisements (cf. lease) Cancel advertisements when removed Control points search as needed Devices respond Control points filter 1 Discovery

  34. UPnP vendor UPnP Forum UPnP Device Architecture HTTPMU(multicast) HTTPU(unicast) GENA SSDP SSDP UDP IP 1 Discovery: Protocol Stack

  35. Multicast address Port 1 Discovery: Advertising • Who? Device multicasts • When? Added or refresh (cf. lease) • What? • 1 time / service type with NT == service type • 1 time / device type with NT == device type • 1 time / device with NT == device UUID • 1 time with NT == upnp:rootdevice NOTIFY* HTTP/1.1HOST:239.255.255.250:1900 CACHE-CONTROL: max-age =seconds until advertisement expiresLOCATION:URL for UPnP description for root device NT:search targetNTS:ssdp:aliveUSN:advertisement UUID

  36. GENA • Notification method format defined by GENA • An event delivery scheme over HTTP • Allows subscription • May be used later • Will allow it to be not depend on the “largely non-existent Internet multicast infrastructure”

  37. Multicast Scope • Entire internet • Idea to find local service • Link local • Does not support bridged/routed LANS • Local administrative scope • Relative address • 239.255.255.250 • Relative address vs local scope • Relative address allows progressively larger scopes • Based on physical location?

  38. Location vs. USN • Location needed to send messages • USN a unique, location-independent ID • UUID is a USN example • Decentralized assignment • Allows services to move • Change IP address • Change DNS name

  39. Byebye message • Sent before device ceases to operate • NTS = ssdp:byebye • NT = service type

  40. 1 Discovery: Searching • Who? Control point multicasts • When? Looking for device or service • What? • ST one of • Service type • Device type • Device UUID • upnp:rootdevice • ssdp:all M-SEARCH * HTTP/1.1HOST:239.255.255.250:1900 MAN:"ssdp:discover"MX:seconds to delay response ST:search target

  41. Broadcast message • Can send message to all devices • ssdp: all • Network analysis tool • Remote control unit

  42. 1 Discovery: Responding • Who? Device unicasts • When? If ST matches an NT • What? • 1 time for each NT that matches • Very simple matching HTTP/1.1 200 OKCACHE-CONTROL: max-age =seconds until advertisement expires LOCATION:URL for UPnP description for root deviceST: search targetUSN: advertisement UUID

  43. Network traffic • SSDP traffic on recovery after power outage. • Control points will all send discover messages. • to find printer • In large companies multicast admin domain will be large • Can be entire company • Need a way for SSDP to deactivate before network storms created • Even with directory services, low-level SSDP may activate

  44. Bandwidth requirements • TP = some time period • DR = # of clients sending discovery messages in TP • RS = # of devices responding to each discover message • AM = average message size • Bandwidth = (DR* 3 + DR*9*RS)*AM/TP

  45. E.g. Network traffic • 100, 000 hosts • 5,000 printers • Requests evenly distributed over 30 second period • Message size = 512 bytes • Bandwidth = 585976 Megabits per second

  46. E.g. Network traffic • 1000 hosts • 50 printers • Requests evenly distributed over 30 second period • Message size = 512 bytes • Bandwidth = 59 Megabits per second

  47. Steps to UPnP Networking 3 Control 4 Eventing 5 Presentation 0 Control point and device get addresses 1 Control point finds interesting device 2* Control point learns about device capabilities 3 Control point invokes actions on device 4 Control point listens to state changes of device 5 Control point controls device and/or views device status using HTML UI 2* Description 1 Discovery 0 Addressing

  48. Control point learns about device capabilities 0 get address 1 discover device get URL for description 2 retrieve descr get URL for service description Declare capabilities Protocol stack UPnP vendor UPnP Forum UPnP Device Architecture HTTP TCP IP 2 Description

  49. Device description Type Physical container Logical container For each service Type URL for description URL for control URL for eventing UI Icons URL for presentation Services Functional units within devices Service description Actions State variables Actual (vs. designed) implementation Expressed in XML 2 Description

  50. XML • Like HTML • Describes a tree • Unlike HTML • Describes contents rather than UI • Style sheets describe UI • Tags are user-defined • Via Schema Language (DDT) • Supported by Web browsers

More Related