A DHT Chord-like mannered overlay-network to store and retrieve data

keywords: ,#networking #distributed-systems#wcf#dht ,,
Data Backup & Recovery
Design and implementation of a DHT-mannered
packet routing solution over a ring-shaped topology
overlay-network to store and retrieve data.
University of Catania
2012-13
Andrea Tino
Advances in Programming
Microsoft
technologies
Microsoft
Visual Studio
Microsoft
Windows
Microsoft PRISM
WPFToolkit .NET
.NET
Framework
Windows
Services

pag IAndrea Tino - All rights reserved 2012-13 Distributed Data Backup & RecoveryUniversity of Catania - Advances in Programming
Outline
Architecture
overview
> Architecture structure,
inspiring principles,
targets, objectives and
problem description.
> Introducing the main
actors and elements.
DDBR library:
Scalability and
flexibility
> A look at the library:
structure, projects and
namespaces.
> Detailing targets:
scalability issues and
ﬂexibility for
usage-scenarios and
future extensions.
Detailing the
Discovery
Layer
> The Discovery Layer:
purpose, functionalities
and services. Describing
design and
implementation.
> Detailing connections
with other projects.
Detailing the
Data Layer
> The Data Layer:
purpose, functionalities
and services. Detailing
data units storage and
serialization. Describing
design and
implementation.
> Detailing connections
with other projects.
Deployment
and hosting
solutions
> Hosting solutions for
the system: IIS hosting,
Windows-Services
hosting, standalone
application hosting.
> Non-homogeneous
hosting solutions.

pag IIAndrea Tino - All rights reserved 2012-13 Distributed Data Backup & RecoveryUniversity of Catania - Advances in Programming
Architecture overview

pag 1Andrea Tino - All rights reserved 2012-13 Distributed Data Backup & RecoveryUniversity of Catania - Advances in Programming
Introduction
Handling data: store & retrieve in an efficient way, introducing main
scenario and actors.
User wants to safely put some data
somewhere where he can always get it
again, anytime, anywhere!
User does
Servers are connected together in
order to form a network and
communicate with each other.
Servers come to rescue
A set of computers is considered.
They are supposed to be
server-level machines ensuring
reliability and connectivity 24/7.
What we need
Finding a way to make the store and retrieve
process easy and eﬃcient.
Problem
Also consider the solution which lets the system
be lightweight => low communication overhead.

Distributed Hash Table
Although we handle servers, Chord/Pastry like solutions for distributed
systems might become a good approach.
The idea is using a
content-addressing solution in
order to assign packets to stations.
Packets addressing
#A54B23
192.168.1.1
#C17911
192.168.1.4
#CCC34D
192.168.1.10
#E1D234
192.168.1.9
#EAB345
192.168.1.25
#FF45DD3
192.168.1.20
Servers are arranged into a
logical overlay-ring. Each
station has a r-ary leafset
corresponding to its
neighborhood. Packets are
routed basing on their
content until they reach the
correct station.
Arranging servers

Routing on the ring
Packets are placed into a station basing on their data. But stations do not
have complete knowledge of the ring. How can a packet reach its destination?
A packet can be send into the ring from every
station. The destination station Sd is the one
satisfying the IMMEDIATE_PREDECESSOR rule:
Routing
SD < SD+1
Destination
station ID
Packet ID
Station
index
Next station ID
#A54B23
192.168.1.1
#C17911
192.168.1.4
#CCC34D
192.168.1.10
Station #C17911
is an example of
1-ary leaf-set
station.
Each station knows a portion of
the ring: the number of adjacent
stations (1 direction) known by a
station is the ariety of its leaf-set.
Neighborhood
IDs are calculated using hash
functions. For packets, data is
hashed, for stations, IP-addr.
Hashing

Data-unit store...
Let’s follow the story of a packet
when stored into the ring.
#A5
#C1
#CC
#E1
#EA
#FF
T3
T1
T2
T4
T5
T6
A1
T1 T3 T5 T2
B2 DD EB C2
T1
T1
A1 B2
T2
C2
T3
DD
T5
EB
Data-units can be fragmented. INodes will
store the DUID and fragments IDs as well.
Store

