KR100670813B1 - System and method for ensuring stable performance of presence service subscription procedure - Google Patents

Abstract

The present invention relates to a system and method for ensuring stable operation of the presence service subscription procedure. More particularly, the subscription procedure when forming a loop by checking whether a resource list for a presence service subscription request from a user forms a loop. The present invention relates to a system and a method for automatically terminating a resource list server so as to operate stably.

The system for ensuring stable operation of the presence service subscription procedure disclosed in the present specification includes a loop detection unit for detecting whether a URI of a resource list for which a user of the presence service requests subscription is formed; And according to whether the detection, the subscription procedure control unit for controlling whether to continue the procedure for the subscription to achieve the object and technical problem of the present invention.

Description

System and guaranty on stably subscribing to presence service and method etc.

FIG. 1A is a diagram illustrating a network configuration and processing flow for implementing a presence information subscription and notification service for a resource list.

1B is a diagram showing the configuration of the present invention.

Figure 1c shows the flow of the method invention.

2A is a diagram illustrating an example of a configuration of a resource list.

2b to 2c show tables of various URIs required for the implementation of the present invention.

2D is a diagram showing an example of the presence information table.

FIG. 3 is a diagram illustrating document information in XML format sent to the RLIM when the ST requests the RLIM to generate detailed configuration information for the resource list URI List1 issued from the RLSS.

FIG. 4 is a diagram illustrating a resource URI table associated with a resource list URI List1 shown in FIG. 2A.

5 is a diagram showing a subscription information table generated in the RLSS.

The present invention relates to a system and method for ensuring stable operation of the presence service subscription procedure. More particularly, the subscription procedure when forming a loop by checking whether a resource list for a presence service subscription request from a user forms a loop. The present invention relates to a system and a method for automatically terminating a resource list server so as to operate stably.

Messenger services such as MSN deliver instant messages when the presence information is online based on the presence information of the buddy to be subscribed to, such as online, offline, away, busy, or eating. It is a service. That is, if a change occurs with respect to the information subscribed to the presence information of the interested user, the service is made based on the presence service that can be notified of the information about the change.

For such a presence service, a large amount of traffic is generated between the presence service subscriber and the presence server providing the information about the presence service so that the presence server can notify the presence service subscriber of the status change whenever the user's presence status changes. If the bandwidth of the communication network is insufficient, serious problems may occur. Therefore, standards for resource list joining procedures and notification methods are defined to reduce traffic generated.

The standard is draft-ietf-simple-event-list, developed by the IETF SIMPLE WG. This standard defines what the subscriber is interested in as a resource. A resource list server is defined as a server that creates a resource list and provides the presence information of each resource in the resource list.

In this case, the resources in the resource list may form a hierarchical structure including another resource list or a single resource. In this case, if the subscriber subscribes to the resource list only once, the resource list server acquires the presence information of all resources included in the resource list and informs the subscriber, thereby significantly reducing the amount of traffic between the subscriber and the resource list server. .

The draft-ietf-simple-event-list standard is based on standards such as the IETF RFC 3261 Session Initiation Protocol (SIP), a framework for IETF RFC 3265 subscription and notification, and the IETF RFC 3856 presence package. RFC 3265 of the IETF SIP WG defines the SUBSCRIBE and NOTIFY messages as a framework for subscription and notification and defines the operation and processing of each message. RFC 3856 of IETF SIMPLE WG defines a package for presence information subscription and notification.

