1 / 15

Active Names: Flexible Location and Transport of Wide-Area Resources

Active Names: Flexible Location and Transport of Wide-Area Resources. Luis Rivera. Outline. Motivation Active Names Definition Goals Architecture Conclusions Related Work Discussion In case something had not been discussed yet!. Motivation. Problem

renev
Download Presentation

Active Names: Flexible Location and Transport of Wide-Area Resources

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Active Names: Flexible Location and Transport of Wide-Area Resources Luis Rivera

  2. Outline • Motivation • Active Names • Definition • Goals • Architecture • Conclusions • Related Work • Discussion • In case something had not been discussed yet!

  3. Motivation • Problem • Mobile computing and modern web applications does not fit well into the static DNS scheme • Need for rapid deployment and extensibility of Internet services • Solutions • Active Networks • Active Services • Active Cache • Smart Clients • Active Routing • Active Names!!!

  4. R R R R R R R R Active Names • Name • Chain of programs to resolve and reply • The name is ACTIVE: “There is not second step to request the service after name resolution”. C S

  5. Architecture Goals • Namespace should be • Customizable • Clients and services customize their namespaces • Extensible • Add functionality without modifying the architecture • Composible • Efficient use of network resources • Location independence resolution • The chain of programs should not be linked to fixed locations • Discussion • Efficiency through extensibility! • Extensibility through naming!

  6. R R R Resolution Partially Solved Name Next Namespace program After Method Solved Name Service Request Name Namespace program • Active chain mechanisms • Delegation • CPS  Continuation Passing Style • Resolvers • Located in strategic points in the network Service Reply C S Service Reply Service Reply After Method list

  7. Active Name Programs • Microkernel approach • Resolvers must provide • A loader to fetch namespace programs • Security for untrusted code (Java-2) • Local soft state • Communication interfaces • Bootstrap • Some initial programs are loaded onto each Active Name machine • Discussion • This works at the service level, we still need DNS right? • With different services in the same machine, who dictates security and resource access policies?

  8. Namespace • A namespace is a program • Locates data and resources • Hierarchically organized • Root interprets all names • Each namespace can interpret a name according to its own rules • Those rules are set by the owner of that portion of the namespace • Discussion • Namespace boundaries are fuzzy! • How scalable is this architecture?

  9. After Methods and API • After methods • Multi-way RPC based on distributed CPS • The remaining work of the namespace is prepended to the After Method list • The list represents the way to follow back to the client • API • Partially resolved name • Reference to the data stream • List of after methods • The framework support legacy applications

  10. Active Names Principles • Extensibility • Functionality can be added as needed • Example: Replicated Service Access • Location Independence • A name does not reveal the location of the service • Example: Image Distiller • Composibility • Combination of client and server extensions to improve service performance • Example: Web caching

  11. Performance • Replicated Service • DNS Round Robin: Best performance at low load. • Distributed Director: Best performance high load. • Active Names • Technique: Selection is biased by the number of hops and a decaying histogram of previous performance. • Best performance overall • Distiller • Server: Worse performance when server is loaded • Proxy: Overall good performance in both cases • Active Names: • Technique: Selection biased by end-to-end distillation cost. • Best performance in most of the cases

  12. Performance (cont…) • Data on Table 1 is interesting • Justify composibility? • Test • Analysis of server-initiated and client-initiated customizations • Distillation implements client-initiated customizations • Combination of server and client customizations • Better than distillation only by 50% • Better than server-only by 104% • Discussion • In all these examples, the client is mobile and the service is static • Does this represents a solution the applications of tomorrow?

  13. Related Work • TP monitors (Transaction Processing monitors) • “A Swiss Army knife of tools reflecting the particular holes in the surrounding system” • Intentional Naming System (INS) • Applications specify what they are looking for, not where to locate them. • Ninja project • Smart Clients • Active Caches

  14. Conclusions • Active names • Programs that resolve the name and retrieve the reply from the requested service • The Active names framework support • Extensibility • Location-independence • Composibility • The experiments showed a significant performance gain using the Active Name extensions • Even with the use of Java to code the programs.

  15. Discussion • Good or bad? • I think is a cool idea !!! • Where these experiments enough? • What could happened with a very long chain of active names? • Is this a solution for a really mobile environment where services are not fixed? • How scalable is this framework? • They say that several thousands, but where are they justifying it?

More Related