...And retrival
Let’s now try to get back our
packet from the ring.
#A5
#C1
#CC
#E1
#EA
#FF
T3
T1
T2
T4
T5
T6
A1
T1 T3 T5 T2
B2 DD EB C2
T1
T1
A1 B2
T2
C2
T3
DD
T5
EB
Using the packet INode, it is possible to
locate all fragments and get the orginal DU.
Retrieve

pag IIIAndrea Tino - All rights reserved 2012-13 Distributed Data Backup & RecoveryUniversity of Catania - Advances in Programming
DDBR library:
scalability & flexibility

Targeting objectives
DDBR is a library built with a few important goals in mind.
Enabling more stations,
more functionalities, more
services and complex
behaviors.
Scalability
Service orchestration,
multiple service hosting
solutions, connectivity
through diﬀerent protocols.
Flexibility
Enabling library future
extension, encouraging
enhancements and edits.
Exstensibility
Objectives

Library structure & organization
DDBR introduces some key elements with specific roles in the whole system.
Message
ResponseMessage
DataUnitOperationMessage
DataUnitOperationResponseMessage
DataUnitOperationMessage
ns IO
ns AlgorithmsDataUnit IDataUnit
DataService DiscoveryService
InspectableDiscoveryService
InspectableDataService
DSS_001
DSS_001o
DSS_002
Orchestration &
deployment.
Station Srv
Business logic &
functionalities.
Proto Srv
Message formats,
contracts, system
common elements.
Communication
Infrastructure

Introducing proto-services
In order to achieve flexibility, proto-services are introduced by the library.
A proto-service consists
of two parts.
Proto-Service Business logic Interoperability+=
Functionality
implementation, data
management, resource
handling.
Interfaces to connect or
be connected to other
proto-services.

Detailing proto-services
Proto-servs’ business logic might need other proto-srvs.
XServiceLibrary.XService
XServiceLibrary.IXService
YServiceLibrary.
CrossServiceReferencing.
ICrossServiceReferencing
ZServiceLibrary.
WServiceLibrary.
When a proto-srv makes
itself available for
connections to other
proto-srvs, a specific
interface is considered.
The proto-srv obviously
implements a specific
interface (decorated
with WCF attributes to
make it a contract).
User can put connection behaviors for interactions
using such interfaces through delegates assignments.
Delegates & interfaces

Connecting proto-services together (1)
An example of proto-srvs connection.
CHANNEL
CHANNEL
CHANNEL
YServiceLibrary.IYService
ZServiceLibrary.
IZService
Using delegates and
interfaces, the system
enables many tech
conﬁgurations for channel
types as well.
Etereogenity
Proto-services are NOT hosted, they get
orchestrated by te real services on channel’s ends!
Orchestration

Connecting proto-services together (2)
Programmatically connect two proto-srvs.
The proto-srv only needs to be
correctly routed the valid
referenced external proto-srv.
Connecting...
CHANNEL
XServiceLibrary.
IXService
YServiceLibrary.
IZService
public class YService : IYService,
XServiceLibrary.CrossServiceReferencing.
ICrossServiceReferencing {...}
1
2
3
public class XService : IXService {...}1
YService srv = new YService(...);
srv.CrossDoSome = delegate(DoSomeMsg msg)
{...};
1
2
3
namespace XServiceLibrary.CrossServiceReferencing {
public delegate DoSomeResMsg
DoSomeDelegate(DoSomeMsg msg);
public interface ICrossServiceReferencing {
DoSomeDelegate CrossDoSome {
get; set;
}
}}
1
2
3
4
5
6
7
8

More about proto-services connections (1)
A proto-srv can be connected to... itself: reentrant connections.
Some proto-srvs need to call the
same proto-srv, of course located
somewhere else. In this case the
proto-srv communicates with a
diﬀerent instance of the same
proto-srv.
Reentrant calls
XServiceLibrary.
ServiceReferencing.
IXServiceReferencing
Although the interface used by a
proto-srv to refer to tself is the
same, actually the interface used
for reentrant calls is diﬀerent
because lets the user specify a
destination station for the call.
Service reference
Reentrant calls are used for
routed-calls. Some proto-srv, in fact,
implement functionalities that cause
a call to be routed among stations.
Call routing