However, since the resource list server is defined in a hierarchical structure in which other resource lists can be included as a resource constituting the resource list in relation to subscription and notification of the resource list, the resource list server creates a loop ( Check in advance that a loop is forming. If the subscription and notification processing is performed immediately without checking whether the loop is formed, the resource list server may repeatedly collect the presence information of the resources included in the resource list and may cause the server to crash.

Draft-ietf-simple-event-list, a standard for resource list subscription and notification methods, requires that a presence service subscriber station requesting subscription to a resource list should not form a loop. However, a malicious subscriber may generate a resource list forming a loop and request to join the resource list. In addition, this situation can occur accidentally on the subscriber side.

Therefore, when the subscriber requests the subscription to the resource list while the resource list has already formed a loop, if the subscriber proceeds with the subscription procedure as it is, an infinite loop occurs in the resource list server and the server goes down. Things can happen, and if you don't prepare for them, you can have serious situations that can lead to Denial of Service (DoS) attacks.

SUMMARY OF THE INVENTION The present invention has been made to address the above problems, and an object of the present invention and the technical problem to be achieved is to form a loop when a request for a subscription of a resource list is requested by a presence service subscriber. System that ensures the stable performance of the presence service subscription procedure, which automatically terminates the subscription procedure when the loop is formed to ensure that the resource list server operates stably (which ensures the stability of the subscription procedure). In providing a method.

In order to achieve the above object and technical problem, a system that ensures stable performance of the presence service subscription procedure disclosed in the present specification may determine whether a URI of a resource list for which a user of the presence service requests subscription is formed. A loop detector for detecting; And according to whether the detection, the subscription procedure control unit for controlling whether to continue the procedure for the subscription to achieve the object and technical problem of the present invention.

In addition, in order to achieve the above object and technical problem, the loop formation detection method disclosed in the present specification (a) detects whether the URI of the resource list that the user of the presence service forms a loop forming a loop; step; And (b) controlling whether or not to continue the procedure for subscribing according to the detection, to achieve the object and technical problem of the present invention.

The technical idea provided by the present invention is to determine whether a resource list requested for subscription is formed through a subscription information table for a resource list when a new subscriber or an existing subscriber of a presence service requests a new subscription or a change subscription to a resource list, respectively. By doing so, the subscription process can be handled reliably.

Hereinafter, in order to clarify the technical spirit of the present invention, the configuration and operation thereof will be described in detail with reference to the accompanying drawings based on the embodiments of the present invention. Although the same reference numerals have been given even in different drawings, it will be appreciated that components of other drawings may be cited when necessary in describing the drawings.

FIG. 1A is a diagram showing a network configuration and a processing flow thereof for implementing a presence information subscription and notification service for a resource list, FIG. 1B is a diagram showing a configuration of the present invention, and FIG. 1C is a diagram of the present invention. This is a flow diagram.

First, the functions of each component of the network shown in FIG. 1A will be described.

The resource terminal 10 (hereinafter, referred to as 'RT') receives its own resource URI (Uniform Resource Identifier), which is an identifier for uniquely recognizing itself from the resource list server 12, and receives its own presence information. The resource list server 12 is registered.

Subscriber terminal 11 (hereinafter referred to as 'ST') requests a resource list server 12 for a subscriber URI, which is an identifier for uniquely recognizing itself, and a resource list URI for collecting resource lists of interest to the subscriber terminal 11. Presence information on the resource list is issued by requesting the resource list information manager 13 to create and delete configuration information of detailed resources in the resource list URI, and joining the generated resource list in the resource list server 12. Acquire.

Here, both the ST 11 and the RT 10 are identical in terms of 'users' in a communication network, but both are distinguished and used in terms of 'separate users'. This also means that the ST 11 may be an RT 10 in some cases.

The Resource List Server System 12 (hereinafter, referred to as 'RLSS') issues URIs for resources and resource lists, receives and stores the presence information for each resource from the RT 10, and stores them from the ST 11. In response to the presence service subscription request for the resource list, the presence status information of all the resources belonging to the resource list is collected and notified to the subscriber ST, and any change in any of the resources belonging to the resource list is notified to the subscriber.

The Resource List Information Manager 13 (hereinafter, referred to as 'RLIM') receives and processes a request for generating and deleting resource list detailed configuration information from the ST 11, stores it, and stores the detailed configuration information from the RLSS 12 or the like. A logical system that provides that information for a search request, which may exist as an internal module of the RLSS 12.

The processing procedure for the presence information subscription and notification for the resource list between each component of FIG. 1 is as follows.

S1: The RT 10 receives a resource URI, which is an identifier that can uniquely identify itself, from the RLSS 12.

S2: The RT 10 registers its presence information in the RLSS 12 using the issued resource URI.

S3: The ST 11 requests and issues a resource list URI to the RLSS 12 for collecting a list of resources of interest to him.

S4: The ST 11 requests the RLIM 13 to generate detailed configuration information regarding the resource list URI issued from the RLSS 12, and the RLIM 13 authenticates and authorizes the ST 11 with respect to the resource list URI. After doing this, inform the result. Here, the request for generation / modification / retrieval of the resource list URI detailed configuration information and the response between the ST 11 and the RLIM 13 may be performed through the web, orally, or in any other way, depending on the usage method. Authentication and authorization also follow the manner set forth in the RLIM 13.

S5: The ST 11 makes a presence service subscription request to the RLSS 12 via the SUBSCRIBE message, targeting the resource list URI issued from the RLSS 12.

S6: The RLSS 12 performs a subscription authentication and authorization procedure for the ST 11. According to the result of the authentication and authorization procedure, the RLSS 12 informs the ST 11 whether to allow the subscription through the grant response or the disallow response to the SUBSCRUBE message. At this time, the authentication and authorization procedure for the ST 11 of the RLSS 12 follows the method defined in the draft-ietf-simple-event-list standard.

S7: When authentication and authorization are performed by the S6 process, the RLSS 12 requests the RLIM 13 to search for detailed information on the resource list URI requested by the ST 11 to obtain information on the detailed configuration. .

S8: The RLSS 12 performs a procedure of acquiring the presence information for each resource based on the detailed configuration information of the resource list URI obtained from the RLIM 13. At this time, the loop detection unit 121 of the RLSS 12 checks whether the resource list URI requested from the ST 11 forms a loop (P1).

The process of checking whether the resource list URI requested to join from the ST 11 forms a loop may include obtaining current presence information of all resources belonging to the resource list URI (S8) and any one of all resources belonging to the resource list URI. It is made at the time of updating the subscription information table to notify the ST 11 when a change occurs.

The RLSS 12 in the present invention, as mentioned above, generates a subscription information table for resources constituting the resource list requested from the ST 11, which includes a subscriber URI and a resource URI (resource). In addition to the list URI, the resource list information (ancestor URI) of the ancestor resource lists to which the resource URI (resource list URI) belongs.

At this time, when the resource list URI requested to join is included in the resource list URI of its ancestors, the resource list URI requested to join is treated as forming a loop.

S9: When the loop detection unit 121 detects a loop, the RLSS 12 indicates to the ST 11 that the subscription to the resource list URI is terminated due to the loop (subscription is not allowed), and the Subscription-State header of the NOTIFY message. Immediately notify by specifying terminated, the subscription procedure control unit 122 of the RLSS 12 stops the subscription-related procedure (P2). If the loop detection unit 121 does not detect the loop, the presence information obtained when notifying the resource list URI subscription to the ST 11 is included in the body of the NOTIFY message, and the subscription procedure control unit 122 is transmitted. ) Will proceed with the subscription-related procedures normally (P3).

