1 / 12

One Hop Lookups Plugin for RELOAD

IETF81@Quebec, Canada d raft-peng-p2psip-one-hop-plugin-00 Jin Peng Kai Feng Lifeng Le. One Hop Lookups Plugin for RELOAD. Agenda. Why One Hop Lookups Plugin? Peer data structure Event notification procedure Updates message Leader choosing strategies Fault tolerance.

etta
Télécharger la présentation

One Hop Lookups Plugin for RELOAD

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. IETF81@Quebec, Canada draft-peng-p2psip-one-hop-plugin-00 Jin Peng Kai Feng Lifeng Le One Hop Lookups Pluginfor RELOAD

  2. Agenda • Why One Hop Lookups Plugin? • Peer data structure • Event notification procedure • Updates message • Leader choosing strategies • Fault tolerance

  3. Why One Hop Lookups Plugin? • Topology Plugin of RELOAD • Each overlay can select an appropriate overlay algorithm that relies on the common RELOAD core protocols and code • High demands for the improvement of routing efficiency in real time applications • Chord: • One Hop Lookups:

  4. Why One Hop Lookups Plugin? • Requirements for RELOAD • The one hop lookups plugin is based on the methods provided by RELOAD which include the framework of commonly-needed methods defined in the Topology Plugin. • RELOAD defines three methods for overlay maintenance: Join, Update and Leave. The one hop lookups plugin defines the contents of those message. • Based on the architecture of RELOAD to support different usages.

  5. Peer data structure • Routing table • A full routing table contains information about every node in the overlay • Predecessor and successor information • Neighborhood information • Unit leader information • Slice leader information • Slice leader list

  6. Event notification procedure X 1 2 2 Slice leader Unit leader 4 2 Ordinary node 3 3 5 4 4

  7. Updates message • The definition of update messages based on the event notification • enum { eventUpdate (0), dataStructureUpdate (1), (255) } UpdateType; • Two kinds of update • Event update / notification • Keeping the accuracy of routing tables • Data structure update • Mainly used in the transferring of data structure during the peer joining procedure

  8. Updates message • Event update / notification base • enum { keepAlive (0), ordinaryPeerChange (1), unitLeaderChange (2), sliceLeaderChange (3), (255) } EventType; • enum { peerJoin (0), peerLeave (1), peerChange (2), (255) } ChangeType; • The EventType and ChangeType can construct all the event notification messages • Keep-alive • Ordinary peer join / leave • Unit leader join / leave • Slice leader join / leave

  9. Updates message • Update request • The update request is composed of two kinds of list • Event notification list • Data structure list • All the peers in the overlay can use this Update request to inform event notification or transfer routing information • Update response • It is only has a response number to represent the receiver’s attitude which may include success, fail and error

  10. Leader choosing strategies • Default choosing schema • Dynamic choosing the successor of the mid-point peer in the slice or unit space • A SandStone like schema • Identify well connected and provisioned peers as “Super Node”, all the super nodes form a parallel ring and do not participate in the routing procedure • The super node can act as a slice leader whose work is collecting the notifications and spreading them in time • The unit leader can be chosen by the default choosing schema

  11. Fault tolerance • First hop fail • If a query fails on its first attempt, the receiver can respond a RouteQueryAns message to give a closer peer’s information which can make the initiator construct a two hop lookups • In most of cases, two hops are enough to locate one peer or resource • Leaders fail • The successor detects the failure and becomes the new leader by sending the update message

  12. Thanks for your attention!Q&A?

More Related