240 likes | 345 Vues
This work discusses the development of a malleable overlay network designed to improve connectivity and resilience in distributed systems featuring group-based applications like gaming platforms and collaboration tools. The framework leverages random graphs to maintain connections among nodes while allowing efficient updates and fault tolerance. The study evaluates significant properties such as clustering coefficients, connectivity, and resilience to failures, showcasing how this approach can be applied to enhance existing systems like JuxMem for scalable replication services.
E N D
MOve: an application-Malleable Overlay UIUC / INRIA Collaboration GDS meeting - LIP
Disclaimer • Context of this work: • Work done during our collaboration with Urbana-Champaign • Indranil Gupta & Ramsés Morales • Side work GDS meeting - LIP
Why another overlay ? • Structured overlays • Chord • KaZAa • Unstructured overlays • Gnutella • Swim GDS meeting - LIP
Targeted applications • Group-based applications • Distributed white board • Gaming platform • Replication service • … • Nodes within subgroups will interact GDS meeting - LIP
Example: a gaming platform GDS meeting - LIP
Needed properties • Connectivity • Nodes should be able to communicate with others • Efficient updates • Within a group nodes share a common state • Volatility resilience • Both at global and subgroup levels GDS meeting - LIP
Who knows whom ? • Every one knows every one • Not scalable !!! • Only a partial view of the system • Who knows whom relation <=> an overlay • Ideally • Stay connected • Support for fault tolerance • Related node should be close in the overlay GDS meeting - LIP
Random graph benefits • Theoretical results • The graph will stay connected if there are more than log(n)links per peer (where n is the overall number of peers in the system) • Goal • To keep connectivity => try to stay close to random graphs GDS meeting - LIP
Non-application links • Take advantage of random graphs • A subset of the links are “random” • Weight according to the Round Trip Time -> taking the underlying topology into account • Use “swim” algorithms GDS meeting - LIP
Application links • To take into account application groups • Create links between peers belonging to a same group • New links • Replacing non-application links • Sharing application links GDS meeting - LIP
Sharing a same space GDS meeting - LIP
Replacement policy • If there is room enough an no link exist -> link creation • If the node has resources enough -> link creation • (else) drop a non-applicationlink, or change a non-application link to an application one GDS meeting - LIP
What happens when a node joins ? GDS meeting - LIP
Random walk • A mechanism to get new neighbor • Called periodically • To avoid pathological topologies • For fault tolerance • To increase the clustering degree GDS meeting - LIP
The random-walk mechanism GDS meeting - LIP
Simulation • UIUC-INRIA_SIM • A discrete event simulator • ~ 5000 lines of java code • Using the GT-ITM topology generator Kenneth L. Calvert, Matthew B. Doar, and Ellen W. Zegura. Modeling Internet topology.IEEE Communications Magazine, 35(6):160ミ163, June 1997. GDS meeting - LIP
Evaluation: Clustering coefficient (random graph…) GDS meeting - LIP
Evaluation:Connectivity GDS meeting - LIP
Evaluation:Controlled clustering GDS meeting - LIP
Evaluation:Link sharing benefit (1) GDS meeting - LIP
Evaluation:Twisting the overlay GDS meeting - LIP
Evaluation:Resilience to failures GDS meeting - LIP
Conclusion • MOve: a malleable overlay • Nodes remain connected • Strong connections within subgroups • High volatility resilience • Paper submited to DSN 2006 GDS meeting - LIP
Link with replication… • Far from JuxMem • BUT • Can be use for replication • Greater scale • Smaller warranties GDS meeting - LIP