110 likes | 247 Vues
This paper presents a novel approach to integrating legacy applications into Associative Overlay Networks (AONs) without requiring modifications to existing infrastructure. By utilizing transparent local AON proxies, applications can communicate effectively while maintaining their original functionality. The system supports both public and private trigger identifiers to manage connections and packets within the network. Additionally, it addresses issues of end-to-end mobility and server load balancing, demonstrating the potential for multiple connections to the same service across different servers.
E N D
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 • 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
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)
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
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
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
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
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
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