Foundation of Peer2 Peer Computing Designing Structured PeertoPeer

  • Slides: 51
Download presentation
Foundation of Peer-2 -Peer Computing Designing Structured Peer-to-Peer Overlays as a Platform for Distributed

Foundation of Peer-2 -Peer Computing Designing Structured Peer-to-Peer Overlays as a Platform for Distributed Network Applications in Mobile Ad Hoc Networks Thomas Zahn, INRIA Rocquencourt, France Jochen Schiller, Freie Universität Berlin, Germany by Rizal Mohd Nor (Joey) [email protected] kent. edu

Purpose of Paper This papers tries to introduce several ideas in implementing structured overlays

Purpose of Paper This papers tries to introduce several ideas in implementing structured overlays networks using DHT which will help create better P 2 P applications over MANETs.

Introduction Distributed Hash Tables (DHTs) have been proposed for large-scale network applications. ➲ Route

Introduction Distributed Hash Tables (DHTs) have been proposed for large-scale network applications. ➲ Route a packet based on a key (rather than a fixed destination address) to the (unknown) node in the network that is currently responsible for the given key within a bounded number of hops. ➲ This overlay routing is also referred to as indirect routing. ➲

Overlay Networks ➲ ➲ Will Indirect overlay work on Ad hoc Mobile Networks? Overlay

Overlay Networks ➲ ➲ Will Indirect overlay work on Ad hoc Mobile Networks? Overlay vs. physical topology Example of the mapping between a P 2 P overlay network and the physical network.

Problem ➲ DHTs do not concern themselves with physical (routing) of the underlying network,

Problem ➲ DHTs do not concern themselves with physical (routing) of the underlying network, because it was designed to form overlay networks in Internet-based networks where physical routing is practically taken for granted. Hence, DHT: ● ● ● Cause an increased lookup complexity. Unstructured P 2 P flooding will not scale to a growing number of nodes Requests messages will overwhelm the underlying physical network.

Why conventional DHTs Won't Work in MANETs 1. Overly stretch A single overlay hop

Why conventional DHTs Won't Work in MANETs 1. Overly stretch A single overlay hop constitutes a physical route consisting of multiple physical hops Hence, probability of a successful decreases for each physical hop

Overlay Hop Physical Hop Overly Stretch Shortest Path Node D Node C Node T

Overlay Hop Physical Hop Overly Stretch Shortest Path Node D Node C Node T Node B Node S Multiple hops on the physical network might be tolerable in the internet, however, in MANETs it could be a significant problem? Why? Probability of a successful delivery decreases with each physical hop

Why conventional DHTs Won't Work in MANETs 2. Physical Route Discovery/Maintenance Unlike the wired

Why conventional DHTs Won't Work in MANETs 2. Physical Route Discovery/Maintenance Unlike the wired Internet with its comparatively stable infrastructure, the topology of a MANETs changes constantly. Routing protocols for MANETs are predominantly concerned with rediscovering routes between nodes. Hence, the expensive physical route discoveries in MANETs can quickly cancel out the efficiency of DHT-based overlay routing.

Physical Route Discovery Flood the network again! Node D To find new physical route

Physical Route Discovery Flood the network again! Node D To find new physical route Node C Node T Node B Node S Flood the network The lost of two nodes, almost flood the whole network twice. Imagine in MANETs, where nodes move constantly in and out of a network.

Why conventional DHTs Won't Work in MANETs 3. DHT Routing Table Maintenance Ø Ø

Why conventional DHTs Won't Work in MANETs 3. DHT Routing Table Maintenance Ø Ø Ø DHTs impose certain requirements that their routing table entries have to match. Depending on the structure and size of their routing tables, this overlay maintenance can incur significant amount of traffic. Extra overlay maintenance traffic can easily add a sizeable portion to the overall traffic, which will further increase the probabilities of collision and use up precious bandwidth.

DHT Routing Table Maintenance Node D Node C Node T Node B Node S

