Chapter 3: Naming Page 38. Clients in most cases find the Jini lookup services in their scope by IP

Transcription

1 Discovery Services - Jini Discovery services require more than search facilities: Discovery Clients in most cases find the Jini lookup services in their scope by IP multicast/broadcast Multicast UDP for nearby Lookup services Unicast TCP for known Lookup services Join Used by services to register with a Lookup Service Lookup Clients and services use to request a service type from a Lookup service Search by type, not by name Closer to a directory service than to a naming service Chapter 3: Naming Page 37 Discovery Chapter 3: Naming Page 39 Organisation of Service Descriptions The lookup service maps interfaces indicating the functionality provided by a service to sets of objects that implement the service Object hierarchical organisation of services by type hierarchy leaf nodes store service descriptions including proxies to access services Printer Print Fax Copier Store Canon HP p1 p2 BJ-100 p3 BJC-70 Chapter 3: Naming Page 38 Chapter 3: Naming Page 40

2 Join Code Code Chapter 3: Naming Page 41 Lookup PDA Jini Client Chapter 3: Naming Page 43 Chapter 3: Naming Page 42 Code PDA Jini Client Chapter 3: Naming Page 44

3 Code PDA Jini Client Chapter 3: Naming Page 45 Simple Solution for a Location Service Using Broadcast or Multicast Broadcast is typically offered in LANs Simple locating process: broadcast identifier and wait on a reply (principle used in the Internet protocol ARP [Address Resolution Protocol]) But: inefficient in large systems More efficient: using multicast for location But: you need to build up and to know the multicast group Chapter 3: Naming Page 47 Naming vs. Locating Entities Till now: resources with fixed locations (hierarchical, caching,...) Problem: some entity may change its location frequently Simple solution: record aliases for the new address or the new name But: efficiency, re-use of old names,... New approaches are necessary, e.g. identifiers for an resource Entity ID a) Direct, single level mapping between names and addresses b) Two-level mapping using identifiers. Needs a location service to resolve identifiers Chapter 3: Naming Page 46 Forwarding Pointers (1) More popular approach for location: Forwarding Pointers old location Principle: A moving entity leaves behind a reference to the new location Client follows the chain of forwarding pointers But... Long chains make the location process very expensive Intermediate nodes have to store all pointers as long as needed Broken links prohibit location new location Short chains and robust pointers are needed Chapter 3: Naming Page 48

4 Forwarding Pointers (2) When an object moves it leaves behind a proxy having the new location reference Location is transparent for the client, request is forwarded along the chain Object sends back its new location to the caller, the forwarding pointer is redirected Chapter 3: Naming Page 49 Hierarchical Approaches Extending the home-based approach to several layers Network is divided into domains, sub-domains,... (similar to DNS) Leaf domains: local area network, cell in a mobile telephone network,... An entity located in domain D is represented by a location record in directory node dir(d) Location records on higher hierarchies point to next sub-domain directory node Chapter 3: Naming Page 51 Home-Based Approaches Popular approach for large-scale networks: home location principle of Mobile IP But: increase in communication latency, fixed home location Chapter 3: Naming Page 50 Information Stored in Nodes Entities may have multiple addresses (e.g. replication) Higher-level node stores pointers to each location Scalability problem: root node has to store all information Chapter 3: Naming Page 52

5 Location Lookup Looking up a location in a hierarchically organized location service Client contacts directory node in its own domain Go up hierarchy to the first directory node holding the information Chapter 3: Naming Page 53 Pointer Caches Caching can be used to store locations of 'stable' nodes Location caching: inefficient lookup with each location change Pointer caching: Caching a reference to a directory node (dir(d)) of the lowest-level domain in which an entity (E) will reside most of the time. Chapter 3: Naming Page 55 Location Update Install a replicate in a new domain: new pointers have to be set a) An insert request is forwarded to the first node that knows about entity E. b) A chain of forwarding pointers to the leaf node is created. Similar operation: deletion of pointers Chapter 3: Naming Page 54 Invalidation of Pointer Caches A cache entry that needs to be invalidated because it returns a non-local address, while such an address is available. Chapter 3: Naming Page 56

6 Scalability Issues Root directory node becomes bottleneck Solution: placing sub-nodes of a partitioned root across the network Spread sub-nodes uniformly; but new scalability problems: which node to give responsibility??? Chapter 3: Naming Page 57 Solution: Reference Counting Simply count the references pointing to you Problem: unreliable communication Process P expects to get an acknowledgement when it increases the skeletons counter Acknowledgement can get lost P sends the increase message again Necessary to detect duplicates Chapter 3: Naming Page 59 The Problem of Unreferenced Objects Problem with forwarding pointers: unreferenced object Garbage collection for remote objects: hidden from clients and objects itself How many proxies point to another one? Reference graph Chapter 3: Naming Page 58 Reference Counting Another problem: copying a remote reference to another process a) Copying a reference to another process and incrementing the counter too late b) Solution by using acknowledgements One more problem: performance problems in large-scale systems by communication overhead Chapter 3: Naming Page 60

7 Advanced Referencing Counting Weighted reference counting: each object has A fixed total weight A partial weight, initialised with the total weight Creating a remote reference causes transmitting half the partial weight to the referencer a) The initial assignment of weights in weighted reference counting b) Weight assignment when creating a new reference. Chapter 3: Naming Page 61 Advanced Referencing Counting Problem: the partial weight of the remote object can become zero. What is with former objects which want to make a reference? Make use of indirections when partial weight reaches one When copying the reference to P2, P1 creates a local skeleton with some total weight and the same partial weight Then transmitting half the partial weight to P2 Chapter 3: Naming Page 63 Advanced Referencing Counting Copying a reference to P2 causes P1 in transmitting half the weight Deleting a reference causes the remote object to subtract the weight of the referencer from its total weight When the total weight becomes zero, there are no more references Chapter 3: Naming Page 62 Advanced Referencing Counting Alternative to the use of indirections: generation reference counting Associate a generation and a copy counter with each referencing process Both counters are initialised with zero When copying a reference, the copy counter is increased; the new referencer becomes the next generation compared to the old one Skeleton maintains the numbers of outstanding copies for each generation; in case of a decrement request, the counter for the referencer's generation is decreased. The copies of the referencer is added to the next generation. If all generation entries are zero, there are no more references Chapter 3: Naming Page 64

8 And much simpler... Reference listing Skeleton keeps track of the proxies having a reference to it, i.e. it has a list of all these proxies (reference list) instead of a counter No problems with duplicated increments Easy to keep the list consistent in case of process failures Problem: copying a reference and deleting it too early (as in reference counting) Main drawback: bad scalability in case of many references Used in Java RMI Chapter 3: Naming Page 65 Tracing in Groups (2) 1. Marking the skeletons Hard mark: reachable from a root object, a hard marked proxy, or an external object Soft mark: only reachable from inside the group 2. Propagating marks to proxies 3. Repeating these steps till no more change is made Chapter 3: Naming Page 67 Tracing-based Garbage Collection How can isolated referencer groups be located? Tracing all entities in a distributed system Removing all non-reachable entities Scalability problems! only consider groups of processes Chapter 3: Naming Page 66 Tracing in Groups (3) If there are no more changes: deletion of soft-marked objects reduction of objects in groups after that: analysis of intergroup references on higher-level groups Chapter 3: Naming Page 68