MarketNet Directory Services (MDS)

1
MarketNetDirectory Services(MDS)

• Weibin Zhao
• Henning Schulzrinne
• Department of Computer Science
• Columbia University

2
Directory Services

• Replication fault tolerance, availability and
  performance

Client
Query
Registration
Reply
Acknowledge
Server 1
Server 2
Advertisement Control Message Registration
Propagation
Server 3
Server Group
3
MDS MarketNet Directory Services

• Approach
• built on top of an existing directory service
  system
• SLP Service Location Protocol
• lower cost, can be reused
• enhance SLP reliability and scalability
• adjust to service dynamic changes and losses
• scale to large systems
• Critical issues
• data organization and distribution
• handling failures server crashes and network
  partitions
• server group management

4
MDS Design Overview

• Peering architecture
• multiple server groups
• Asynchronous replication
• high availability anti-entropy (eventual
  consistency)
• Direct forwarding
• propagate new updates rapidly
• Automated server group management
• server advertisement request
• Dynamic states
• Version resolution
• Handling deleted states

5
Peering Architecture

• Peers
• share serving groups
• have a persistent peering connection
• a reliable FIFO communication channel TCP
• Topology
• an arbitrary connected graph, multiple groups
• best for a full mesh

y
Server 1 (x,y)
Server 2 (y,z)
x
z
Server 3 (x,z)
6
Controlling Timestamps

• acceptID
• for updates propagation
• acceptServer the first replica that accepts
  the update
• acceptTS timestamp at acceptServer
• arrivalTS
• for dynamic states
• purge expired states
• versionTS
• for version resolution
• each registration only updated by one client
• new version overwrites the old one

7
Messages

• Server group management
• Advertisement server domain name, serving
  groups
• AdvertisementRequest
• PeerList
• KeepAlive
• Bye
• Updates propagation
• StateReport summary of states
• BatchBegin
• BatchEnd
• MeshForward Extension acceptID, versionTS
• (append to update messages when propagated
  among replicas)

8
Peering Connections

• Identify
• a connection
• from which an original Advertisement is received
• original Advertisement
• advertised domain name sender domain name
• Maintain
• KeepAlive
• handling failures
• server crashes, network partitions

9
Peer Management

• Discover new peers
• static configuration, DHCP
• Advertisement multicast, unicast
• exchange PeerList with a new peer
• forward a new peer Advertisement to existing
  peers
• Remove an old peer
• peering connection has been closed
• KeepAlive time out
• Bye received

10
Ordering and Summary

• Ordering acceptID
• total order accepted by same server
• partial order in the system
• State summary
• all the latest acceptIDs
• ((S1, T1), (S2, T2), (Sn, Tn))
• carried by StateReport

11
Updates Propagations

• Anti-entropy
• pull model
• when StateReport is received
• uni-direction from sender to receiver
• scheduling StateReport
• new peer and after failures (reboot and network
  partitions)
• send to one peer at a time
• Direct forwarding
• push model
• propagate new updates quickly
• one-hop from acceptServer to its peers

12
Transfer Modes

• Normal mode
• ordering transfer
• Batch Mode
• unsorted states between BatchBegin and BatchEnd
• deliver summary after a whole batch has been
  received

new peer
after an anti-entropy
Direct forwarding
Anti-entropy
Sending
receive BatchBegin
new peer
Normal
Batch
receive BatchEnd
Receiving
13
Performing Updates

• Version control
• use versionTS new version overwrites the old
  one
• Dynamic states
• soft state remove a state when it expires
• Handling deleted states
• deletion flag
• propagation (1) registration, (2)
  deregistration
• no special purging process

14
Survivability

• Handling Failures
• server crashes, network partitions
• server side
• KeepAlive time out
• deliver a batch after BatchEnd
• client side
• automatically discover/select/switch servers
• response time out

Server 1
Server 2
Client
15
Conclusions

• MDS
• a robust distributed dynamic directory service
• for general purposes and customized applications
• Contributions
• defined a lightweight directory replication
  protocol
• mSLP - mesh-enhanced Service Location Protocol
• standalone and integrated implementation in Java
• Internet Draft and ICCCN00 paper
• Future work
• advance mSLP to RFC

16
Demo

• Metro-north and Diablo (servers) peering
• Ruihan (client) discovers servers
• registration propagations
• failures Diablo crashes and network partitions
• Ruihan switches to Metro-north
• Diablo recovers

Metro-north
Diablo
Ruihan