1 / 11

Supporting Legacy Applications in Associative Overlay Networks

Supporting Legacy Applications in Associative Overlay Networks. Shelley Zhuang, Ion Stoica { shelleyz , istoica }@CS.Berkeley.EDU Sahara Retreat January 16-18, 2002 http://www.cs.berkeley.edu/~shelleyz/research/aon. (ID, data). (ID, data). (ID, R). Associative Overlay Networks.

meda
Télécharger la présentation

Supporting Legacy Applications in Associative Overlay Networks

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. Supporting Legacy Applications in Associative Overlay Networks Shelley Zhuang, Ion Stoica {shelleyz, istoica}@CS.Berkeley.EDU Sahara Retreat January 16-18, 2002 http://www.cs.berkeley.edu/~shelleyz/research/aon

  2. (ID, data) (ID, data) (ID, R) Associative Overlay Networks • Implements rendezvous-based communication abstraction • Overlay network which consists of a set of servers that store triggers and forwards packets between end-points Receiver (R) Sender

  3. 5 8 9 (IDS, S) 6 7 (IDC, C) 1 2 4 3 (IDP, S) AON Native Application • Two types of triggers:  public and private • Server maintains a public trigger, IDP • Client creates a private trigger identifier IDC • Server creates a private trigger identifier IDS • Client and server insert the private triggers (IDC, IPC) and (IDS, IPS) Client (C) Server (S)

  4. Legacy Applications • Design goals • User should be able to choose between an AON-aware application or regular application • Should not require changes to existing infrastructure such as IP network routers, DNS • Proposed solution • Configure existing applications to connect to a local AON proxy that translates and forwards packets transparently over AON • Run an AON proxy locally

  5. Transparent Application Support • Example: telnet client-server application • TCP connection established via proxies: • Client (C)  Client Proxy (CP)  AON  Server Proxy (SP)  Server (S) • Private trigger identifiers (IDC, IDS) exchanged in 3-way handshake • Packets forwarded via proxies • Proxies rewrite TCP packets

  6. Control Path Operations • Server, S, runs telnet server • Server Proxy, SP • IDP = Hash1(telnet.S.aon.net) • Inserts trigger (IDP, IPSP /PSP) into AON • Inserts trigger (IDS, IPSP /PSP) into AON • Client, C, runs wrapper script “aon_telnet S” • IDP = Hash1(telnet.S.aon.net) • Send SETUP(IDP) to CP • CP sends back ACCEPT(P’CP = Hash2 (telnet.S.aon.net)) • Telnet 127.0.0.1 P’CP • Client Proxy, CP • Inserts trigger (IDC, IPCP /PCP) into AON

  7. Pros and Cons • Advantages • Client can make multiple connections to the same service on S simultaneously • Client can use more than one service on S simultaneously • Client can use the same service on two different servers simultaneously • No changes to existing infrastructure • Limitations • Per-application script • Not as general as solutions based on LD_PRELOAD, LD_LIBRARY, or system call trapping

  8. Discussion • End-to-end host mobility • Without changes to IP layer (Mobile IP) • Without changes to TCP protocol (MIGRATE) • Supports sender and receiver mobility • Server load balancing • Nearby server selection

  9. TCP Three-Way Handshake

  10. Translation Table • Client Proxy • IPCP /P’CP IDP • IDC  IPC /P’C • IDC  IPC P/P’CP • IPC /P’C  IDS • Server Proxy • IDP  IPS /PS • IDS  IPS /PS • IDS  IPSP /P’SP • IPSP /P’SP IDC

  11. Data Path Operations

More Related