21
Middleware issues: Middleware issues: From P2P systems to Ad Hoc From P2P systems to Ad Hoc Networks Networks Franca Delmastro Franca Delmastro [email protected] [email protected] Pervasive Computing & Networking Lab Pervasive Computing & Networking Lab (PerLab) (PerLab) IIT-CNR Pisa IIT-CNR Pisa MobileMAN Project MobileMAN Project Helsinki, June 7 Helsinki, June 7 th th 2004 2004

Middleware issues: From P2P systems to Ad Hoc Networks

Embed Size (px)

DESCRIPTION

Middleware issues: From P2P systems to Ad Hoc Networks. Franca Delmastro [email protected] 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: - PowerPoint PPT Presentation

Citation preview

Middleware issues:Middleware issues:From P2P systems to Ad Hoc From P2P systems to Ad Hoc

NetworksNetworks

Franca DelmastroFranca [email protected]@iit.cnr.it

Pervasive Computing & Networking Lab Pervasive Computing & Networking Lab (PerLab)(PerLab)

IIT-CNR PisaIIT-CNR Pisa

MobileMAN ProjectMobileMAN ProjectHelsinki, June 7Helsinki, June 7th th 20042004

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

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

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

Logical & Physical distances

Pastry Ring0 2128 - 1

The Pastry Ring

N1

X1 = H(N1)

N2

X2 = H(N2)

L1

X1

X2

L2

(K2 ,V)

L2 = H(K2 )

(K1 ,V)

L1 = H(K1)

0 2128 - 1

Pastry routing tables

0 2128 - 1

10233001

10233232

02212102

11301233

10323302

10233102

Pastry Multi-hop Routing

23000101

02212102

Route(23302121)

23301101

23301201

33301201

0 2128 - 1

22301203

10233102

bestMatch(RoutingTable[0], 23302121 ) =

22301203

Compare(10233102, 23302121) = 0

Joining the Ring

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

A

B1

B2

Bk

Z

0 2128 - 1

X

Join(X)

Route(X)

X

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.

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

NeSt

Applications

Middleware

Transport

Network

MAC

Using Cross-Layer to CROSS-ROAD

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

CROSS-layer Ring Overlay for AD hoc networks

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

Middleware level

A

B

CROSS-ROAD overlay

Nodes providing service S

Ad Hoc Network nodes

Network level

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

B

Interactions with NeSt

NeSt

NetworkData

Abstraction

MiddlewareData

AbstractionMiddleware

Network

Node A

Middleware

Network

NeSt

NetworkData

Abstraction

MiddlewareData

Abstraction

Node BLocal

Provided services

LSU routing pkt containing services

publications and topology updates

Topology update and

remote servicesApplication

messages

CROSS-ROAD Routing Tables

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

Network Routing Table

Destination IP

address

Next Hop IP add.

Cost Services

CROSS-ROAD Routing Table

Destination ID = H(IP

address)

Cost

Pastry vs CROSS-ROAD PASTRY:

Join operation requires many remote connections to recover routing tables contents

CROSS-ROAD: Join operation does not

require remote connections: each node can build its ring autonomously

HIGH COST at middleware level

NO COST at middleware level

Pastry vs CROSS-ROAD PASTRY:

The detection of disconnection events requires polling cycles towards remote nodes

CROSS-ROAD: Disconnection events

are detected by the netwrok routing protocol through LSU packets

HIGH COST at middleware level

NO COST at middleware level

Pastry vs CROSS-ROAD PASTRY:

Routing table fixed size involves a not complete knowledge of the network

CROSS-ROAD: Routing table size

depends on the number of nodes taking part to the service

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

Pastry vs CROSS-ROAD PASTRY:

Subject-based routing involves a multi-hop middleware routing

CROSS-ROAD: Subject-based routing

involves a peer-to-peer connection

O(log(N)) middleware lookup cost

O(1) middleware lookup cost, the remaining is a

routing task

CROSS-ROAD Software Architecture

P2PCommonAPI

CROSS-ROAD

CROSS-ROAD Node

NodeHandle

CROSS-ROAD Routing Table

Endpoint

Hash ID Factory

CROSS-ROAD Messages

NeStService

Notification

TopologyAbstraction

(GRAPH)

Link-State Routing

Topology table Routing Table

Routing Messages

Socket Manager

Client/Server Manager

LSU Management