DHT Routing Table Maintenance Node D Node C Node T Node B Node S Similarly, moving nodes will make overlay maintenance, as well as flooding the network for discovering the new physical route. Have to update DHT Table

Solution 1. 2. 3. 4. 5. MADPastry: A new structured overlays (DHT) with added

Solution 1. 2. 3. 4. 5. MADPastry: A new structured overlays (DHT) with added design goals: Consideration of physical locality Provide standard DHT interface and functionality Avoid physical route discoveries Minimize overlay maintenance Exploit any available packet information

MADPastry Each node in a MADPastry network assigns itself a unique overlay id ➲

MADPastry Each node in a MADPastry network assigns itself a unique overlay id ➲ ● defines its logical position on the virtual overlay id ring. MADPastry routes the message to the node in the network that is currently responsible for the message key ➲ ● the node whose overlay id is currently the numerically closest to the message key among all MADPastry nodes in the network. To avoid message broadcasts (e. g. for route discovery) ➲ ● MADPastry considers physical locality in the construction of its routing tables.

MADPastry and the concept of Landmark MADPastry define its Fixed Landmark Keys Fixed Landmark

MADPastry and the concept of Landmark MADPastry define its Fixed Landmark Keys Fixed Landmark keys are chosen by dividing the logical overlay id space into equal sections 0800. . 00, 1800. . 00, . . . . , F 800. . 00 However, in MANETs, nodes are highly dynamic, then how can a Landmark sustain for Answer: Employed a long? technique called Random Landmarking (RLM) Fixed Landmark Keys Range of Lower Keys Range of Higher Keys 08000000 - 07 FFFFFF 0000 - 0 FFFFFFF 18000000 10000000 - 17 FFFFFF 10000000 - 1 FFFFFFF 28000000 20000000 - 27 FFFFFF 20000000 - 2 FFFFFFF 38000000 30000000 - 37 FFFFFF 30000000 - 3 FFFFFFF 48000000 40000000 - 47 FFFFFF 40000000 - 4 FFFFFFF 58000000 50000000 - 57 FFFFFF 50000000 - 5 FFFFFFF 68000000 60000000 - 67 FFFFFF 60000000 - 6 FFFFFFF 78000000 70000000 - 77 FFFFFF 70000000 - 7 FFFFFFF 880000000 - 87 FFFFFF 80000000 - 8 FFFFFFF 98000000 90000000 - 97 FFFFFF 90000000 - 9 FFFFFFF A 8000000 A 0000000 - A 7 FFFFFF A 0000000 - AFFFFFFF B 8000000 B 0000000 - B 7 FFFFFF B 0000000 - BFFFFFFF C 8000000 C 0000000 - C 7 FFFFFF C 0000000 - CFFFFFFF D 8000000 D 0000000 - D 7 FFFFFF D 0000000 - DFFFFFFF E 8000000 E 0000000 - E 7 FFFFFF E 0000000 - EFFFFFFF

Mad. Pastry Random Landmark 1) Initially, all nodes (RLM) Nodes assigns itself overlay IDs

Mad. Pastry Random Landmark 1) Initially, all nodes (RLM) Nodes assigns itself overlay IDs 2) Listen for Beacons, to find out if they are close to any Landmark keys, if not check to see if they are responsible for being temporary landmark node 75 A 1 FFE 2 72 A 1 FF 21 B 5 A 1 FEE 2 78000050 75 A 1 FFE 2 74 A 1 FFE 2 3) Node currently closest to a landmark key, becomes temporary landmark Node (RLM) 4) The temporary Landmark Node periodically issue beacon messages 75 A 1 FFE 2 5) Node associates itself with closest temporary landmark if have the same prefixed A 0594822 6) If need be, a node assigns itself a new overlay id sharing the same prefix with the new closest temporary landmark node.

MADPastry & Cluster Nodes Random Landmark (RLM) ➲ ● These RLM keys divide the

