DISTRIBUTED PRESENCE MANAGEMENT IN PEER-TO-PEER NETWORKS

Information

  • Patent Application
  • 20080019291
  • Publication Number
    20080019291
  • Date Filed
    July 18, 2007
    17 years ago
  • Date Published
    January 24, 2008
    16 years ago
Abstract
The invention concerns a computer software product comprising a plurality of peers (2′, 4, 5) adapted to participate in a peer-to-peer network where the computer software product comprises detection means for detecting actual presence information of a peer and where the computer software product comprises retrieval means for retrieving actual information about the peer, where the detection means is located on neighbour partner peer (4) of the peer (5) for detecting continuously whether the peer provides still actual information and the computer software product comprises propagation means for outdating the information about this peer in case of detecting that the peer is not alive.
Description

BRIEF DESCRIPTION OF THE DRAWINGS

The inventions is described in detail, where



FIG. 1 shows a presence management according to prior art



FIG. 2 shows a presence management in a peer to peer network according to prior art



FIG. 3 shows a presence management in a peer to peer network according to the method according to the invention



FIG. 4 shows a presence management in a Chord like peer to peer network according to the method according to the invention



FIG. 5 shows the network load of the method according to the invention



FIG. 6 shows the server load of the method according to the invention





DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS


FIG. 1 shows a client 1 that provides presence information to a central server 3. This information is provided by the central server 3 to further clients 2 that are interested. When the central server detects an presence change the information is communicated C to all further clients via the dotted lines. The central server 3 detects when the client 1 disappears, i.e. goes down or off-line, by regularly verifying the presence, i.e. the aliveness A.


Since there is a concentration of load and communication at the presence server this solution has the disadvantages mentioned in the introduction



FIG. 2 avoids this concentration. There a client peer 1′ informs directly further client peers 2′ about its presence state. The further client peer′ remains responsible for validating the actuality of this information, i.e. such a further peer will regularly verifying the presence. Thus the communication of the presence information C and the regular aliveness verification A will cause high network load.



FIG. 3 shows a peer to peer network that is configured to run the method according to the invention. The network comprises peers of three roles, the above mentioned further client peers 2′ that are interested in actual presence information of the client peer 5, this client peer 5 and its neighbor peer 4. As shown in the previous figure presence information of the peer 5 is communicated C (shown by the dotted lines) to client peers 2′. But the client peers have not to verify aliveness. This aliveness verification A is performed by the neighbor peer 4. When the client peer 5 leaves for some reason the network or the presence state simply changes, the neighbor peer 4 informs F the further client peers 2′.


The client peer 5 and the neighbor peer 4 build a reliable team. The further clients 2′ can rely on the information 4 provided by the neighbor peer. For reliability reasons the aliveness probability could even be enhanced by securing the neighbor peer with a further neighbor and thus building redundancy. What even in this coarse picture is observable, that compared with the network configuration shown in FIG. 2 the aliveness is only verified once and communicated once. Thus the churn rate would be less since there is no repetition of the aliveness verifications.



FIG. 4 shows the instantiation of the principle shown in FIG. 3 applied to a Chord ring. The Chord ring consists of the peers mentioned above, namely the client peer 5, the neighbor peer 4, and the further client peers 2′. They are interconnected as a ring, shown by the solid arcs with short cuts, called fingers, shown y the long dotted-dashed lines. These lines define the topology of the peer to peer network. Usually such a connection topology has about order of less than quadratic (in the number of peers) connections.


When a presence change of the client peer 5 is observed by the neighbor peer 4 while verifying the aliveness A, the connection topology is used to propagate this information. Here a change is propagated via the ring and via the fingers. In such an overlay peer to peer network a node (clients are also called nodes and correspond often to network devices) regularly has established connections to a specific number of neighbors, like the two neighbors in a simple ring.


In Chord the nodes build a ring topology based on the key values generated by a hash function. All nodes have connections to their right and left partners and a set of “fingers” which enable shortcuts for message routing, see I. Stoica, et al. “CHORD: A Scalable Peer-to-peer Lookup Protocol for Internet Applications” in IEEE/ACM Transactions on Networking, Vol 11, No 1 (February 2003), pp. 17-32.).


