150 likes | 248 Views
The State of Service Discovery. Jeff Pang. Service Discovery (SD). NETWORK. Find me a printer. I am a printer. Overview. Purpose of Talk: Induce some cooperative brainstorming about contemporary SD problems :) Outline: Local Area SD Wide Area SD Possible future directions for SD.
E N D
The State of Service Discovery Jeff Pang Tuesday Seminar
Service Discovery (SD) NETWORK Find me a printer I am a printer Tuesday Seminar
Overview • Purpose of Talk: • Induce some cooperative brainstorming about contemporary SD problems :) • Outline: • Local Area SD • Wide Area SD • Possible future directions for SD Tuesday Seminar
Local Area SD • History: • AppleTalk, Novel IPX, NetBIOS/SMB • Current over-IP Protocols: • Service Location Protocol (SLP) [IETF, 1999] • Jini [Sun, 1999] • UPnP [Microsoft et al., 1999] • ZeroConf (a.k.a Rendezvous, mDNS, Bonjour, includes SLP) [Apple et al., 1999] • Most use the same mechanisms: • Service advertisement/query • No infrastructure/configuration required • Optional directory server(s) for scalability Tuesday Seminar
LAN SD Primitives • Two modes of operation: • Search vs. Publish/Subscribe • Service Request: search for a service • E.G., use an LDAP search filter in SLP • Service Advertisement: advertise the availability of a service • E.G., iTunes playlists (DAAP) over Rendezvous Jini Primitives Tuesday Seminar
LAN SD Self-Configuration • IP Addressing: • “Local-link”: Pick a random address from 169.254/16 and ARP to check for collisions • Naming: • Multicast DNS: Pick “Your Name.local” as name and multicast name lookups to the local-link • Discovery: • Service Requests multicast/broadcast • Use IP multicast groups to limit publish/subscribe Tuesday Seminar
LAN SD Scalability • Self-Configuration breaks when: • Multiple subnets: not all hosts on same local-link • Lots of hosts/services: multicast advertisement/search is too chatty to be scalable • General Solution: • Employ a Directory Server(s) at which services register and requests are routed • Effectively becomes dynamic LDAP • Requires infrastructure Tuesday Seminar
Recent Work • IETF working groups • Autoconf in MANETs • Autoconf in “mobile networks” • User-Relative-Naming [Ford, et al. 2005] • Owners assign own names to devices • Construct a consistent namespace for each user • Uses signed device logs to resolve conflicts Tuesday Seminar
Wide Area SD • Some research, long ago: • Intentional Naming System [MIT, 99] • Secure Service Discovery Service [Berkeley, 99] • Network Sensitive Service Discovery [CMU, 03] • Focus on: • Mobility (decouple name/location) • Scalability Tuesday Seminar
Scalability in WAN SD • Solution 1: Induce some hierarchy (INS) • Service descriptions/queries form a tree • e.g., [city, building, room], [device-type, data-type] • Partition namespace among a spanning tree of resolvers • Solution 2: Lossy Aggregation (SDS) • Aggregate service attributes using Bloom Filters • Trade-off query routing overhead for storage Tuesday Seminar
Recent Work • Most work in dynamic resource discovery: • SWORD [Berkeley, 04], Xenosearch [UCL, 03], Network Coordinates [GNP,Vivaldi,Meridian,etc.] • e.g., distributed search for particular nodes • WAN Service Discovery in the real world? Tuesday Seminar
Take Aways • Key Benefits: • Local Area SD: Auto-configuration • Because there are no sys admins • Wide Area SD: Fuzzy search interface • Because the search space is too big for global advertisement, too unknown for direct queries • Key Limitations: • Local Area SD: Scalability • Primary usage pattern is browse/select • Wide Area SD: Massive infrastructure • Without Google, how would we discover anything? :) Tuesday Seminar
Possible Future Directions • “Local-link” isn’t always physically local • e.g., my desktop at home, laptop at office, cell phone on me • “virtual local-link”? • Number of “services” on local-link growing • Most Apple programs advertise as services • Most service query results are junk • Preference sensitive service discovery? • Mobility and context aren’t considered • Still can’t “print to closest printer” on a laptop • Context sensitive service discovery? iTunes “services” Tuesday Seminar
Context-Sensitive SD Ideas • Keep browse/select interface, but rank results for scalability • In terms of user/application-information overload • In terms of service discovery traffic (e.g., incremental results) • Try similar approach to IR folks: • Instead of ranking by Pr[result|query] • Compute Pr[result|query,context,history] • Challenges: • Mobility: environment “context” may be ephemeral • Scalability: can’t rely on Google, need a distributed approach for autoconf environments • Privacy: context and history can reveal sensitive info; much pervasive computing work in this area (but do people really care? i.e., again, Google) Tuesday Seminar
That’s all! • Questions? Tuesday Seminar