MADPastry & Cluster Nodes Random Landmark (RLM) ➲ ● These RLM keys divide the logical overlay id space into equal sections ➲ ● 0800. . 00, 1800. . 00, . . . . , F 800. . 00 Node currently closest to a landmark key ➲ ● ● ➲ No fixed landmark nodes, landmark keys instead Become temporary landmark node Periodically issue beacon messages Nodes overhearing these beacon messages and periodically determine the physically closest temporary landmark node.

MADPastry & Cluster Nodes Node associates itself with closest temporary landmark ➲ ● If

MADPastry & Cluster Nodes Node associates itself with closest temporary landmark ➲ ● If need be, a node assigns itself a new overlay id sharing the same prefix with the new closest temporary landmark node. ➲ ● ➲ assumes same overlay ID prefix physically close nodes forming overlay clusters with common id prefixes Therefore, physically close nodes are also likely to be close in the overlay

MADPASTRY ➲ MADPastry maintains three different routing tables: Node 3 BBA 1234 Stripped down

MADPASTRY ➲ MADPastry maintains three different routing tables: Node 3 BBA 1234 Stripped down Pastry routing table that only contains Landmark Key Standard Pastry Leaf Set for Indirect Routing AODV routing table for actual physical routes of overlay hops.

Considerations of Physical Locality ➲ Employed a technique called Random Landmarking (RLM) ➲ RLM

Considerations of Physical Locality ➲ Employed a technique called Random Landmarking (RLM) ➲ RLM are randomly selected nodes in the cluster. The RLM node, will be the node. ID in the stripped down Pastry routing table. ➲ RLM nodes peridically send out beacon messages to associate closest overhearing nodes ➲ Lead to formation of clusters, where nodes are close in the physical layer, as well as numerical space Spatial Distribution of overlay ID prefixes

Provide Standard DHT interface and functionality MADPastry routing(overlay and physical view) ➲ MADPastry first

Provide Standard DHT interface and functionality MADPastry routing(overlay and physical view) ➲ MADPastry first uses the Pastry routing table or Pastry leaf set to determine the destination of the next overlay hop. ➲ Next, the AODV routing table is used to determine the next physical hop towards the next node

Avoid Physical Route Discovery ➲ A forwarding node will first restrict such a route

Avoid Physical Route Discovery ➲ A forwarding node will first restrict such a route discovery to its own cluster before broadcasting it network-wide. ➲ Only if no such alternative destination is available will MADPastry engage in an AODV-style route discovery broadcast.

Minimize overlay maintenance ➲ MADPastry nodes do not proactively perform routing table maintenance to

Minimize overlay maintenance ➲ MADPastry nodes do not proactively perform routing table maintenance to avoid costly maintenance overhead. ➲ Routing tables are updated using information from received and overheard packets.

Exploit Any Available Packet Information All other routing entries are obtained by overhearing data

Exploit Any Available Packet Information All other routing entries are obtained by overhearing data packets. A MADPastry packet consists of the following information: ➲ ● ● ➲ The AODV sequence number of the packet's source The AODV sequence number of the packet's previous physical hop The overlay id of the packet's source The overlay id of the packet's previous physical hop When a node overhears a packet, it updates its AODV routing table by extracting AODV sequence numbers in the packet and gains a new route to the packet's source. The existing routes are overwritten. Additionally, by overlay identifiers it inserts the nodes into the appropriate entries in the Pastry routing table and Pastry leaf set. Similarly all existing entries are overwritten.

MADPastry Routing Node which ID intends Virtual 17 Overlay ring to send a packet

MADPastry Routing Node which ID intends Virtual 17 Overlay ring to send a packet with key prefixed B, will be forwarded to the cluster with B prefixed. (B 7 E 9 A 014, 17) Node 17 17 B 207 D 11 F Pastry Routing Table 75 A 1 FFE 2 Row 0 1 2 3 0 03438687 16378092 29476800 -- Node. ID 70 Node. ID 88 Node. ID 238 Node. ID 17 4 5 6 7 45357677 58712758 65568991 79416102 Node. ID 71 Node. ID 184 Node. ID 145 Node. ID 70 8 9 A B 84219169 97434904 A 1610906 B 7 E 9 A 014 Node. ID 113 Node. ID 160 Node. ID 187 Node. ID 4 C D E F C 3739014 D 3237999 E 4514927 F 4905072 Node. ID 233 Node. ID 86 Node. ID 212 Node. ID 165 79 B 7 E 9 A 014 35 B 7 E 1 C 101 47 54 4 75 A 1 FFE 2 32 Physical Network B 7 E 1 C 101 B 7 E 9 A 014 B 207 D 11 F 39 90