More about proto-services connections (2)
Programmatically perform reentrant calls.
Generally these calls are routed
calls, a destination needs to be
speciﬁed to implement routing.
Connecting...
public class XService : IXService,
XServiceLibrary.ServiceReferencing.
IServiceReferencing {...}
1
2
3
XService srv = new XService(...);
srv.IntDoSome = delegate(DoSomeMsg msg,
Leaf dst) {...};
1
2
3
namespace XServiceLibrary.ServiceReferencing {
public delegate DoSomeResMsg
DoSomeDelegate(DoSomeMsg msg, Leaf dst);
public interface IServiceReferencing {
DoSomeDelegate IntDoSome {
get; set;
}
}}
1
2
3
4
5
6
7
8

Introducing Station services
Proto-srvs gets orchestrated, but by who?
An S-Service consists of
two parts.
ENDPOINT
ENDPOINT
ENDPOINT
S-Service Endpoint Orchestration+=
A fully implemented and
working WS, reachable
through 1+ endpoints.
ENDPOINT
ENDPOINT
ENDPOINT
One or more
incapsulated proto-srvs
reasonably connected
and organized.

Reaching a service
An S-Srv does not implement any business logic. It has two targets:
incapsulate proto-srvs and make their BL available.
ENDPOINT
USER
USER
USER
Server: Station-1
Ip-Addr: 102.54.67.89
WS: IXService
Users can access
functionalities of a
speciﬁc WS. Behind
the scenes the WS BL
is mapped/routed
onto the proto-srvs.
A WS is available
Proto-srvs are not
visible from the
outside. The service
provides its
functionalities by
orchestrating
proto-srvs.
Transparency

A significative example
An S-Srv incapsulating some proto-srvs.
Server: Station-5
Ip-Addr: 111.255.99.101
WS: IZService
NETWORK
IZService
LOCAL
Server: Station-1
Ip-Addr: 102.54.67.89
WS: IX1Service
LOCAL
NETWORK
IX1Service
IYService
IX2Service
LOCAL
USER
HTTP
USER
HTTP
Station-1 implements
the IX1Service
interface. Its BL resides
in a speciﬁc proto-srv
which needs YService
proto-srv to work.
Local connection
YService proto-srvs
needs ZService to
work. But this resides
into another station.
Net connection

pag IVAndrea Tino - All rights reserved 2012-13 Distributed Data Backup & RecoveryUniversity of Catania - Advances in Programming
Solution structure
A closer look to the projects in the solution.
DistributedDataBackupAndRecovery
CommunicationInfrastructureLibrary
DataStationServiceLibrary
DataServiceLibraryDiscoveryServiceLibrary
ObserverServiceLibrary
RingMonitor
ServiceCommonLibrary

pag VAndrea Tino - All rights reserved 2012-13 Distributed Data Backup & RecoveryUniversity of Catania - Advances in Programming
Detailing the
Discovery layer

Handling stations’ neighborhood and defining a topology.
Handling stations’ neighbors,
managing stations’ leafset.
Neighborhood
management
Organizing stations into a
speciﬁc topology. The
project sets for a ring, but
future designs might
consider other solutions.
Setting topologyPossibility, in the future,
to handle dynamic
conditions: add/remove
stations at runtime.
Dynamic conditions
handling Objectives

Locating resources in library
The library provides a specific set of proto-srvs for Discovery.
IDiscoveryService
DiscoveryService InspectionAwareDiscoveryService
ns DDBR.DiscoveryServiceLibrary
DDBR.DiscoveryServiceLibrary
ns DDBR.DiscoveryServiceLibrary.CrossServiceReferencing
ns DDBR.DiscoveryServiceLibrary.Clients ns DDBR.DiscoveryServiceLibrary.ServiceConfiguration
IDiscoveryInspection
Configuration ICrossServiceReferencingValidation
Configuration
IClient
DDBR.ServiceCommonLibrary
ns DDBR.<SCL>.ServiceConfiguration
ns DDBR.<SCL>.Exceptions
ProtoServiceException
LeafSet
DDBR.Comm...InfrastructureLibrary
ns DDBR.<CIL>.Identification
Message
LeafSet.LeafSetEntry
ResponseMessage

Handling neighborhoods
Each station needs a discovery-proto-srv
to handle its neighbor stations.
T1
T6T2
T5T3
T2
T1T3
T6T4
T3
T2T4
T1T5
T4
T3T5
T2T6
T5
T4T6
T3T1
T6
T5T1
T4T2
T1
T2
T3
T4
T5
T6
T1
T6T2
T2
T1T3
T3
T2T4
T4
T3T5
T5
T4T6
T6
T5T1
RADIUS=2RADIUS=1
Stations are connected using a ring
topology. Each stations has its own
leaf-set with a uniform radius.
Logic overlay ring
DDBR.<CIL>.LeafSet DDBR.<CIL>.LeafSet.LeafSetEntry