Preferred embodiments for clarifying the technical spirit of the present invention in more detail.

For example, when the subscriber X requests the RLSS 12 to join the resource list with List1 which is a part of the resource list URIs issued from the RLSS 12 (S5), the operation of the RLSS 12 will be described. At this time, all URIs are designated with "rlss-domain-name" which designates the RLSS domain after "@" to enable routing to the RLSS 12, and the information in the RLSS 12 through the information before "@". Make sure to distinguish between users. Here, "rlss-domain-name" becomes a domain name corresponding to the IP address where the RLSS 12 exists (hereinafter, "@ rlss-domain-name" is omitted in all URIs for convenience).

2A is a diagram illustrating an example of configuration of a List1 resource list.

List1 consists of List2 and List3, which are other resource lists below. List2 consists of a single resource Rsc1 and Rsc2, and List3 consists of a single resource Rsc1 and another resource list List2 and List4. Here, Rsc1 is identical to Rsc1 belonging to List2, and List2 is identical to List2 belonging to List1. List4 consists of a single resource Rsc3 and another resource list List3. Here, List3 is the same as List3 belonging to List1.

FIG. 2B illustrates a URI table that designates all URIs issued by the RLSS 12 including both a resource URI and a resource list URI in relation to the resource list URI List1 shown in FIG. 2A. List2, List3, List4, Rsc1, Rsc2, Rsc3 are specified.

FIG. 2C shows a table specifying URIs of resource lists issued by the RLSS 12 in relation to the resource list URI List1 shown in FIG. 2A. The resource list URI table contains a list of all resource list URIs issued by the RLSS 12. In this embodiment, List1, List2, List3, List4 are specified as resource list URIs.

FIG. 2D illustrates an example of a presence information table that stores presence information for each resource URI issued by the RLSS in relation to the resource list URI List1 shown in FIG. 2A.

The RLSS 12 receives and stores registered presence information from the RT 10 having received the resource URI. Presence information registered from the RT (10) can be expressed in various forms, such as communication information such as status information, such as online, offline, away, busy, meal, and telephone number, e-mail address, messenger address.

FIG. 3 illustrates an XML (eXtension Markup Language) format to be sent to the RLIM when the ST requests the RLIM to generate detailed configuration information for the resource list URI List1 issued from the RLSS with respect to the resource list URI List1 shown in FIG. 2A. It is a figure which shows document information. The RLIM 13 notifies the ST 11 of the result of the information generation request after undergoing the authentication and authorization process for the ST 11.