Intermediate nodes on the physical path of an overlay hop consult their AODV table

Intermediate nodes on the physical path of an overlay hop consult their AODV table for the corresponding next physical hop. Virtual Overlay ID ring MADPastry Routing B 7 E 1 C 101 B 7 E 9 A 014 B 207 D 11 F 75 A 1 FFE 2 Node 17 17 79 Dest Next. Hop Others 56 256 -- 132 25 -- 61 87 -- 85 34 -- 4 54 -- B 7 E 9 A 014 B 7 E 1 C 101 47 54 4 75 A 1 FFE 2 32 Physical Network 35 B 207 D 11 F 39 90

Intermediate nodes on the physical path of an overlay hop consult their AODV table

Intermediate nodes on the physical path of an overlay hop consult their AODV table for the corresponding next physical hop. Virtual Overlay ID ring MADPastry Routing B 7 E 1 C 101 B 7 E 9 A 014 B 207 D 11 F 75 A 1 FFE 2 Node 54 17 Dest Next. Hop Others 78 214 -- 122 26 -- 53 219 -- 25 52 -- 4 32 -- 79 B 7 E 9 A 014 B 7 E 1 C 101 47 54 4 75 A 1 FFE 2 32 Physical Network 35 B 207 D 11 F 39 90

Intermediate nodes on the physical path of an overlay hop consult their AODV table

Intermediate nodes on the physical path of an overlay hop consult their AODV table for the corresponding next physical hop. Virtual Overlay ID ring MADPastry Routing B 7 E 1 C 101 B 7 E 9 A 014 B 207 D 11 F 75 A 1 FFE 2 Node 32 17 Dest Next. Hop Others 23 135 -- 174 247 -- 224 256 -- 176 28 -- 4 39 -- 79 B 7 E 9 A 014 B 7 E 1 C 101 47 54 4 75 A 1 FFE 2 32 Physical Network 35 B 207 D 11 F 39 90

Intermediate nodes on the physical path of an overlay hop consult their AODV table

Intermediate nodes on the physical path of an overlay hop consult their AODV table for the corresponding next physical hop. Virtual Overlay ID ring MADPastry Routing B 7 E 1 C 101 B 7 E 9 A 014 B 207 D 11 F 75 A 1 FFE 2 Node 39 17 Dest Next. Hop Others 23 135 -- 174 247 -- 224 256 -- 176 28 -- 4 90 -- 79 B 7 E 9 A 014 B 7 E 1 C 101 47 54 4 75 A 1 FFE 2 32 Physical Network 35 B 207 D 11 F 39 90

Intermediate nodes on the physical path of an overlay hop consult their AODV table

Intermediate nodes on the physical path of an overlay hop consult their AODV table for the corresponding next physical hop. Virtual Overlay ID ring MADPastry Routing B 7 E 1 C 101 B 7 E 9 A 014 B 207 D 11 F 75 A 1 FFE 2 Node 90 17 Dest Next. Hop Others 23 135 -- 174 247 -- 224 256 -- 176 28 -- 4 4 -- 79 B 7 E 9 A 014 B 7 E 1 C 101 47 54 4 75 A 1 FFE 2 32 Physical Network 35 B 207 D 11 F 39 90

When a packet reaches the destination of an overlay hop, that node again consults