Defining topology
An S-Service always incapsulates
the discovery-proto-srv.
Server: Station-1
Ip-Addr: 111.255.99.101
WS: I?Service
NETWORK
IXService
LOCAL
IDiscoveryService
IYService
When external interaction is
needed, a S-Srv incapsulates locally
or remotly the discovery-proto-srv.
Crossing stations
Server: Station-2
Ip-Addr: 111.255.99.101
WS: I?Service
IXService
LOCAL
IDiscoveryService
IYService
NETWORK
Local incapsulation Remote incapsulation
DDBR.DiscoveryServiceLibrary.ICrossServiceReferencing DDBR.DiscoveryServiceLibrary.IDiscoveryService

The contracts
A closer look to the
DiscoveryServiceLibrary
namespace.
IDiscoveryService
IEchoService ILeafSetManagementService
EchoResponseMessage
Echo(EchoMessage msg)
GetLeafSetResponseMessage
GetLeafSet(GetLeafSetMessage msg)
Discovery is also (in theory)
responsible for stations’ liveness,
the EchoService is intended for
checking whether a station is up.
Station alive?
The most important contract is the
one used by the discovery-proto-srv
to provide information about one
station’s neighborhood.
LeafSet handling
DDBR.DiscoveryServiceLibrary.IDiscoveryService
DDBR.DiscoveryServiceLibrary.IEchoService
DDBR.DiscoveryServiceLibrary.ILeafSetManagementService

LeafSet management
By acting on the leafset management routines, the topology can be controlled.
Proto-srv X needs to contact a
proto-srv located on another
station. X asks for neighbors.
Requesting leafset
The discovery proto-srv
returns the leafset of the
current station.
Getting leafset
Proto-srv X can ﬁnally connect
to the desired proto-srv on the
station selected by the routing
algorithm run after receiving
neighbor stations.
Connecting
IXService
LINK
ILeafSetManagementService
IXService
LINK
ILeafSetManagementService
IXService
NETWORK
I?Service

pag VIAndrea Tino - All rights reserved 2012-13 Distributed Data Backup & RecoveryUniversity of Catania - Advances in Programming
Detailing the
Data layer

Defining what we call “data” and handling it among stations.
Managing data-units core
operations. Handling
everything related to data.
Handling data-units
Providing, under the hoods,
a persistence layer in order
to organize data-units once
saved into a station.
Persistence
The layer must be
guaranteed exclusive
access to data-units. No
other entities are allowed
to read or edit data-units.
Data access
Objectives

The library provides a specific set of proto-srvs for Data.
IDataService
DataService InspectionAwareDataService
ns DDBR.DataServiceLibrary
DDBR.DataServiceLibrary
ns DDBR.DataServiceLibrary.CrossServiceReferencing
ns DDBR.DataServiceLibrary.Clients ns DDBR.DataServiceLibrary.ServiceConfiguration
IDataInspection
Configuration ICrossServiceReferencingValidation
FragmentAndSend
Configuration
IClient
DDBR.ServiceCommonLibrary
ns DDBR.<SCL>.ServiceConfiguration
ns DDBR.<SCL>.Exceptions
ProtoServiceException
Message
ns DDBR.<CIL>.Data
DataUnit INodeTable
ns DDBR.<CIL>.Algorithms
ns DDBR.<CIL>.IO

Data units
What users store and retrieve.
A user submits a ﬁle
to the system.
User does
When the ﬁle is considered by the
system, it becomes a sequence of bytes,
thus, a data-unit.
Data Unit
Data Unit
(Data) data-unit
INode
01001001
01011100
01001010
01010101
Bytestream
INodeTable
When a data-unit is fragmented (for some reason), the
fragments’ IDs are stored in the original data-unit’s INode.
Fragmentation
ns DDBR.<CIL>.Data
DDBR.<CIL>.Data.DataUnit
DDBR.<CIL>.Data.IDataUnit
DDBR.<CIL>.Data.INodeTable
DDBR.<CIL>.Data.IINodeTable