At this time, the resource list URI generated / issued by the request of the ST 11 must be unique on the system managed by the RLIM 13, and the RLIM 13 must ensure that the URI is issued from the RLSS 12. The above condition must satisfy not only the resource list URI from which the ST 11 is requested, but also other resource list URIs.

When the ST 11 is notified of the result of the detailed configuration information generation request for the resource list URI List1 from the RLIM 13, it makes a presence service subscription request to the RLSS 12 for the resource list URI List1. After performing the authentication and authorization procedure for the ST 11, the RLSS 12 informs the ST 11 whether to allow the subscription of the resource list URI List1 requested to join, and at this time, the resource requested by the loop detector 121 to join. It is determined whether a loop of the list URI List1 is formed.

If authentication and authorization have been made, the RLSS 12 requests the RLIM 13 to retrieve detailed information about the resource list URI List1 requested by the ST 11 to join. The RLIM 13 informs the RLSS 12 of this request in detail in the form of the document presented in FIG. 3 by the ST 11. The RLSS 12 parses the document (detailed information) of FIG. 3 obtained from the RLIM 13 to generate a resource URI table as shown in FIG. In the resource URI table, a resource list URI and a resource URI immediately below are designated.

FIG. 4 is a diagram illustrating a resource URI table associated with a resource list URI List1 shown in FIG. 2A.

Referring to FIG. 4, List1 has List2 and List3 as lower resources. List2 has Rsc1 and Rsc2 as subordinate resources, List3 has Rsc1, List2 and List4 as subordinate resources, and List4 has Rsc3 and List3 as subordinate resources.

The RLSS 12 generates the subscription information table shown in FIG. 5 with reference to the resource URI table shown in FIG. The subscription information table is necessary for the RLSS 12 to obtain the current presence information of the resources subscribed to the subscriber or all resources in the resource list and notify the subscriber or to notify the ST 11 when a change occurs in any one of the future resources. will be.

Referring to FIG. 5, an ancestor URI of a subscriber URI, a resource URI (resource list URI), and a resource URI (resource list URI) is specified in the subscription information table. In particular, in the present invention, it is unusual that an ancestor URI is specified, which has the purpose of detecting whether a resource subscribed to is a resource list URI and this resource list URI creates a loop.

If the ancestor URI list of the resource URI is Null in the subscription information table, there is a real subscription from the subscriber to the resource. If the ancestor of the resource is not null, the subscription from the subscriber to the resource is a virtual implicit from the ancestor of the resource. This signifies subscription status.

The criterion for determining whether a resource list URI requested by a subscriber forms a loop is when a resource URI (resource list URI) for the same subscriber URI is included in its ancestor URI. At this time, if the same resource URI is generated for the same subscriber URI, but the ancestor URI of the resource URI is different, this is not a problem. This is because the same resource is included in the detailed configuration of the resource list URI, but the RLSS 12 This is because it does not have a fatal effect on the subscription process.

5 is a diagram showing a subscription information table generated in the RLSS.

Here, it can be seen that resource URIs are duplicated through different routes in case of List2, List3, and Rsc1. However, it can be seen that List3, which is the last resource URI, generates a loop because its ancestor URI is List4, List3, List1, and the resource URI is included in the ancestor URI. In the case where there are a plurality of ancestor URIs, the ranks of the ancestor URIs are higher in order to the right.

Subscriber X subscribes to the resource list URI List1. At this time, since the ancestor URI of the resource URI List1 is Null, it means that the actual resource list URI List1 is subscribed to.

Subscriber X subscribes to the resource list URI List2. At this time, since the ancestor URI of the resource list URI List2 is List1, the subscriber X implies that List2 is nested in the resource list URI List1 and is virtually subscribed.

Subscriber X subscribes to the resource list URI List3. At this time, since the ancestor URI of the resource list URI List3 is List1, the subscriber X implies that List3 is nested in the resource list URI List1 and is virtually subscribed.

Subscriber X subscribes to resource URI Rsc1. At this time, since the ancestor URIs of the resource URI Rsc1 are List2 and List1, the subscriber X implies that List2 is implied in the resource list URI List1 and Rsc1 is implied in List2 to virtually subscribe.

Subscriber X subscribes to resource URI Rsc2. At this time, since the ancestor URIs of the resource URI Rsc2 are List2 and List1, the subscriber X implies that List2 is contained in the resource list URI List1 and Rsc2 is nested in the List2 to virtually subscribe.