When a packet reaches the destination of an overlay hop, that node again consults its Pastry routing table and/or leaf set to determine the next overlay hop. Virtual Overlay ID ring MADPastry Routing B 7 E 1 C 101 B 7 E 9 A 014 B 207 D 11 F 75 A 1 FFE 2 79 B 7 E 9 A 014 Leaf Set 17 54 75 A 1 FFE 2 Smaller Larger B 1011101 B 7 E 1 C 101 B 1 E 12301 B 9 E 67701 B 1 E 1 C 321 BAE 16201 B 7 E 1 C 101 47 4 32 Physical Network 35 B 207 D 11 F 39 90

Consults its AODV routing table for the physical route to execute this overlay hop.

Consults its AODV routing table for the physical route to execute this overlay hop. MADPastry Routing Virtual Overlay ID ring B 7 E 1 C 101 B 7 E 9 A 014 B 207 D 11 F 75 A 1 FFE 2 79 Node 4 17 54 Dest Next. Hop Others 23 135 -- 174 247 -- 224 256 -- 176 28 -- 35 47 -- B 7 E 9 A 014 B 7 E 1 C 101 47 4 75 A 1 FFE 2 32 Physical Network 35 B 207 D 11 F 39 90

Consults its AODV routing table for the physical route to execute this overlay hop.

Consults its AODV routing table for the physical route to execute this overlay hop. MADPastry Routing Virtual Overlay ID ring B 7 E 1 C 101 B 7 E 9 A 014 B 207 D 11 F 75 A 1 FFE 2 79 Node 47 17 54 75 A 1 FFE 2 B 7 E 9 A 014 Dest Next. Hop Others 23 135 -- 174 247 -- 224 256 -- 176 28 -- 35 35 -- B 7 E 1 C 101 47 4 32 Physical Network 35 B 207 D 11 F 39 90

When a packet reaches the destination of an overlay hop, that node again consults

When a packet reaches the destination of an overlay hop, that node again consults its Pastry routing table and/or leaf set to determine the next overlay hop. Virtual Overlay ID ring MADPastry Routing B 7 E 1 C 101 B 7 E 9 A 014 B 207 D 11 F 75 A 1 FFE 2 79 B 7 E 9 A 014 Leaf Set 17 54 75 A 1 FFE 2 Smaller Larger B 1011101 B 7 E 9 A 014 B 1 E 12301 B 8 E 67701 B 1 E 1 C 321 BAE 16201 B 7 E 1 C 101 47 4 32 Physical Network 35 B 207 D 11 F 39 90

Case Study: MADPASTRY ➲ General Performance Evaluation ● Success Rate MADPastry was compared to

Case Study: MADPASTRY ➲ General Performance Evaluation ● Success Rate MADPastry was compared to a variation of MADPastry was also not that does compared to a Broadcast exploit physical locality in agent that maintains the construction of itsno Clearly, it shows that overhead structure and routing table (NO RLM) MADPastry outperform the extra maintenance other protocols for high overhead. It simply volume of nodes. This is broadcasts all packets because, using network-wide. MADPastry, there are less flooding in the network. Therefore, less collision and network congestion.

Case Study: MADPASTRY ➲ General Performance Evaluation ● Total Generated Network Traffic Clearly MADPastry

Case Study: MADPASTRY ➲ General Performance Evaluation ● Total Generated Network Traffic Clearly MADPastry produces less network traffic, since MADPastry was designed to reduce broadcast in the network by using passing packet information to update AODV routing table and overlay maintenance.

Case Study: MADPASTRY ➲ General Performance Evaluation ● Overlay Stretch MADPastry performs better than

Case Study: MADPASTRY ➲ General Performance Evaluation ● Overlay Stretch MADPastry performs better than the variant of Pastry that does not consider localization by using Land. Marks (NO RLM). This is because after identifying a Land. Mark in a different cluster of nodes, MADPastry uses its AODV table to route packets. However, it cannot perform better than Broadcast since, broadcast will flood the network and find the closest physical route.