Data units operations
Store a data-unit. Retrieve a data-unit.
A Store/Retrieve operation is
performed by calling the
same proto-srv procedure on
several stations until the
destination is reached.
Routed calls Data Unit
T3
T1
T2
T4
T5
T6
Data unit operations are routed among
stations. It means that a service
executes a call, and inside that call the
same routine opens a connection to the
same proto-srv to call the same routine.
Nested calls
Although calls are routed,
it seems like a message is
routed among stations.
Virtual msg routing
ns DDBR.<CIL>.Algorithms ns DDBR.DataServiceLibrary.ServiceReferencing

more info later...
The contracts
A closer look to the
DataServiceLibrary namespace.
IDataService
PlaceDataUnitResponseMessage
PlaceDataUnit(PlaceDataUnitMessage msg)
RetrieveDataUnitResponseMessage
RetrieveDataUnit(RetrieveDataUnitMessage msg)
The method will locate the correct
station and save the provided
data-unit there. Collisions are
handled in case they occur.
Data-unit store
When a data-unit is to be retrieved from the ring, this method will
locate the correct station and will try to retrieve the desired
data-unit from its coordinates.
Data-unit retrieval
DDBR.DataServiceLibrary.IDataService

Data unit store
Let’s follow a data-unit while being
stored into the system.
After a data-unit is stored, a
second ID might get returned
in case of collisions.
Returned ID
more info later...
T1 T2 T3 T4 T5 T6
T2 T3 T4 T5DU DU DUT2
Data Unit
T2, in this case, is the POE
T2 T3 T4 T5T5
STORING... IN IN IN
DDBR.DataServiceLibrary.DataService DDBR.DataServiceLibrary.IDataService.PlaceDataUnit

Data unit retrieval
Let’s follow a data-unit while being
retrieved from the system.
At the end of the retrieval
process, the data-unit is
returned.
Returning DU
T1 T2 T3 T4 T5 T6
T2 T3 T4 T5ID ID IDT2
ID
T2 T3 T4 T5T5
RETRIEVING... DU DU DU
T2, in this case, is the POE
DDBR.DataServiceLibrary.DataService DDBR.DataServiceLibrary.IDataService.RetrieveDataUnit

Case: store & retrieval + fragmentation
What happens when a data-unit must be fragmented?
A store-call reaches the dst
station. Fragmentation is
performed if the following is true:
Frag. policy
i >Data-unit size
Threshold
When performed, the process
causes a DU to be divided into a
certain number of DUs.
Fragmentation
Data-unit size
Fragmentation fun
i
f
µj : j = 1 i
Fragment size
Tk Tk+1 Tk+2 Tk+3
Tj Tj+1 Tj+2
Th Th+1 Th+2
Tv Tv+1 Tv+2
Tk+3 Tk+2 Tk+1 Tk
time
DDBR.DataServiceLibrary.FragmentAndSend

Calls routing
Calls are routed following
a specific algorithm.
The destination station is the one satisfying the
IMMEDIATE_PREDECESSOR rule:
Immediate predecessor
SD < SD+1
Destination
station ID
Packet IDStation
index
Next station ID
Linear Circular Bidirectional
No-Fingering Routing.
Routing
namespace DDBR.<CIL>.Algorithms {
public static SeqID RouteCircularRing(
SeqID[] table, SeqID cur, SeqID dst) {
SeqID[] lset, slls = new SeqID[0];
if (dst == cur) return cur;
if (dst > cur) lset.sortadd(cur);
foreach (SeqID id in table)
if ((dst > cur && id > cur && id <= dst) ||
dst < cur && id < cur) {
lset.sortadd(id);
if (dst < cur && id < cur && id < dst)
slls.sortadd(id);
}
if (dst < cur && slls.len == 0)
return (lset.len > 0) ? lset[last] : cur;
return (slls.len > 0) ? slls[0] :
(lset.len > 0) ? lset[0] : cur;
}}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
void route(SeqID src, SeqID dst,
SeqID[] leafset) {
if ((r = RouteCircularRing(
leafset, src, dst)) == src)
// Call reached its destination
else
// Call routine @r!
}
1
2
3
4
5
6
7
8
DDBR.<CIL>.Algorithms.Routing.RouteCircularRing