Subscriber X subscribes to the resource list URI List2. At this time, since the ancestor URIs of the resource list URI List2 are List3 and List1, the subscriber X implies that List3 is nested in the resource list URI List1 and List2 is nested in the List3 to virtually subscribe.

Subscriber X subscribes to resource URI Rsc1. At this time, since the ancestor URIs of the resource URI Rsc1 are List3 and List1, the subscriber X implies that List3 is implied in the resource list URI List1 and Rsc1 is implied in List3 to virtually subscribe.

Subscriber X subscribes to the resource list URI List4. At this time, since the ancestor URIs of the resource list URIs are List3 and List1, subscriber X means that List3 is nested in the resource list URI List1 and List4 is nested in the List3 to virtually subscribe.

Subscriber X subscribes to resource URI Rsc3. At this time, since the ancestor URIs of the resource URI Rsc3 are List4, List3, List1, the subscriber X implies that List3 is nested in List1, List4 is nested in List3, and Rsc3 is nested in List4, thereby making a virtual subscription.

Subscriber X subscribes to the resource list URI List3. At this time, since the ancestor URIs of the resource list URI List3 are List4, List3, List1, the subscriber X implies that List3 is nested within List1, List4 is nested within List3, and List3 is nested within List4, thereby making a virtual subscription. This case is a case where a resource list URI requested by a subscriber is included in the ancestor URI of a resource URI (resource list URI) for the same subscriber URI, thus forming a loop.

If the loop is found, the RLSS 12 immediately informs the ST 11 that the subscription to the resource list URI is terminated due to the loop, and the subscription procedure controller 122 stops the subscription procedure. When no loop is generated, the ST 11 is informed of the subscriber, including the presence information of detailed configuration information, for the subscription to the resource list URI List1.

The present invention can also be embodied as computer readable code on a computer readable recording medium. The computer-readable recording medium includes all kinds of recording devices in which data that can be read by a computer system is stored.

Examples of computer-readable recording media include ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage, and the like, and may also be implemented in the form of a carrier wave (for example, transmission over the Internet). Include. The computer readable recording medium can also be distributed over network coupled computer systems so that the computer readable code is stored and executed in a distributed fashion.

So far I looked at the center of the preferred embodiment for the present invention. Those skilled in the art will appreciate that the present invention can be implemented in a modified form without departing from the essential features of the present invention.

Therefore, the disclosed embodiments should be considered in descriptive sense only and not for purposes of limitation. The scope of the present invention is shown in the claims rather than the foregoing description, and all differences within the equivalent scope will be construed as being included in the present invention.

As described above, in the present invention, when a presence service subscriber requests to join a resource list, a resource is included in a subscription information table in a process of generating a subscription information table for notifying a change state of presence information such as a resource belonging to the requested resource list. By maintaining the ancestor URI information for, check whether the resource list creates a loop, and if the loop is created, the resource list server can be stably operated by stopping the registration procedure immediately.

Claims (7)

A loop detector to determine whether a resource list requested by a user of the presence service forms a loop; And In accordance with the detection or not, including a subscription procedure control unit for controlling whether to continue the procedure for joining, if the requested resource list forms a loop, characterized in that the progress of the subscription procedure to stop A system that ensures stable performance of the presence service subscription process. The method of claim 1, wherein the loop detector The system assures stable performance of the presence service subscription procedure, wherein it is determined whether the loop is formed by referring to subscription information of resources constituting the resource list. The method of claim 2, wherein the subscription information And a URI of an ancestor resource list to which the subscriber URI (Uniform Resource Identifier) of the user, the URI of the resources, and the URI of the resources belong. The method of claim 3, wherein the loop detector And if the URI of the requested resource list is included in the ancestor resource list URI, determine that the loop is formed. (a) detecting whether a resource list requested by the user of the presence service forms a loop; And (b) controlling whether to continue the procedure for subscribing according to the detection, and if the URI of the requested list forms a loop, stopping the process of subscribing. To ensure the stable performance of the Presence Services subscription process. The method of claim 5, wherein step (a) It is made by referring to subscription information of resources constituting the resource list, wherein the subscription information includes a subscriber URI of the user, a URI of the resources, and a URI of an ancestor resource list to which the URIs of the resources belong. How to ensure the stable performance of the presence service subscription process. The method of claim 6, wherein step (a) And determining that the loop is detected when the URI of the requested resource list is included in the ancestor resource list URI.

Images