The instantiation of the invention depends on the overlay network topology defining the neighborship relations. For peers behind borders providing network address translation function, as performed by standard SOHO (small offices and home offices) routers, for presence updates direct from the presence source to a subscribed peer a dedicated IP link has to be established first. This requires renewal of firewall hole punching after the firewall timeout period. The neighbor nodes will detect the leaving of a node automatically, in order to stabilize the topology of the overlay network.


This behavior of reliable disappearance information could be used in order to provide presence information to a list of nodes which should be informed about a kind of “sudden death” of a particular node. If a node activates this function it will provide a list of nodes that should be informed about a leaving to at least one of his neighbors.


Alternatively the neighbor will receive a reference to this list, if the list is stored in the distributed database, e.g. a distributed hashing table. As long as the node is registered in the network, the node can send his actual status and the changes of the presence state to the subscribed peer nodes or alternatively publish the presence state in the hashing table, which will notify the subscribed nodes. Since only changes are sent, the number of presence messages is low.


If a sudden death of the node occurs, the neighbor node will detect the death and inform the subscribed nodes, acting on behave of the node that left the overlay.


In case the supervising neighbor node dies, the peer-to-peer backup mechanisms are used and the node sends the related information to his new neighbor. Same procedure is performed in the case the neighborship relation to the node ends, due to the joining of a new neighboring node between the node and the original neighbor.


The described invention may be extended to hierarchical network configurations characterized by specific super peer nodes supporting a couple of regular peer nodes or even subordinate peer networks. In this case the super peers are then the neighbor nodes of choice for the affiliated standard peers. This does not exclude multiple homing concepts, where one peer is connected to multiple super peers at the same time.


Super peers usually show a reduced churn rate compared to standard peers, therefore super peers can be advantageously used not only to monitor the availability of the affiliated peers, but also to collect and distribute all presence information (presence out). This is of particular importance if the use of the communication link towards an end device has to be minimized, e.g. to save power in case of a mobile device. Again failure of super peers can be compensated by standard peer to peer protocol mechanisms. Presence relevant status information of a super peer has therefore be either copied regularly to a responsible neighbor super peer, stored in a shared database like the hashing table mentioned above or retrieved from the affected standard peers.


A super peer also may collectively subscribe (presence in) for the presence information of a multitude of remote peers on behalf of its affiliated standard peers. Such a collective presence subscription between super peers would reduce the needed network wide presence update information flows. Means are required, to endow the super peers with the individual presence information access rights.



FIG. 5 shows the network load of a typical peer to peer network with a buddy list size below 200 and a keep-alive rate of 30 verifications per hour. The graph labeled mod A shows the load of the method illustrated by FIG. 2. and the graph labeled mod B shows the load of the method illustrated by FIG. 3. The simulated presence change rate was 2 per hour. The ordinates is the to ratio of network load by the method illustrated by FIG. 1.



FIG. 6 shows the tremendous server load of a central server 3 as depicted in FIG. 1 when the buddy list grows.


As a remark it should be noted that the topology induced by communications between peers could change while collaborating.

Claims
  • 1. A computer software product comprising a plurality of peers adapted to participate in a peer-to-peer network where the computer software product comprises detection means for detecting actual presence information of a peer and where the computer software product comprises retrieval means for retrieving actual information about the peer, wherein the detection means is located on neighbour partner peer of the peer for detecting continuously whether the peer provides still actual information and the computer software product comprises propagation means for outdating the information about this peer in case of detecting that the peer is not alive.
  • 2. The computer software product according to claim 1, wherein the peer-to-peer network has a chord-like ring topology where the neighbour partner peer is a predecessor or a successor.
  • 3. The computer software product according to claim 1, wherein the peer-to-peer has a hierarchical topology of layers and a neighbour partner peer has the same layer and where the information about this peer is propagated through the hierarchy.
  • 4. A method for providing actual presence information about a peer of a plurality of peers that form a peer-to-peer network, where the method comprising the steps of detecting actual presence information of a peer, providing and retrieving the actual information about the peer, wherein the detecting is distributed to a neighbour partner peer of a peer with respect to the topology of the peer-to-peer network and a neighborhood partner peer detects continuously whether its peer disappears and propagates actual presence information when detecting a disappearing of its peer to other peers.
  • 5. A network device of a telecommunication network, the node comprising at least a peer adapted to participate in a peer-to-peer network, wherein the peer is adapted to perform the method according to claim 4.
Priority Claims (1)
Number Date Country Kind
06300819.7 Jul 2006 EP regional