Handling data-units storage
What happens when, during a du-store, the call reaches the destination?
Data Unit
Name
.dataunit.xml
aff2.ee23.
dataunit.xml
aff2.
dataunit.xml
aff2.ee23.
dataunit.xml
aff2.ee23.
dataunit.xml
aff2.
dataunit.xml
aff2.ee23.
dataunit.xml
aff2.
dataunit.xml
aff2.ee23.
dataunit.xml
FILESYSTEM
When a data-unit needs to be physically
stored into a station, the data layer
serializes it to xml and saves the file to a
specific location.
The file is named upon the data-unit’s ID
(typically the has of its content).
Persistence
ns DDBR.<CIL>.IO DDBR.<CIL>.IO.IPersistence DDBR.<CIL>.IO.IDataInfoPersistence

Handling hash collisions in data-unit storage
What happens if a data-unit collides with another when stored?
ID.
dataunit.xml
ID1.ID.
dataunit.xml
ID2.ID.
dataunit.xml
Startup
Collision 1
Collision 2
Collision 3
ns DDBR.<CIL>.IO
When a data-unit reaches a station
and its hash collides to another
(already) sotred data-unit, the
collision occurs also in the station’s
ﬁlesystem.
Data/filesystem collisions
By appending the data-unit’s
content to its previous
(colliding) hash, collisions can
be safely solved.
Collision handling
more info later...

The role of ID2 in collision management
After data-unit storage a second ID is returned.
ns DDBR.<CIL>.IO
The ID calculated after collision
occurrance is needed by user when
retrieving that DU!
In future implementations ID2
might be used for security matters.
Returned ID2
ID is used to locate the
station where a DU is stored.
ID2 is used to locate the DU
in that station!
ID vs Returned ID2
Data Unit
T3
T1
T2
T4
T5
T6
ReturnedID2

Data-proto-srv and Discovery-proto-srv orchestration.
Exposing endpoint services to
store data-units and make
them available all the time.
Data storage services
Exposing endpoint services
to retrieve stored data-units
and make them available all
the time.
Data retrieval servicesEnabling architects and
programmers to host and
deploy services according
to library’s philosophy.
Flexible hosting &
deployment solutions Objectives

The library provides some types to be directly deployed as services.
DSS_001
ns DDBR.DataStationServiceLibrary
DDBR.DataStationServiceLibrary
DSS_001o
ns DDBR.DataStationServiceLibrary.Contracts
WSDSS_001ASDSS_001
IClient
DDBR.DiscoveryServiceLibrary
ns DDBR.DiscoveryServiceLibrary
IDiscoveryService
Message
ns DDBR.<CIL>.Data
ResponseMessage
DDBR.CommonServiceLibrary
IClient
DDBR.DataServiceLibrary
ns DDBR.DataServiceLibrary
IDataService

The services
A closer look to all deployable services.
DataStationServiceLibrary
DSS_001
PlaceDataUnit
RetrieveDataUnit
DSS_001o
PlaceDataUnit
RetrieveDataUnit
DiscoveryInfo
DataInfo
WSDSS_001
PlaceDataUnit
RetrieveDataUnit
WSDSS_001o
PlaceDataUnit
RetrieveDataUnit
DiscoveryInfo
DataInfo
<in>
<in> <in>
<in>
<inherits> <inherits>
DDBR.DataStationServiceLibrary.Contracts.IDataServiceObserverService
ns DDBR.DataStationServiceLibrary.Contracts
DDBR.DataStationServiceLibrary.WSDSS_001
DDBR.DataStationServiceLibrary.DSS_001o
DDBR.DataStationServiceLibrary.DSS_001
DDBR.DataStationServiceLibrary.ASSS_001
DDBR.DataStationServiceLibrary.WSDSS_001o

DSS_001: All-in-one
Data + Discovery incapsulation, static
leafset.
Server: DSS_001
Ip-Addr: 127.0.0.1:50000
WS: IDataService
NETWORK
IDataService
LOCAL
IDiscoveryService
REDIRECT REDIRECT
USER
HTTP
Data-proto-srv and
Discovery-proto-srv are
both locally incapsulated.
Incapsulated proto-srvs
The S-Station exposes
the IDataService
contract.
Exposed contract
Static leafset to be assigned at
conﬁguration time. IIS hosting with
DDBR conﬁguration system.
Hosting + notes
DDBR.DataServiceLibrary.DataService
DDBR.DiscoveryServiceLibrary.DiscoveryService

