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

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

3. 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

4. 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

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

6. Existing Solutions for Scalability
Sensor
Proxy
Resolver
Hierarchies

7. 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

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

9. 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

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

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

12. 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

13. 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

14. 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 △

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

16. Evaluation: Data Distribution
- Even distribution of queries among resolvers

17. 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