1 / 21

Middleware issues: From P2P systems to Ad Hoc Networks

Middleware issues: From P2P systems to Ad Hoc Networks. Franca Delmastro franca.delmastro@iit.cnr.it Pervasive Computing & Networking Lab (PerLab) IIT-CNR Pisa MobileMAN Project Helsinki, June 7 th 2004. Middleware for Ad Hoc networks. Ad Hoc networks and P2P systems:

halee-atkins
Download Presentation

Middleware issues: From P2P systems to Ad Hoc 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. Middleware issues:From P2P systems to Ad Hoc Networks Franca Delmastro franca.delmastro@iit.cnr.it Pervasive Computing & Networking Lab (PerLab) IIT-CNR Pisa MobileMAN Project Helsinki, June 7th 2004

  2. Middleware for Ad Hoc networks • Ad Hoc networks and P2P systems: • The distribution of services and data can fit well with the decentralized nature of Ad Hoc networks • In both cases nodes interactions are temporary • Resources are distributed among heterogeneous nodes • Systems must be reliable in case of node failures and disconnections events

  3. The fundamentals of the structured overlay network • CAN, Chord, Pastry et al. represents a family of middleware solutions for large-scale P2P systems • They use a Distributed Hash Function (DHT) to map physical addresses to a logical address space • Information and workload are uniformely distributed on the network • System scalability with the number of nodes is the main objective for ad hoc networks

  4. The Pastry model • The overlay network is a circular address space where nodes and data are logically mapped. • There is no correspondence between logical and physical distances • Subject-based routing reduce the lookup cost to a logarithmic cost • There are a lot of applications implemented for this solution, and many others are adaptable to this routing policy

  5. Logical & Physical distances 0 2128 - 1 Pastry Ring

  6. The Pastry Ring (K1 ,V) (K2 ,V) 0 2128 - 1 L1 = H(K1) L2 = H(K2 ) L1 X2 X1 = H(N1) L2 X1 N1 N2 X2 = H(N2)

  7. Pastry routing tables 0 2128 - 1 02212102 10233001 10233102 10233232 10323302 11301233

  8. Pastry Multi-hop Routing 0 2128 - 1 33301201 23301201 23301101 Route(23302121) 10233102 22301203 bestMatch(RoutingTable[0], 23302121 ) = 22301203 02212102 23000101 Compare(10233102, 23302121) = 0

  9. Joining the Ring X Route(X) X Join(X) • X has to know a own physical neighbor already present in the ring (node A) • A sends a message with key equal to X • Pastry Routing table of node X is initialized using routing tables of contacted nodes: • LS(X) = LS(Z) • NS(X) = NS(A) • RT(X) is a join of the routing tables of other nodes, according to the prefix shared metric 0 2128 - 1 Z Bk B2 A B1

  10. Disconnection from the ring • Each node executes a polling procedure to discover “remote” nodes status (referred only to routing table knowledge). • A “remote” node is considered disconnected from the Pastry network if it doesn’t answer to a polling message before a timeout expiration • After a disconnection event, the sender of the polling message has to update its routing tables contacting other “remote” nodes to fill in entries related to that node.

  11. Pastry Pros & Cons • Pros: • DHT allows an uniform distribution of IDs and workload on nodes providing the service • The subject-based routing defines a logarithmic lookup cost on the network dimension (O(log N)) • A lot of application can adapt their contents to this routing strategy • Cons: • Routing tables management based on remote connections can be a big overhead for ad hoc networks • Forcing the network routing with the subject-based policy can reduce network performances

  12. Using Cross-Layer to CROSS-ROAD NeSt Applications Middleware Transport Network MAC CROSS-layerRingOverlayforADhoc networks • In order to build an overlay network, the middleware can directly use the Network Routing table. • Node ID = H(IPaddress) • Since each ring is associated to a service, the routing protocol has to provide Service Location • Using a proactive LINK-STATE routing protocol, each node knows the entire network

  13. Hazy Sighted Link-State • Optimization of Proactive routing protocols • Each node sends periodical LSU packets on the network with frequencies inversary proportional to the routing hops number. • “Hazy” knowledge of distant nodes. Their status is not frequently updated as the 1-hop neighbors. (*) C. Santivanez, I. Stavrakakis et al., “Making Link-State Routing Scale for Ad Hoc Networks”, MobiHoc 2001 (*) C. Santivanez, I. Stavrakakis et al., “On the Scalability of Ad Hoc Routing Protocols”, INFOCOM 2002

  14. CROSS-ROAD overlay A Middleware level B Ad Hoc Network nodes Nodes providing service S • Working hypothesis: • The Network level gives a graph representing the network topology to the Nest • Each node has to be characterized by at least: (IPaddress, Services, 1hop-neighbors) • The middleware level can access to this graph and recover relevant information for itself A Network level B

  15. Interactions with NeSt Node A Node B NeSt Local Provided services NeSt Middleware Data Abstraction Middleware Data Abstraction Middleware Middleware Network Network Network Data Abstraction Network Data Abstraction Topology update and remote services Application messages LSU routing pkt containing services publications and topology updates

  16. Each node defines the ring autonomously CROSS-ROAD routing table contains only nodes provide the service (Leafset and Neighborset disappear) Middleware routing protocol is limited to a peer-to-peer connection Messages forwarding is realized by the network routing protocol CROSS-ROAD Routing Tables

  17. Pastry vs CROSS-ROAD • CROSS-ROAD: • Join operation does not require remote connections: each node can build its ring autonomously • PASTRY: • Join operation requires many remote connections to recover routing tables contents HIGH COST at middleware level NO COST at middleware level

  18. Pastry vs CROSS-ROAD • CROSS-ROAD: • Disconnection events are detected by the netwrok routing protocol through LSU packets • PASTRY: • The detection of disconnection events requires polling cycles towards remote nodes NO COST at middleware level HIGH COST at middleware level

  19. Pastry vs CROSS-ROAD • CROSS-ROAD: • Routing table size depends on the number of nodes taking part to the service • PASTRY: • Routing table fixed size involves a not complete knowledge of the network HIGH COST for tables management due to remote connections following topology updates NO COST at middleware level: local interactions with NeSt are sufficient to update routing tables

  20. Pastry vs CROSS-ROAD • CROSS-ROAD: • Subject-based routing involves a peer-to-peer connection • PASTRY: • Subject-based routing involves a multi-hop middleware routing O(1) middleware lookup cost, the remaining is a routing task O(log(N))middleware lookup cost

  21. CROSS-ROAD Software Architecture

More Related