THE MAPNAS NAME SERVICE Distributed Service Discovery ➲ In MAPNa. S, a resource (e.

THE MAPNAS NAME SERVICE Distributed Service Discovery ➲ In MAPNa. S, a resource (e. g. a file) is identified by a unique resource key that is mapped into the logical MADPastry ID space. file 123 Hash() B 7 E 9 A 578

THE MAPNAS NAME SERVICE Nodes store the resource descriptors they are responsible for their

THE MAPNAS NAME SERVICE Nodes store the resource descriptors they are responsible for their local MAPNa. S repository. ➲ ● The resource key along with the specific network address of the resource.

THE MAPNAS NAME SERVICE Resource Advertisement When a node in a MADPastry network wants

THE MAPNAS NAME SERVICE Resource Advertisement When a node in a MADPastry network wants to make a local resource (e. g. a file) available to other nodes in the network ➲ ● ● Assign a hash key to that resource By hashing the resource's name. Node A will then construct a resource descriptor consisting of ➲ ● ● The resource key The physical network address (e. g. IP address) of the resource provider. ➲ Using MADPastry, the descriptor is routed to the node currently responsible for the resource key. ➲ That recipient node will then store the resource descriptor in its local repository.

THE MAPNAS NAME SERVICE Resource Advertisement Node 79 is responsible for resource key B

THE MAPNAS NAME SERVICE Resource Advertisement Node 79 is responsible for resource key B 7 E 9 A 578 file 123 {B 7 E 9 A 578, 17} Hash() B 7 E 9 A 578 In the final hope, Node 35(B 7 E 1 C 101) will then consult its MADPastry leaf set to Node 17(75 A 1 FFE 2) send the packet to node 4(B 207 D 11 F) using MADPastry routing forward the packet to node 79(B 7 E 1 C 101) and takes 1 physical hops. Upon reception table. As indicated in thewill overlay hop. This first overlay hop takes 5 physical hops. the Node 5(B 207 D 11 F) then MADPastry routing table to{B 7 E 9 A 578, 17} determine of this advertisement, nodeconsult 79 will its store the resource descriptor in its next to forward the advertisement packet. So the next overlay hop will be at localnode repository. node 35(B 7 E 1 C 101) and takes 2 physical hops.

THE MAPNAS NAME SERVICE Resource Discovery Node A wants to find a resource Node

THE MAPNAS NAME SERVICE Resource Discovery Node A wants to find a resource Node A does not know who has the resource desciptor ➲ Node A ➲ ➲ ● ● Assign a hash key to that resource eg. Filename By hashing the resource's name. Using MADPastry, the key is routed to the node currently responsible for the resource key. ➲ The node currently responsible for the resource will respond to node A request by sending a resource descriptor ➲

THE MAPNAS NAME SERVICE Resource Discovery {B 7 E 9 A 578, 17} file

THE MAPNAS NAME SERVICE Resource Discovery {B 7 E 9 A 578, 17} file 123 Hash() B 7 E 9 A 578 Physical Overlay Node 63(A 101 D 11 F) is interested in the file 123. Node 63 does not know which node provides the file. So node 63 produces for the filename. Node 63(A 101 D 11 F) sends a request the for key a matching resource descriptor towards the hash key B 7 E 9 A 578 using MADPastry. The first overlay hop, the request will be Node 35(B 7 E 1 C 101) will then forward the request to its leaf set member node delivered to node 35(B 7 E 1 C 101) with 3 physical hops. 79(B 7 E 9 A 014) who is responsible for the given hash key. Node 79 will check its local repository and send a response containing the descriptor {B 7 E 9 A 578, 17} back to the requester, node 63.

THE MAPNAS NAME SERVICE Handovers Cluster 1 Cluster 2 75 A 1 F 552

THE MAPNAS NAME SERVICE Handovers Cluster 1 Cluster 2 75 A 1 F 552 B 573 AB 63 N Resource descriptors L 1 75 A 1 F 532 R 1 75 A 1 F 623 Resource descriptors L 2 B 573 AA 10 R 2 B 573 AD 88 The moving node, changed its cluster membership, needfrom to pass In MANETs, nodes arehave mobile. Therefore, one node, could beand moving resource descriptors that are its local repository to its old left, and right onethe cluster to another. So a node willineventually have a different overlay Node leaf set members as those two nodes will now be responsible numerically ID as it joins another cluster. closest to the corresponding descriptor keys. So what happens to the resource descriptors in a node?

THE MAPNAS NAME SERVICE Handovers ➲ Since a handover packet could be lost. ●

THE MAPNAS NAME SERVICE Handovers ➲ Since a handover packet could be lost. ● ➲ A node can potentially end up having some resource descriptors in its local repository that it is actually not responsible for. Each node periodically checks its local repository for such descriptors and hands them over.

MAPNa. S (Performance Evaluation) MASNa. S is compared to two different kinds of resource

MAPNa. S (Performance Evaluation) MASNa. S is compared to two different kinds of resource discovery service: MAPNa. S outperforms thebroadcast-based other discovery ● Using the simple methodsapproach, in producing lower trafficdiscovery in the where service network. request This is are because: broadcast throughout the network. Ø The expanding ring tend to send more hops in network if it does not a ● the Using the expanding ringget search, response after in a few initial request. where order to avoid unnecessary network-wide Ø Broadcast-based would flood the whole broadcast, a service discovery network with a request is first propagated within a Ø MAPNa. S will use MADPastry routing to local scope of 3 hops, and increase selectively cluster numerically thechoose numberthe of hops if the request and physically to the responsible gets noclosest response. node for the resource by using the hash key.

MAPNa. S (Performance Evaluation) Clearly MAPNa. S outperforms the other discovery methods in success

MAPNa. S (Performance Evaluation) Clearly MAPNa. S outperforms the other discovery methods in success rates. This is because: The expanding ring tend to send more hops in the network if it does not get a response after a few initial request. This will cause congestion and collision, hence reducing success rate. Ø Similar, broadcast-based would flood the whole network with a request. This will cause congestion and collision in the network and reduce the success rate. Ø MAPNa. S will use MADPastry routing to selectively choose the cluster numerically and physically closest to the responsible node for the resource by using the hash key. The low traffic generated will result in less congestion and collision, thereby, giving better success rate. Ø

Conclusion ➲ ➲ 5 design principles were introduced as a considerations when designing structured

Conclusion ➲ ➲ 5 design principles were introduced as a considerations when designing structured overlays to be use on top of MANETs. In very volatile networks (e. g. high node velocities), it becomes more and more challenging to maintain the DHT structures In smaller networks, one does not necessarily need to maintain DHT structures but could use less complex approaches as well. Approaches with small structural overhead – such as broadcasting – might be preferable over DHTbased approaches.

My thoughts Assume that nodes moves slowly, if nodes were moving around faster, how

My thoughts Assume that nodes moves slowly, if nodes were moving around faster, how does it perform for resource discovery, since handover delay time might cause resource not found. ➲ No study on contention of a particular node. ➲ Will it work in a sparse network? Where clusters are small and separated far from each other. ➲

Extended thoughts? • The experiments were done with the following parameters: • Node Density

Extended thoughts? • The experiments were done with the following parameters: • Node Density is 100 nodes/km 2 using the random distribution model. • Radio range is 250 m. • If we consider the unit disc model in simulations on ns 2, the unit density is 25 nodes per unit. • The issue of routing may not be as important as contention in this case. • Since most nodes won’t have problems in finding the next hop for most protocol. 1 km 0. 5 m 1 km In one unit radius of transmission, The nodes are too many.

The End Thank You For Listening

The End Thank You For Listening

Quiz 1. 2. 3. 4. 5. Give 2 reason why unstructured DHT will not

Quiz 1. 2. 3. 4. 5. Give 2 reason why unstructured DHT will not work in MANETs? How does the ever changing routing in MANETs affects network traffic? How does MADPastry handles the introduction of a new node? Give an example of an application using MADPastry? What is the major drawback in using MADPastry where nodes move from one cluster to the other?