more info please ask me!DSS_001o: DSS_001 + observable
leafset and observable data and discovery.
Server: DSS_001o
Ip-Addr: 127.0.0.1:50001
WS: IDataServiceObserverService
NETWORK
IDataService
IDataInspection
LOCAL
IDiscoveryService
IDis...yInspection
REDIRECT REDIRECT
IObserverService
REDIRECT REDIRECT
USER
HTTP
Data-proto-srv Discovery-proto-srv
and Observer-proto-srv are all
locally incapsulated.
The S-Station exposes the
IDataService and
IObserverService
contracts.
Exposed contract
conﬁguration time. IIS hosting with DDBR
conﬁguration system. Monitorable svc.
Hosting + notes
ns DDBR.ObserverServiceLibrary
DDBR.DataServiceLibrary.IObserverService

WSDSS_001
leafset. Windows Services hosting.
Server:WSDSS_001
Ip-Addr: 127.0.0.1:50000
WS: IDataService
NETWORK
IDataService
LOCAL
IDiscoveryService
REDIRECT REDIRECT
USER
HTTP
Data-proto-srv and
the IDataService
contract.
Exposed contract
configuration time. WinSrvs
hosting with app.config assisted
DDBR configuration system.
Hosting + notes

pag 38aAndrea Tino - All rights reserved 2012-13 Distributed Data Backup & RecoveryUniversity of Catania - Advances in Programming
more info please ask me!
WSDSS_001o: WSDSS_001 + observable
leafset and observable data and discovery.
Windows Services hosting.
Server: DSS_001o
Ip-Addr: 127.0.0.1:50001
WS: IDataServiceObserverService
NETWORK
IDataService
IDataInspection
LOCAL
IDiscoveryService
IDis...yInspection
REDIRECT REDIRECT
IObserverService
REDIRECT REDIRECT
USER
HTTP
Data-proto-srv Discovery-proto-srv
and Observer-proto-srv are all
locally incapsulated.
The S-Station exposes the
IDataService and
IObserverService
contracts.
Exposed contract
configuration time. WinSrvs hosting with
app.config assisted DDBR configuration
system. Monitorable svc.
Hosting + notes
ns DDBR.ObserverServiceLibrary
DDBR.DataServiceLibrary.IObserverService

SADSS_001
leafset. Standalone application hosting.
Server:WSDSS_001
Ip-Addr: 127.0.0.1:50000
WS: IDataService
NETWORK
IDataService
LOCAL
IDiscoveryService
REDIRECT REDIRECT
USER
HTTP
Data-proto-srv and
the IDataService
contract.
Exposed contract
configuration time. Standalone
application hosting with app.config
assisted DDBR configuration system.
Hosting + notes

Deployed ring: DSS_001.T8R1.MD5
During simulations, the ring is the one reported following:
#0001AA
localhost:50000/T1/Service.svc
#013F1A
#5614AF
#7010FA
#AAA010 localhost:50000/T5/Service.svc
#CAF101
#CD1000
#FF1011
8-station ring
1r leaf-sets

Deployed ring: DSS_001o.T16R2.MD5
During simulations, the ring is the one reported following:
#0017AA
#:T16O-1/Service.svc
#05AA19
#547AB2
#993144
#A13BCD
#AA2B79
#AF27FF
#B97AFE
#BB74CA
#CC1713
#DF9193
#E174F2
#EEEEEE
#F17490
#F57040
#FFF456
#:T16O-16/
Service.svc
16-station ring
2r leaf-sets

pag VIIIAndrea Tino - All rights reserved 2012-13 Distributed Data Backup & RecoveryUniversity of Catania - Advances in Programming
Ring monitor application
Monitoring stations in the ring.
DistributedDataBackupAndRecovery
RingMonitor
Tracking stations’ status at real time and
getting info about data-units amounts.
Purpose
ns DDBR.RingMonitor
MS .NET 4 WPF C# application.
Model-View-ViewModel pattern.
Charting. Microsoft PRISM.
Tech info

A DHT Chord-like mannered overlay-network to store and retrieve data

More Related Content

What's hot (20)

Viewers also liked (10)

Similar to A DHT Chord-like mannered overlay-network to store and retrieve data (20)

More from Andrea Tino (20)

Recently uploaded (20)

A DHT Chord-like mannered overlay-network to store and retrieve data