MIT – Laboratory for Computer Science International Conference of Pervasive Computing, LNCS, 2002. INS/Twine : A Scalable Peer-to-Peer Architecture for Intentional Resource Discovery

Problem Description Abundant ubiquitous computation and communication Increasingly large computing environments Dynamic environments Locate resources using intentional descriptions

INR: Intentional Name Resolver INS Overview INR: Intentional Name Resolver INR Self-configuring resolver network Resources advertise their capabilities Client describes attributes of required resources

Resource Discovery Goals Allow client applications to locate services and devices Handle sophisticated resource descriptions Handle dynamism in the operating environment Scale to large numbers of resources

Existing Solutions for Scalability Sensor Proxy Resolver Partitioning Bldg 1 Bldg 2 Bldg 3 Floors 1-3 Floors 4-6 ? Cameras

Existing Solutions for Scalability Sensor Proxy Resolver Hierarchies

INS/Twine Contributions Collaborating peer resolvers: no content or location constraints on queries Scalability and load distribution via hash-based partitioning of resource descriptions among resolvers Semi-structured resource descriptions with arbitrary attribute-set Network dynamism Designed for an environment where all resources are equally important to users

INS/Twine Approach Overview Resolver resource = camera subject = traffic resource = motion sensor Sensor Proxy

INS/Twine Approach Overview A resource advertises its descriptions and network location to any resolver The description is converted into a canonical form: attribute-value tree (AVTree) Using the content of the advertised description, the resolver determines which resolvers should know about the resource The resolver forwards the description to these resolvers for storage Similarly for queries <res>camera <man>ACompany</man> <model>AModel</model> </res> <subject>traffic</subject> traffic root subject resource camera manufacturer ACompany model AModel

Architecture of INS/Twine (3-layer) T: type (advertisement or query) V: AVTree NR: name-record

Architecture of One Resolver 0110 1001 0000 Key Strand Mapper h : 0110 Best(01101001000) K nodes are chosen Router Distributed Hash Table h = hash(a1v1-a2v2) Res adv. … a1 v1 a2 v2

Splitting Descriptions into Strands Resource description: AVTrees traffic root subject resource camera manufacturer ACompany model AModel Six strands Input strand: res-camera-man-ACompany h1 = hash(res-camera) h2 = hash(res-camera-man) h3 = hash(res-camera-man-ACompany) Output keys: h1, h2 and h3

State Management Resources: join, move, leave and fail Resolvers: join and fail How to maintain consistency while achieving fault-tolerance? Hard state Soft state Hybrid solution implemented in INS/Twine

State Management in INS/Twine Resources refresh: at a high frequency by the refresh interval δ Resolvers refresh: at a lower rate defined by the refresh interval △

Evaluation: Data Distribution - Data distribution rather even. - Each resolvers holds a small fraction of resource descriptions

Evaluation: Data Distribution - Even distribution of queries among resolvers

Conclusion Intentional resource discovery Scalable peer-to-peer network of resolvers Hash-based mapping of resource descriptions to resolvers Dynamic and event distribution of resource information and queries Handles dynamism of resources and resolvers