Abstract:
A system and method for event notification and access control for Distributed Hash Tables (DHTs) using an event triggering mechanism for DHT-based Peer-to-Peer (P2P) overlay networks is described. According to an embodiment of the invention, a user interested in certain event can insert a trigger into the DHT. When the event occurs, the trigger fires and causes a pre-defined action to be executed. According to another embodiment of the invention, a user peer inserts a trigger resource record, which includes instructions to execute a specified action upon occurrence of the event, into the DHT. A monitored resource record, with which the event is or will be associated, is identified. A monitoring peer, responsible for maintaining the monitored resource record, is then identified. The trigger resource record is maintained at the monitoring peer.

Description:
TECHNICAL FIELD  
       [0001]    The present invention relates to event identification in P2P networks. In particular, the invention relates to an event triggering mechanism for DHT-based P2P overlay networks. 
       BACKGROUND 
       [0002]    A hash table is a data structure that associates keys with values. A key may be, for instance, a person&#39;s name. The corresponding value may then be that person&#39;s contact address (e.g. email address or Session Initiation Protocol (SIP) Uniform Resource Identifier (URI)). The primary operation a hash table supports is lookup: given a key, the hash table finds the corresponding value. 
         [0003]    Distributed Hash Tables (DHTs) provide a lookup service similar to a hash table. However, unlike regular hash tables, DHTs are decentralized distributed systems. In a DHT, the responsibility for maintaining mappings from names to values is distributed among the nodes (or peers) participating in the system. This is achieved by partitioning the key space among the participating nodes. The nodes are connected together by an overlay network, which allows the nodes to find the owner of any given key in the key space. 
         [0004]    In the overlay network, each node maintains a set of links to other nodes. This set of links is the node&#39;s routing table. In some DHTs such as Chord (Stoica et al.: “Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications”; in Proceedings of the ACM SIGCOMM&#39;01 Conference, August 2001, San Diego, Calif., USA) the entries in the routing table are called fingers. In addition to the routing table, each node also maintains another data structure called the neighbour list. The neighbour list contains pointers to the immediate successors and predecessors (i.e., neighbours) of the node in the overlay network. A node picks its neighbours according to a certain structure, called the network&#39;s topology. One such topology, known as a ring topology in which the nodes are peers, is illustrated in  FIG. 1 . A peer  101  has immediate predecessors  102 ,  103  and immediate successors  104 ,  105 . The peer  101  also maintains links in its routing table to three fingers  111 ,  112 ,  113  elsewhere in the network. 
         [0005]    Each peer participating in the DHT is identified by its peer identifier (peer-ID), which is created by calculating a hash over certain piece of unique information such as the peer&#39;s IP address and port number. Many DHTs use Secure Hash Algorithm One (SHA-1) as the base hash algorithm. In DHTs, peer identifiers and resource identifiers (i.e. keys) are stored in the same namespace. As an example, in the Chord DHT, each peer is responsible for storing resources whose identifiers fall between its predecessor&#39;s peer identifier and its own peer identifier. Resource identifiers (resource-IDs) are also constructed (in an analogous manner to peer-IDs) by calculating a hash over a piece of information that uniquely identifies the resource. As an example, if the resource record is the contact address of a user&#39;s SIP terminal, the resource-ID can be formed by calculating a hash over the user&#39;s SIP URI. In a DHT, a user is responsible for storing his own contact information only if the resource-ID of his contact information falls in the portion of the identifier space his endpoint is responsible for. 
         [0006]    Although DHTs have many benefits such as low capital cost, low operational cost, scalability, and robustness, they face certain challenges when used to distribute interpersonal communication systems such Voice over IP (VoIP), instant messaging and presence systems. In traditional client-server communication systems, all of the system&#39;s intelligence is located in centralized servers, whereas in peer-to-peer (P2P) systems, all of the system&#39;s intelligence is distributed to the endpoints. Client-server VoIP relies on centralized servers when providing features such as call control, presence, user registration, telephony supplementary services, and Network Address Translator (NAT) traversal, among other things. In P2P VoIP, these features need to be provided in a distributed fashion. 
         [0007]    One challenge is the provision of a distributed presence service. In a pure P2P presence system, there is no central presence server to which users can update their presence status, and which can inform users about the changes in their buddies&#39; presence status. Instead, users are responsible for tracking the presence status of their buddies themselves. To detect when his buddies join the P2P overlay, a user must poll these offline buddies periodically. Each periodic poll operation requires a P2P lookup that attempts to fetch the contact record of the buddy from the DHT. If the contact record cannot be found, the buddy is still offline. Ideally, the interval at which offline buddies are polled would be rather short so that there would not be a long gap between the buddy joining the overlay and the user detecting this. The problem with this approach is that the periodic lookups for offline buddies generate a lot of extra traffic into the overlay. If the polling interval is frequent, it is not uncommon that the majority of lookups in the system are lookups for offline buddies. This has a negative impact on performance since the system is flooded with such lookups. 
         [0008]    To reduce the amount of polling traffic, the polling interval can be kept rather infrequent. This is the approach that real-world P2P presence systems have been forced to take. In these systems, it is not uncommon that it takes over five minutes from the moment that a user joins the system before his buddies detect this. This naturally results in poor user experience. Thus, P2P presence systems would greatly benefit from a mechanism that reduces or eliminates the polling traffic and yet makes the detection of peers becoming online almost immediate. 
         [0009]    Telephony supplementary services are also difficult to provide in a distributed environment. In a traditional client-server system, supplementary services such as call forwarding, call barring, and completion of calls to busy subscribers are handled by centralized network components. There is no straightforward way to implement such services in a P2P environment. 
         [0010]    One further problem is service discovery. In a P2P system, peers providing a particular service register as service providers into the overlay using the service identifier of the service. Other peers discover service providers by sending lookups for the service identifiers. If no service provider is available, a peer interested in the service must perform periodic lookups to detect when the service becomes available. Such periodic queries again cause extra traffic and degrade the performance of the system. 
       SUMMARY  
       [0011]    It is an object of the present invention to address the difficulties associated with providing presence services, telephony supplementary services, and service discovery (inter alia) in DHT-based P2P systems. 
         [0012]    The invention generally provides a generic event notification and access control mechanism for DHTs using an event triggering mechanism for DHT-based P2P overlay networks. A user interested in certain event can insert a trigger into the DHT. When the event occurs, the trigger fires and causes a pre-defined action to be executed. 
         [0013]    In accordance with one aspect of the present invention there is provided a method of monitoring an event in a P2P network having a DHT. A user peer inserts a trigger resource record, which includes instructions to execute a specified action upon occurrence of the event, into the DHT. A monitored resource record, with which the event is or will be associated, is identified. A monitoring peer, responsible for maintaining the monitored resource record, is then identified. The trigger resource record is maintained at the monitoring peer. 
         [0014]    The identification of the monitoring peer may be enabled by the calculation of a resource-ID key from the monitored resource record, for example by the use of a hash algorithm. 
         [0015]    The monitoring peer may store the trigger record resource in a trigger database. Then when any event takes place which affects the monitored resource record, the monitoring peer checks the contents of the trigger database to find a trigger record resource for that event and monitored record. If a trigger record resource for that combination is present, then the specified action is executed. 
         [0016]    Typical events which can be monitored in this manner include: the creation of the monitored resource record; the removal of the monitored resource record; an update to the monitored resource record; an attempt to read the monitored resource record; a counter associated with the monitored resource record reaching a threshold value; and a predetermined time period before expiry of the monitored resource record being reached. The specified action may include: sending a notification to the user peer that the event has taken place; sending a notification to an owner of the monitored resource record that the event has taken place; deleting the monitored resource record; incrementing or decrementing a counter contained in the trigger resource record; and/or allowing or restricting access to the monitored resource record. 
         [0017]    In one embodiment, the event is the creation of the monitored resource record. In this case, when the trigger resource record is inserted into the DHT the monitored resource record does not yet exist. A resource identifier is predicted for the monitored resource record, and this resource identifier is used to identify of the monitoring peer. 
         [0018]    The monitored resource record may be the contact information of a second user, and the creation of the monitored resource record may result from the second user becoming online. Thus the trigger record may be used to provided a presence service. Alternatively, the monitored resource record may be a service resource record associated with a service, and the creation of the monitored resource record may result from the service becoming available. 
         [0019]    In either case a lookup request may initially be sent by the user peer to identify whether the monitored resource record exists. The lookup request may contain instructions to insert the trigger resource record into the DHT if it is identified that the monitored resource record does not exist. 
         [0020]    The trigger resource record may be associated with an existing monitored resource record. In one embodiment the event may be an attempt by a third party peer to gain access to the monitored resource record. The trigger resource record may then include a whitelist of peers for which access to the monitored resource record is allowed, and/or a blacklist of peers for which access to the monitored resource record is not allowed. The specified action may include permitting or restricting access to the monitored resource record on the basis of whether the third party peer is on the whitelist or blacklist. The trigger resource record may include an access restriction reason why access is restricted for peers on the blacklist. 
         [0021]    The use of a whitelist and/or blacklist enables the provision of telephony services. For example, call redirecting may be implemented if the access restriction reason is that incoming calls to the monitored resource record should be redirected. The specified action may include restricting access to the third party peer and providing to the third party peer an identification of an alternative resource record to which access should be attempted. Completion of calls to busy subscribers may be implemented if the access restriction reason is that the user peer is busy, and the specified action includes restricting access to the third party peer and notifying the third party peer that the user peer is busy. In this case the third party peer may insert a further trigger resource record into the DHT to monitor the trigger resource record, so that if the trigger resource record is removed a further attempt to gain access to the monitored resource record can be made. 
         [0022]    The information in the trigger resource record may include: a trigger-ID identifying the trigger resource record; a monitored-ID identifying the monitored resource record; an event-ID identifying the type of event being monitored; a trigger-action-ID identifying the specified action which is to take place upon occurrence of the event; and an inserting-peer-ID identifying the user peer. 
         [0023]    The invention also provides a P2P network comprising peers arranged to carry out the method described above. 
         [0024]    In accordance with another aspect of the present invention there is provided a user peer for use in a P2P network having a DHT. The user peer comprises a processor for generating a trigger resource record which includes instructions to execute a specified action upon occurrence of a monitored event and an identification of a monitored resource record with which the monitored event is or will be associated. The user peer also comprises a transmitter for sending the trigger resource record into the P2P network for insertion into the DHT, such that the trigger resource record is maintained at a monitoring peer responsible for maintaining the monitored resource record. 
         [0025]    In accordance with another aspect of the present invention there is provided a monitoring peer for use in a P2P network having a DHT. The monitoring peer comprises a storage function for maintaining a monitored resource record. A receiver is provided for receiving a trigger resource record from a user peer, the trigger resource record including instructions to execute a specified action upon occurrence of an event associated with the monitored resource record. A processor is provided for executing the specified action. The monitoring peer is also arranged to maintain the trigger resource record, optionally in a trigger database. 
         [0026]    It will be appreciated that the terms “user peer” and “monitoring peer” are labels used for the sake of convenience, and that one peer may able to perform the functions of both simultaneously. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0027]      FIG. 1  is a schematic diagram illustrating nodes in a ring topology; 
           [0028]      FIG. 2  is a flow diagram illustrating the insertion of a trigger into a DHT; 
           [0029]      FIG. 3  is a flow diagram illustrating the use of a DHT trigger to implement presence service; and 
           [0030]      FIG. 4  is a schematic diagram illustrating the architecture of a peer. 
       
    
    
     DETAILED DESCRIPTION 
       [0031]    DHT Trigger 
         [0032]    A DHT trigger takes the form of a special resource record that can be stored in a DHT-based overlay network either in a standalone fashion or by attaching it to an existing resource record. In the first case, the trigger is called a standalone trigger, since it has not been attached to any resource record. In the second case, the trigger is called an attached trigger. Standalone and attached triggers are further discussed below. 
         [0033]    The protocol that is spoken between the peers in an overlay network is called the peer protocol. In Peer-to-Peer Session Initiation Protocol (P2PSIP) systems, the Resource Location and Discovery (RELOAD) protocol is used as the peer protocol. Trigger records are created by using a new peer protocol message which is here referred to as the InsertTrigger message. A DHT trigger can be used to subscribe to events occurring in the overlay network. When the event occurs, the action specified in the trigger record is executed. One possible action is the generation of a notification request. Such notifications are sent using a new peer protocol message which is here referred to as the TriggerAction message. 
         [0034]    Trigger Events 
         [0035]    As mentioned above, DHT triggers can be used to subscribe to various events occurring in a P2P overlay network. Examples of such events are listed in Table 1. 
         [0000]    
       
         
               
             
               
               
               
               
             
           
               
                 TABLE 1 
               
             
             
               
                   
               
               
                 Trigger events 
               
             
          
           
               
                   
                 Event 
                   
                   
               
               
                   
                 type 
                 Event-ID 
                 Description 
               
               
                   
                   
               
               
                   
                 Resource- 
                 1 
                 A resource record is created. 
               
               
                   
                 created 
                   
                 Example: Alice wants to be notified 
               
               
                   
                   
                   
                 when Bob stores his contact 
               
               
                   
                   
                   
                 information into the overlay. 
               
               
                   
                 Resource- 
                 2 
                 A resource record is removed. 
               
               
                   
                 removed 
                   
                   
               
               
                   
                 Resource- 
                 3 
                 A resource record is updated. 
               
               
                   
                 updated 
                   
                 Example: Alice&#39;s P2P application 
               
               
                   
                   
                   
                 wants to be notified whenever Bob&#39;s 
               
               
                   
                   
                   
                 IP address changes. 
               
               
                   
                 Resource- 
                 4 
                 A resource record is fetched: 
               
               
                   
                 read 
                   
                 Example: Alice wants to be notified 
               
               
                   
                   
                   
                 whenever somebody fetches a file 
               
               
                   
                   
                   
                 she has stored in the overlay. 
               
               
                   
                 Counter- 
                 5 
                 A counter associated with a 
               
               
                   
                 threshold- 
                   
                 resource record reaches a specified 
               
               
                   
                 reached 
                   
                 threshold value. In this case, the 
               
               
                   
                   
                   
                 trigger is not attached to a resource 
               
               
                   
                   
                   
                 record, but to a counter. 
               
               
                   
                 Resource- 
                 6 
                 A resource record is about to 
               
               
                   
                 about-to- 
                   
                 expire. Example: Alice wants to be 
               
               
                   
                 expire 
                   
                 notified before her contact 
               
               
                   
                   
                   
                 information expires so that she can 
               
               
                   
                   
                   
                 refresh the contact information. 
               
               
                   
                   
               
             
          
         
       
     
         [0036]    Trigger Actions 
         [0037]    Each trigger specifies an action that should be carried out when the event to which the user has subscribed by inserting the trigger occurs. When the event occurs, the action specified in the trigger is carried out. Possible actions include for instance those specified in Table 2. 
         [0000]    
       
         
               
             
               
               
               
               
             
           
               
                 TABLE 2 
               
             
             
               
                   
               
               
                 Trigger actions 
               
             
          
           
               
                   
                 Action type 
                 Action-ID 
                 Description 
               
               
                   
                   
               
               
                   
                 Notify-me 
                 1 
                 Send a TriggerAction message to 
               
               
                   
                   
                   
                 the party that inserted the trigger 
               
               
                   
                 Notify- 
                 2 
                 Notify the owner of the resource 
               
               
                   
                 owner 
                   
                 record for which the trigger was 
               
               
                   
                   
                   
                 created by sending a 
               
               
                   
                   
                   
                 TriggerAction message. 
               
               
                   
                 Delete 
                 3 
                 Delete the resource record to 
               
               
                   
                   
                   
                 which the trigger is attached. 
               
               
                   
                 Increment- 
                 4 
                 Increment the counter of the 
               
               
                   
                 counter 
                   
                 trigger record by one 
               
               
                   
                 Decrement- 
                 5 
                 Decrement the counter of the 
               
               
                   
                 counter 
                   
                 trigger record by one 
               
               
                   
                 Validate- 
                 6 
                 Check whether the party trying to 
               
               
                   
                 peer 
                   
                 access the resource record has 
               
               
                   
                   
                   
                 the permission to do so 
               
               
                   
                   
               
             
          
         
       
     
         [0038]    Standalone Triggers 
         [0039]    A standalone trigger is used when the resource record that is of interest to the user does not exist yet, meaning that no-one has stored a resource record with the specified resource-ID in the overlay. In this case, the event the user is interested in is the creation of the resource record. A standalone trigger is stored using the resource-ID of the resource to which the trigger is related. As an example, if the resource is the contact information of user Alice, whose SIP URI is “sip:alice@example.com”, the trigger is stored using the resource-ID of Alice&#39;s contact record. This resource-ID can be obtained by calculating a hash over the SIP URI of Alice using the hash algorithm defined by the overlay algorithm. 
         [0040]    Since the triggers are stored using the resource-ID of the record with which they are associated, they will be stored by the peer responsible for maintaining this record. This can be understood with reference to  FIG. 4 , which is a schematic diagram of the architecture of a typical peer  41 . The peer  41  includes a transmitter  42  for sending information (such as trigger records) into the network, and a receiver  43  for receiving information from the network. A processor  44  is capable of generating trigger records and/or carrying out actions specified in a trigger record. Records are stored by a storage medium  45 , part of which may be a dedicated trigger database  46 . 
         [0041]    Returning to the example above and considering also the ring topology shown in  FIG. 1 , suppose that the user peer  101  wishes to be notified when Alice comes online. The resource-ID for Alice&#39;s contact record is calculated, and this will indicate which of the peers in the network (for example, the peer  112  maintained as a finger by the user peer  101 ) will be responsible for maintaining Alice&#39;s contact record when she becomes online. Since peer  112  is responsible for Alice&#39;s contact record, it also stores the trigger in its trigger database  46 . 
         [0042]    This process is also illustrated in  FIG. 2 . In step S 21 , the user peer  101  creates a trigger record. In step S 22  this trigger is inserted into the DHT. In step S 23  the resource with which the trigger is (or will be) associated is identified. In the example above this resource is Alice&#39;s contact record. In step S 24 , the resource-ID of this resource is determined. In step S 25  the resource-ID is used to determine which peer (e.g. finger  101 ) is responsible for maintaining this resource. In step S 26  the trigger is stored at that peer. 
         [0043]    Whenever a peer is requested to store a resource record, it first checks whether there exist any standalone triggers stored with the resource-ID of the resource. If triggers exist, their trigger actions are executed. So, in the example above, as soon as peer  112  is requested to store Alice&#39;s contact record, it checks its trigger database and discovers the trigger inserted by the user peer  101 . It then executes the action contained therein, which is to notify the user peer  101  that Alice has come online. 
         [0044]    Standalone triggers can be created in two ways. In one mechanism, an InsertTrigger request can be sent to the peer responsible for the resource-ID that is of interest to the sender. In another mechanism, a peer performing a lookup can specify in the peer protocol Lookup request that a trigger should be automatically created if no resource record with the specified resource-ID exists. For this, a new flag, create TriggerIfResourceNotFound can be used in the Lookup request. 
         [0045]    Attached Triggers 
         [0046]    An attached trigger is a trigger that has been created for an existing resource record. Attached triggers can be used to add extra service logic to resource records. As an example:
       A user can attach to his contact record a trigger that tells the peer responsible for storing the contact record to notify the user when the contact record is about to expire.   A user can attach a trigger that tells the peer responsible for storing a specific resource record to inform the user whenever the resource record is updated or deleted. If the resource record is a contact record, the user may insert a trigger so that she learns whenever the contact address associated with the contact record changes.       
 
         [0049]    There are different types of attached triggers:
       Regular—A standard trigger that is extended by the other types   Counter—Extends a regular trigger with the ability to keep track of how many times the trigger event has occurred.   Access-control—Extends a regular trigger with an access control list that specifies which peers are allowed to access the resource record and which peers aren&#39;t.       
 
         [0053]    Multiple Peers Adding Triggers to the Same Resource 
         [0054]    In many cases, multiple peers are interested in adding triggers to the same resource. This can happen, for instance, when multiple peers have the same user as a buddy and want to learn when that user stores her contact information into the overlay. To support this, peers should store the triggers they are responsible for in a trigger database. The key to the trigger database is the resource-ID of the resource for which the trigger was created. Whenever a particular resource is created, accessed, modified or deleted, the peer responsible for the resource should check whether the trigger database contains any trigger records that are related to the resource-ID of the resource and process them. 
         [0055]    Transferring Trigger Records 
         [0056]    Trigger records need to be transferred between peers in the overlay network as new peers join and old ones leave, in exactly the same fashion as regular resource records are transferred. The fact which peer is responsible for storing a given resource record at a specific moment is dictated by the DHT algorithm. A standalone trigger is transferred whenever a new peer that joins the overlay network becomes responsible for the portion of the identifier space to which the resource-ID for which the trigger was created belongs or when the peer that is currently responsible for the resource-ID leaves the network. Attached triggers are transferred whenever the resource record to which the trigger has been attached is transferred. 
         [0057]    Format of a Trigger 
         [0058]    A trigger record consists of the pieces of information specified in Table 3. 
         [0000]    
       
         
               
             
               
               
             
           
               
                 TABLE 3 
               
             
             
               
                   
               
               
                 Fields of a regular trigger 
               
             
          
           
               
                 Field 
                 Description 
               
               
                   
               
               
                 Trigger-ID 
                 Assigned by the peer that is responsible for the resource 
               
               
                   
                 for which the trigger was created. The Trigger-ID is 
               
               
                   
                 returned to the peer that added the trigger in a response 
               
               
                   
                 to the InsertTrigger request. The combination of Trigger- 
               
               
                   
                 ID and Monitored-ID uniquely identifies the trigger 
               
               
                 Monitored-ID 
                 Identifier of a resource record or another trigger to which 
               
               
                   
                 this trigger is related. If the event field contains the event 
               
               
                   
                 type counter-threshold-reached, the monitored-ID field  
               
               
                   
                 can only contain a trigger-ID. 
               
               
                 Event 
                 Contains one of the event-IDs specified in Table 1. 
               
               
                 Trigger-action 
                 Contains one of the action-IDs specified in Table 2 
               
               
                 Inserting-peer-ID 
                 The identifier of the peer that created the trigger. 
               
               
                   
               
             
          
         
       
     
         [0059]    In addition to the fields listed in Table 3, an attached trigger of type counter has the additional fields specified in Table 4. 
         [0000]    
       
         
               
             
               
               
             
           
               
                 TABLE 4 
               
             
             
               
                   
               
               
                 Additional fields in a counter trigger 
               
             
          
           
               
                 Field 
                 Description 
               
               
                   
               
               
                 Counter 
                 Incremented (if the trigger-action is increment- 
               
               
                   
                 counter) or decremented (if the trigger-action is 
               
               
                   
                 decrement-counter) when the event specified in the 
               
               
                   
                 event field occurs. 
               
               
                 Counter-threshold 
                 Specifies a threshold value. Another trigger can be 
               
               
                   
                 attached to a counter trigger to monitor the threshold 
               
               
                   
                 value. 
               
               
                   
               
             
          
         
       
     
         [0060]    In addition to the fields listed in Table 3, an access-control trigger has the extra fields listed in Table 5. 
         [0000]    
       
         
               
             
               
               
             
           
               
                 TABLE 5 
               
             
             
               
                   
               
               
                 Additional fields in an access control trigger 
               
             
          
           
               
                 Field 
                 Description 
               
               
                   
               
               
                 List-type 
                 Can have two values, blacklist or whitelist 
               
               
                 List 
                 Contains blacklisted or whitelisted peer-IDs. If list- 
               
               
                   
                 type of the access control trigger is blacklist, the list 
               
               
                   
                 contains identifiers of peers that are not allowed to 
               
               
                   
                 fetch the resource record to which the trigger is 
               
               
                   
                 related. A special value “*” (implemented for 
               
               
                   
                 instance as a peer-ID in which all bits are ones), is 
               
               
                   
                 used to specify that all peers are blacklisted. If list- 
               
               
                   
                 type is whitelist, the list contains peers who have 
               
               
                   
                 the right to access the resource record. 
               
               
                 Access-restricted- 
                 Specifies why access to the resource record is 
               
               
                 reason 
                 being restricted. This field can have among others 
               
               
                   
                 the following values: (0 = busy, 1 = no-rights, 
               
               
                   
                 2 = redirect, 3 = blocked). If a peer that is trying to 
               
               
                   
                 fetch an access controlled resource record is not 
               
               
                   
                 allowed to do so, the error response that is returned 
               
               
                   
                 to the peer will contain the access-restricted-reason 
               
               
                   
                 value in a new header field which is here referred to 
               
               
                   
                 as the reject-reason field. 
               
               
                 Alternative-resource- 
                 Contains the resource-ID of an alternative resource 
               
               
                 ID 
                 record that can be fetched by the remote peer. For 
               
               
                   
                 instance, if reject-reason is redirect, the alternative- 
               
               
                   
                 resource-ID field should contain the resource-ID of 
               
               
                   
                 an alternative contact record that can be used to 
               
               
                   
                 reach the user. 
               
               
                   
               
             
          
         
       
     
         [0061]    Using DHT Triggers to Implement Presence Service 
         [0062]    In a P2P presence system, a user has to periodically poll her offline buddies in order to discover when the buddies store their contact information into the overlay (i.e., become online). Instead of polling the status of each offline buddy, the user can store standalone DHT triggers for the resource-IDs of her buddies&#39; contact records. Thanks to the trigger, the user is notified as soon a buddy joins the overlay and stores his contact record. As explained above, the user can construct the resource-ID of a buddy&#39;s contact record by calculating a hash over the buddy&#39;s SIP URI. 
         [0063]    As an example, if Alice wishes to learn when Bob, whose SIP URI is sip:bob@example.com, joins the P2P overlay, Alice will insert a trigger whose fields contain the following values into the overlay:
       Trigger-type: regular   Trigger-ID: Set by the peer that will store the trigger   Monitored-ID: hash(sip:bob@example.com)   Trigger action: notify-me   Event: created   Inserting-peer-ID: Alice&#39;s endpoint&#39;s peer-ID       
 
         [0070]    Since Bob&#39;s contact record does not exist in the overlay yet, the trigger Alice inserts will become a standalone trigger. The trigger will be stored at the peer who is currently responsible for the Monitored-ID. 
         [0071]    This can also be seen with reference to  FIG. 3 . Alice inserts the trigger (S 31 ) into the DHT. The resource-ID for Bob&#39;s contact record is determined (S 32 ) and used to determine the peer responsible for maintaining Bob&#39;s contact record (S 33 ). The trigger is stored (S 34 ) in a trigger database at that peer. When Bob becomes online (S 35 ) the trigger is retrieved from the database (S 36 ) and the action specified therein—to notify Alice that Bob is now online—is executed (S 37 ). 
         [0072]    Using DHT Triggers to Implement Access Control 
         [0073]    An attached trigger of type access-control can be used to specify which peers are allowed to access a specific resource record (whitelist) or which peers don&#39;t have the right to access the resource record (blacklist). In this case the action specified in the trigger record is validate-peer (see Table 2). If the peer that is trying to access the resource record by sending a peer protocol Lookup request does not have the right to do so, the Lookup request is rejected. 
         [0074]    As an example, if Alice wants to deny access to her contact information from a set of peers, Alice will create an access control trigger with the following contents:
       Trigger-type: access-control   Trigger-ID: Set by the peer that will store the trigger   Monitored-ID: hash(sip:alice@example.com)   Trigger action: validate-peer   Event: resource-read   Inserting-peer-ID: Alice&#39;s endpoint&#39;s peer-ID   List-type: blacklist   List: The set of Blacklisted peer-IDs   Access-restricted-reason: no-rights   Alternative-resource-ID: empty       
 
         [0085]    DHT Triggers and Counters 
         [0086]    An attached trigger of type counter can be used to associate an event counter with a resource record. A user may for instance be interested in how many times an image he has stored in the overlay has been viewed. 
         [0087]    As an example, let&#39;s assume Alice has stored an image in the overlay and wants to associate a counter with the resource record of the image. The initial value of the counter is zero and the counter should be increment each time the resource record of the image is fetched. The trigger Alice attaches to the resource record of the image is shown below:
       Trigger-type: counter   Trigger-ID: Set by the peer that will store the trigger   Monitored-ID: The resource-ID of the image   Trigger-action: increment-counter   Event: resource-read   Inserting-peer-ID: Alice&#39;s endpoint&#39;s peer-ID   Counter. 0   Counter-threshold: 10       
 
         [0096]    Alice is also interested in receiving a notification when the value of the counter reaches the value ten (as specified in the counter-threshold field above). In this case, Alice creates another trigger. This second trigger is a regular trigger specifying the trigger-action notify-me and event counter-threshold-reached. This second trigger is attached to the first trigger by setting the resource-ID field of the trigger to contain the trigger-ID of the first record. Note that a trigger that monitors the counter-threshold-reached event can never be attached to a resource record, but only to another trigger record whose type is counter. The second trigger Alice stores looks as follows:
       Trigger-type: regular   Trigger-ID: Set by the peer that will store the trigger   Monitored-ID: The trigger-ID of the first trigger   Trigger-action: notify-me   Event: counter-threshold-reached   Inserting-peer-ID: Alice&#39;s endpoint&#39;s peer-ID       
 
         [0103]    Triggers and Service Discovery 
         [0104]    Peers participating in a P2P overlay can offer services to each other. One example of a service that peers can provide to each other is a TURN (Traversal Using Relays around Network address translation) relay service. A peer offering a TURN service stores a resource record with the service-ID of the TURN service into the overlay, or adds its information into an existing record if a TURN service record already exists. If another peer is interested in a specific service (such as the TURN relay service), but no other peer is currently offering the service, the DHT triggering mechanism can be used to create a standalone trigger for the service-ID of the service. Thus, users that have inserted triggers get a notification when the service becomes available. 
         [0105]    Triggers and Telephony Supplementary Services 
         [0106]    Telephony supplementary services typically require centralized call control components and are thus difficult to implement in distributed P2P overlays. However, the DHT triggering mechanism offers a way to offer certain supplementary services in a distributed way. Below three supplementary services, barring of incoming calls, call forwarding, and completion of calls to busy subscribers are used as examples. 
         [0107]    Barring of Incoming Calls 
         [0108]    The barring of incoming calls supplementary service can be implement by using the access control mechanism described in Section 0. To block incoming calls from a subset or from all peers, a user can create an access control trigger for his contact record. 
         [0109]    As an example, to block all incoming calls, the access control trigger specific fields of a trigger record should be set as follows:
       List-type: blacklist   List: *   Access-restricted-reason: block   Alternative-resource-ID: empty       
 
         [0114]    Call Forwarding 
         [0115]    The call forwarding supplementary service can be implemented by using an access control trigger whose access control trigger specific fields have the following values:
       Type: blacklist   List: *   Access-restricted-reason: redirect   Alternative-resource-ID: the resource-ID of the contact record of the endpoint to which the call should be forwarded       
 
         [0120]    Completion of Calls to Busy Subscribers 
         [0121]    To activate the completion of calls to busy subscribers service, a user who is engaged in a call should create an access control trigger for his contact record. The access control trigger should have the following information:
       List-type: blacklist   List: *   Access-restricted-reason: busy   Alternative-resource-ID: empty       
 
         [0126]    When a caller tries to fetch the contact record of a busy user, he will receive an error response in which the reject-reason field has the value busy. Now, the caller can attach a trigger to the access control trigger of the busy user&#39;s contact record. This trigger is a regular trigger and has the following information:
       Monitored-ID: the trigger-ID of the access control trigger   Trigger-action: notify-me   Event: resource-removed   Inserting-peer-ID: the peer-ID of the caller       
 
         [0131]    Because the caller has inserted this trigger, he will receive a notification when the called user removes the access control trigger. Thus, the caller will learn when the called user is no longer busy (i.e., when the call is over). 
         [0132]    Thus it can be seen that the approach described above addresses some of the challenges faced by DHT-based P2P systems when used for person-to-person communication such as VoIP, presence, and instant messaging. In particular, due to the distributed nature of the system, the endpoints participating in the P2P overlay are responsible for providing many of the services that in client-server systems are provided by centralized servers. Two examples of services that are difficult to provide efficiently in P2P communication systems are presence and telephony supplementary services, and it will be appreciated that both are facilitated by the use of triggers. 
         [0133]    In particular, one major problem in a distributed presence service is the polling necessary to detect when offline buddies join the P2P overlay network. This can cause a significant amount of excess traffic in the network and thus degrade its performance. One benefit of the system described is that it provides a way to completely eliminate such polling traffic. 
         [0134]    Another problem with previously known P2P presence systems is that the delay between a user joining the system and his buddies detecting this can be considerable. This naturally results in poor user experience. Besides eliminating the polling traffic, the proposed DHT triggering mechanism also eliminates this delay. 
         [0135]    In addition to optimizing P2P presence, the DHT triggering mechanism can also be used to implement traditional telephony supplementary services in P2P VoIP systems. 
         [0136]    Examples of such services include call forwarding, completion of calls to busy subscribers, and call barring. The triggering mechanism also provides a way to implement an access control service for resource records in a P2P overlay network. Additionally, the DHT triggers can be used to implement an event counting service in P2P overlay networks. The mechanism can also be used to improve service discovery mechanisms in DHT-based overlay networks. 
         [0137]    It will be appreciated that variations from the above described embodiments may still fall within the scope of the invention, which is defined in the accompanying claims.