WO2013053252A1

WO2013053252A1 - Method and apparatus for processing network overload

Info

Publication number: WO2013053252A1
Application number: PCT/CN2012/078513
Authority: WO
Inventors: 陈志峰
Original assignee: 中兴通讯股份有限公司
Priority date: 2011-10-10
Filing date: 2012-07-11
Publication date: 2013-04-18
Also published as: CN103036928A

Abstract

Disclosed are a method and an apparatus for processing network overload. The method comprises: receiving, by a responsible node, a request message sent from a terminal or a node; determining that the request message cannot be processed; instructing a standby node to process the request message. In the embodiments of the invention, the node of the network which is busy can forward, the request messages needed to be processed, to other nodes having processing abilities, thus reducing the session loss, and utilizing the characteristic and processing ability of the Peer-to-Peer(P2P) overlay network more adequately.

Description

The present invention relates to the field of communications, and in particular to a method and apparatus for processing network overload. BACKGROUND Peer-to-Peer (P2P) technology allows users to directly connect to other users' computers for file sharing and exchange, and P2P is also useful for deep search, distributed computing, and collaborative work. . At present, P2P has fully demonstrated its strong technical advantages in enhancing communication, file exchange, distributed computing, and service sharing on the network. However, P2P applications are mainly concentrated in Internet applications, but not in traditional telecommunication networks. Large-scale application. Considering the current and future telecom networks, the mainstream of session control is the Session Initiation Protocol (SIP) protocol. Therefore, the introduction of P2P technology into the telecommunication network must ensure the application of the SIP protocol in the P2P network. At the same time, it needs to be able to run all kinds of typical business. Based on the above considerations, many organizations in the industry are working on how to introduce P2P technology into the telecommunication network. Figure 1 is a schematic diagram of a P2P overlay network architecture according to the related art. As shown in Figure 1, the P2P overlay network 11 and P2P are included. The node 12, the non-P2P terminal device 13, the P2P terminal device 14, and the access node 15 in the overlay network 11 are described in detail below.

The P2P overlay network 11 is a logical network composed of various types of peers (also referred to as nodes in the present invention) that are responsible for different tasks. The node 12 in the P2P overlay network 11 is the basic component of the P2P overlay network 11, and is capable of giving the same

Other nodes in the P2P overlay network provide nodes for storing and transmitting services. The non-P2P terminal device 13 accesses the P2P overlay network, but does not support any P2P protocol, and only supports the SIP protocol.

The P2P terminal device 14 is connected to the P2P overlay network, and supports both the P2P protocol and the SIP protocol. Considering that the general terminal device, especially the handheld terminal device, has weak capabilities, in many cases, the P2P terminal is actually deployed. The device is only used as a P2P client to access the P2P overlay network, and is not used as a server for storage and transmission. The access node 15 is an access node of a terminal device such as a non-P2P terminal device 13, a P2P terminal device 14, etc., and in consideration of the needs of telecommunication operations, both the P2P terminal and the non-P2P terminal must access the P2P overlay through the nearest access node. In the network, when the access node acts as an access node of a non-P2P terminal, and simultaneously acts as a proxy node, it is responsible for completing the conversion of the protocol adopted by the non-P2P terminal and the protocol used by the P2P overlay network internal routing SIP, and when the node When acting as an access node of a P2P terminal, only the message needs to be relayed. In the P2P overlay network, each node can store data and process data. Since each node stores different processed data, the load level at the same time is also different. Of course, some good load balancing algorithms are in specific conditions. Under the normal low load condition, the load degree between different nodes in the same overlay network is basically the same. Once the load is high, the algorithm will automatically adjust, and the adjustment is inevitable. The occurrence calculation and data migration operation further add overlapping screening load, so the application of the load balancing algorithm of the general P2P overlay network also has certain limitations. 2 is a flowchart of processing a node overload in a P2P overlay network according to the related art. In a SIP application of a P2P overlay network, a general processing flow when a single node is overloaded is shown in FIG. 2, and the process specifically includes step S202 to Step S210. Step S202: The terminal sends a SIP request message to the P2P overlay network, and the SIP message is forwarded by the transit node. Step S204, the transit node finds the responsible node of the SIP request, and forwards the SIP message to the responsible node. Step S206, the responsible node has a high current load level and cannot process a new SIP request, and then rejects the processing of the current message. Step S208, the responsible node returns a 3xx, 486 or 5xx message according to the current configuration, and rejects the current call. Step S210: The transit node forwards the response message to the terminal, indicating that the current request processing fails, and the terminal further performs processing according to the response message returned by the overlay network. At present, the IETF is also studying the overload of SIP servers, and the result is called SOC (SIP Load Control). FIG. 3 is a flowchart of a process for overloading a node in another P2P overlay network according to the related art. If a node in the P2P overlay network supports the SOC, the process specifically includes steps S302 to S314. Step S302, the terminal sends a SIP request message to the P2P overlay network, and the SIP message is forwarded by the transit node. Step S304, the transit node supports the SOC, and when the SIP message is forwarded, the support SOC header field is added to the SIP message, and the supported SOC algorithm is carried. Step S306, after receiving the message, the node is found to be in an overload state, replying to the SIP response message, adding a responsible node busy indication in the response message, and indicating an algorithm used after the overload, and an expiration date of the overload processing. Step S308, the transit node forwards the response message. Step S310, when the subsequent message arrives at the transit node, the transit node finds that the responsible node of the message is still at the overload node. In step S312, the transit node discards or forwards the message according to the previously negotiated overload algorithm. The overload algorithm is not part of the discussion of the present invention and will not be described in detail herein. Step S314, if the transit node selects the forwarding request in step S306, the subsequent response request will also be forwarded by the transit node. The above solution is to apply the overload method to the P2P network in the client/server model (C/S) network architecture. However, the P2P network and the C/S architecture are obviously different: P2P network When a single node is overloaded, it does not mean that the entire P2P network is overloaded. There are other nodes and even most of the nodes have processing power. Therefore, these processing methods will cause session loss and low processing capability. SUMMARY OF THE INVENTION The present invention provides a method and apparatus for processing an overload in a network, which can be used to solve the problem that a network overload processing method in the related art causes session loss and low processing capability. According to an aspect of the present invention, a method for processing a network overload is provided, including: receiving, by a node, a request message from a terminal or a node; determining that the request message cannot be processed; and instructing the standby node to process the request message. Preferably, the responsible node receiving the request message from the terminal or the node comprises: the responsible node receiving the request message sent by the terminal or the node and forwarding via the transit node. Preferably, indicating that the standby node processes the request message includes: adding an identifier in the request message, where the identifier is used to indicate a standby node processing request message, where the identifier includes one of the following: a busy identifier for indicating that the responsible node is busy, used for A temporary resource or host identifier indicating that the standby node temporarily processes the request message; forwarding the request message after adding the identifier to the standby node. Preferably, after indicating the standby node processing the request message, the method further includes: the responsible node receiving the request response from the standby node; and forwarding the request response to the terminal or the node. Preferably, after indicating the standby node processing the request message, the method further includes: the standby node determines that the request message cannot be processed; and the standby node instructs the next standby node to process the request message. Preferably, after the standby node indicates the next standby node processing the request message, the method further includes: the standby node receiving the request response from the next standby node; and the standby node forwarding the request response to the terminal or the node by the responsible node. Preferably, after forwarding the request response to the terminal or the node, the method further includes: when the request response includes the forced routing information, for the INVITE request message in the subsequent session to be sent, the terminal or the node directly sends the standby message to the standby node. node. Preferably, after forwarding the request response to the terminal or the node, the method further includes: when the standby node maintains the user registration relationship, for the subsequent REGISTER request message to be sent, the terminal or the node is directly sent to the standby node across the responsible node. Preferably, after indicating the standby node processing the request message, the method further includes: the standby node processing the request message. Preferably, after indicating the standby node processing the request message, the method further includes: performing, between the responsible node and the standby node, a data update corresponding to the request message. Preferably, after indicating the standby node processing the request message, the method further includes: the responsible node determining the recovery processing capability; and performing, between the responsible node and the standby node, the data update corresponding to the request message. According to another aspect of the present invention, a network overload processing apparatus is provided, comprising: a receiving module configured to receive a request message from a terminal or a node; a determining module configured to determine that the request message cannot be processed; and an indication module configured to Instruct the alternate node to process the request message. The invention solves the problem that the processing capability of the P2P overlay network cannot be fully utilized in the telecommunication network in the related art by using the scheme that the standby node processes the new request when the responsible node is busy, thereby achieving the problem in the telecommunication network. Make full use of the processing power of the P2P overlay network. BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are set to illustrate,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, In the drawings: FIG. 1 is a schematic diagram of a P2P overlay network architecture according to the related art; 2 is a flowchart of processing of node overload in a P2P overlay network according to the related art; FIG. 3 is a flowchart of processing of node overload in another P2P overlay network according to the related art; FIG. 4 is a network overload according to an embodiment of the present invention. FIG. 5 is a flowchart of general message processing according to an embodiment of the present invention; FIG. 6 is a flow chart of INVITE and subsequent message processing according to an embodiment of the present invention; FIG. 7 is a REGISTER according to an embodiment of the present invention; FIG. 8 is a flowchart of another REGISTER and subsequent message processing according to an embodiment of the present invention; FIG. 9 is a flowchart of processing for actively synchronizing data of a node according to an embodiment of the present invention; FIG. 11 is a structural block diagram of a processing device for network overload according to an embodiment of the present invention. BEST MODE FOR CARRYING OUT THE INVENTION Hereinafter, the present invention will be described in detail with reference to the accompanying drawings. It should be noted that, in the case where no conflict occurs, the features in the embodiments and the embodiments in the present application can be combined with each other. FIG. 4 is a flowchart of a method for processing network overload according to an embodiment of the present invention. As shown in FIG. 4, the following steps S402 to S406 are included. Step S402, the responsible node receives the request message from the terminal or the node. Step S404, determining that the request message cannot be processed. Step S406, instructing the standby node to process the request message. In the related art, the network overload processing method causes session loss and low processing capability. In the embodiment of the present invention, the busy node in the network can forward the request message to be processed to other nodes with processing capability, thereby reducing session loss and making full use of the characteristics and processing capability of the P2P overlay network. Preferably, the responsible node receiving the request message from the terminal or the node comprises: the responsible node receiving the request message sent by the terminal or the node and forwarding via the transit node. The transmission of the message in this embodiment is transited through the transit node, so that the request message can be stably and reliably transmitted. Preferably, indicating that the standby node processes the request message includes: adding an identifier in the request message, where the identifier is used to indicate a standby node processing request message, where the identifier includes one of the following: a busy identifier for indicating that the responsible node is busy, used for A temporary resource or host identifier indicating that the standby node temporarily processes the request message; forwarding the request message after adding the identifier to the standby node. In this embodiment, the added identifier enables the standby node to process the new request when the responsible node is busy, thereby improving the utilization of the P2P network. Preferably, after indicating the standby node processing the request message, the method further includes: the responsible node receiving the request response from the standby node; and forwarding the request response to the terminal or the node. In this embodiment, the responsible node can obtain the request response after the standby node processes the request and forwards it to the sender of the request message, and completes the whole process of processing the request signal. Preferably, after indicating the standby node processing the request message, the method further includes: the standby node determines that the request message cannot be processed; and the standby node instructs the next standby node to process the request message. Considering that both the standby node and the responsible node are busy, in this embodiment, the next standby node performs processing, thereby avoiding the request failure. Preferably, after the standby node indicates the next standby node processing the request message, the method further includes: the standby node receiving the request response from the next standby node; and the standby node forwarding the request response to the terminal or the node by the responsible node. Through this step, the embodiment achieves the effect that the network can also process new requests in time when both the responsible node and the standby node are busy. It should be noted that the selection of the standby node and the next standby node may be a node calculated according to the P2P algorithm and the current status of the P2P overlay network, or may be a pre-configured node, or may be randomly selected in the routing table of the active node. Selected node. Preferably, after forwarding the request response to the terminal or the node, the method further includes: when the request response includes the forced routing information, for the INVITE request message in the subsequent session to be sent, the terminal or the node directly sends the standby message to the standby node. node. Considering that each time the responsible node itself judges whether to process a new request to reduce the efficiency of network operation, when the responsible node is busy, the terminal or node can find the actual processing of the request by adding mandatory routing information in the request information. node. Preferably, after forwarding the request response to the terminal or the node, the method further includes: when the standby node maintains the user registration relationship, for the subsequent REGISTER request message to be sent, the terminal or the node is directly sent to the standby node across the responsible node. Specifically, the terminal or the node sends the subsequent REGISTER request message to the standby node directly to the standby node, which can be implemented in multiple manners, for example, by adding a mandatory routing information header to the subsequent REGISTER request message to be sent. area. It should be noted that other implementations in the prior art that can achieve the same cross-transmission are all included in the protection scope of the present invention. In addition, in the case that the responsible node maintains the user registration relationship, the subsequent request message sent by the terminal or the node is not added. The routing information header field is enhanced. The responsible node determines whether the message is processed by the local node according to the current load condition after receiving the request message. If processed by the local node, the processing flow is the same as the normal message processing flow. If the node cannot process, the handover needs to be handed over. Other node processing. In this embodiment, by managing the user registration relationship between the responsible node and the standby node, the operation of the entire network is maintained more efficiently. Preferably, after indicating the standby node processing the request message, the method further includes: the standby node processing the request message. Preferably, after the requesting the standby node to process the request message, the method further includes: performing, between the responsible node and the standby node, a data update corresponding to the request message. Considering that data synchronization will affect the processing capability of subsequent messages, each time the message is processed in this embodiment, the relevant node will update the data to ensure consistency. Preferably, after indicating the standby node processing the request message, the method further includes: the responsible node determining the recovery processing capability; and performing, between the responsible node and the standby node, the data update corresponding to the request message. In this embodiment, the responsible node can actively synchronize data with the standby node when not busy, thereby ensuring the accuracy of its own data. In this embodiment, a method for processing an overload of a SIP application in a P2P network is implemented. The method is that when the responsible node that should process the message is overloaded and cannot process a new request, the responsible node adds the identifier to the message and forwards the request. For the selected standby node, the identifier added by the responsible node means that the responsible node is busy and cannot continue processing the message; after the standby node receives the message, although the node is not responsible for the node, after detecting the identifier in the message, The message will be processed. Preferably, in order to enable the forwarding message to be successfully routed to the standby node, the destination in the forwarding message needs to be replaced with the relevant identifier of the standby node. In the P2P overlay network, the related identifier may be the identifier of the standby node itself, or may be The standby node is responsible for the identification of resources within the interval. Preferably, after processing the message, the standby node may initiate an overlay network data modification operation if the overlay network data needs to be modified; or when the responsible node is no longer overloaded, the responsible node actively retrieves the modified data and performs the overlay. Network data modification. Preferably, if the current standby node is also busy, the new request may be forwarded to the next standby node for processing, and the process forwards the message to the standby node, and adds the overload identifier of the standby node or replaces the original overload identifier, and the next standby node receives After the message is found, the responsible node is overloaded with the previous standby node, and the message is processed. If the message processed by the method establishes a conversation or registration relationship, the session or registration data may exist on the current processing node, and subsequent messages are handed over to the processing node; otherwise, the conversation or registration If the data does not exist on the current node, the subsequent message will be handed over to the responsible node, and will only be handed over to the standby node when the responsible node is still overloaded. Preferably, when the subsequent message is still processed by the current processing node, a header field needs to be added in the response message for description, otherwise the subsequent message is processed by the responsible node. After the method in this embodiment is used, when a node in the P2P overlay network is overloaded, the new request message that the overload node should process may be forwarded to the other node for processing, thereby ensuring the processing of the new request message. The implementation process of the embodiment of the present invention will be described in detail below in conjunction with the preferred embodiments. Preferred Embodiment 1 FIG. 5 is a flowchart of a general message processing according to an embodiment of the present invention, and the specific process includes steps S502 to S520. Step S502: The terminal or the node sends a SIP request message to the P2P overlay network, and the SIP message is forwarded by the transit node. Step S504, the transit node forwards the message to the responsible node. Step S506, since the responsible node is busy at this time, the new SIP request message cannot be processed. Step S508, the responsible node forwards the request message to the standby node for processing, adds an identifier to the forwarded request message, marks that the primary node is busy, and is handed over to the standby node for processing, and the identifier may be adding the responsible node to the busy identifier in the message, or Is to generate a temporary resource or host ID, inserted into the message. Step S510: After receiving the request message, the standby node searches for the identifier added by the responsible node in the message, so the data required for processing the request is obtained, and the request processing is performed. Step S512, after the standby node completes the request processing, returns a response message. Step S514, the response message arrives at the transit node after being forwarded by the responsible node. Step S516, the transit node sends a response message to the terminal or node that sends the request message. Step S518, when the processing of the standby node causes modification of the data in the overlay network, the standby node initiates a data update request message to the responsible node of the data, and performs data modification, where the responsible node of the data may be the responsible node of the request or not, For the convenience of the figure, the two nodes are combined into the same node. Step S520, after the responsible node of the data completes the data update request message, returns a data update response message, and completes the processing of the message when the node is overloaded. The above figure is the processing of the ordinary request response message. For special SIP messages, for example, the INVITE message will generate a dialogue, and the REGISTER message will generate a registration dialog. If these messages are processed on the standby node, the subsequent messages in the conversation may be affected. Process flow. Preferred Embodiment 2 FIG. 6 is a flowchart of an INVITE message and a subsequent message processing according to an embodiment of the present invention. The specific process includes steps S602 to S630. Step S602, the terminal or the node sends an INVITE request message to the transit node. Step S604, the transit node forwards the request message to the responsible node of the message. Step S606, because the responsible node of the message is busy and cannot process the new INVITE request, the responsible node forwards the INVITE request message to the standby node, and adds the master node busy identifier in the message. Step S608: After the standby node completes the request processing, the subsequent message that determines the call corresponding to the INVITE is processed by the standby node. When the SIP response message is returned, the message carries the mandatory routing information that the subsequent message is processed by the standby node. In step S610, the message is forwarded to the transit node. Step S612, the transit node forwards the response message to the terminal or the node. Step S614, the subsequent request message sent by the terminal or the node carries the signature routing message header field. Step S616, the message is forwarded to the standby node after being forwarded by the transit node. Step S618, after receiving the request message and processing the message, the standby node returns a response message. Step S620: The response message is forwarded by the transit node and sent to the originating terminal or node. Step S622: The message is not added to the mandatory routing information header field for the non-intra-session request message sent by the terminal or the node. Step S624, the non-intra-session request message is forwarded to the responsible node by the transit node. Step S626, the responsible node determines whether the message is processed by the local node according to the current load condition. If processed by the local node, the processing flow is the same as the normal message processing flow. If the local node cannot process and needs to be handed over to other nodes for processing, the processing flow is the same as the figure. 5 is shown. Step S628, after the processing is completed, a response message is returned. Step S630, the response message is forwarded to the terminal or node through the transit node. Preferred Embodiment 3 FIG. 7 is a flowchart of REGISTER and subsequent message processing according to an embodiment of the present invention, and the specific process includes steps S702 to S720. Step S702, the terminal or the node sends a REGISTER request message to the transit node. Step S704, the transit node forwards the request message to the responsible node of the message. Step S706, the responsible node of the message is busy, unable to process the new REGISTER request, so the message is forwarded to the standby node, and the primary node is busy identifier added in the message. Step S708, after the standby node completes the request processing, the subsequent message that determines the call corresponding to the REGISTER is processed by the standby node. When the SIP response message is returned, the subsequent message carrying the registered user in the message has the mandatory processing by the standby node. Routing information. In step S710, the message is forwarded to the transit node. Step S712, the transit node forwards the response message to the terminal or the node. Step S714, the subsequent request message sent by the terminal or the node, where the message carries the signature routing message header field. Step S716, the message is forwarded to the standby node by the transit node. Step S718: After receiving the request message and processing the message, the standby node returns a response message. Step S720, the response message is forwarded to the originating terminal or node through the transit node. In the above embodiment, the registration relationship of the user is maintained by the standby node in the above figure, and the registration relationship of the user is maintained by the responsible node, and the process is as shown in FIG. 8. FIG. 8 is a flow chart of another REGISTER and subsequent message processing procedure according to an embodiment of the present invention, which is specifically performed in steps S802 to S822. Step S802, the terminal or the node sends a REGISTER request message to the transit node. Step S804, the transit node forwards the request message to the responsible node of the message. Step S806, the responsible node of the message is busy, unable to process the new REGISTER request, so the message is forwarded to the standby node, and the primary node is busy identified in the message. Step S808: After the standby node completes the request processing, the subsequent message that determines the call corresponding to the REGISTER is processed by the standby node. When the SIP response message is returned, the subsequent message that does not carry the registered user in the message has a standby node. Forced routing information. In step S810, the message is forwarded to the transit node. Step S812, the transit node forwards the response message to the terminal or the node. Step S814, the subsequent request message sent by the terminal or the node does not add the mandatory routing information header field. Step S816, the request message is forwarded to the responsible node by the transit node. Step S818, the responsible node determines whether the message is processed by the local node according to the current load condition. If processed by the local node, the processing flow is the same as the normal message processing flow. If the node cannot process and needs to be handed over to other nodes for processing, the processing flow is the same as the figure. 4 is shown. Step S820, after the processing is completed, a response message is returned. Step S822, the response message is forwarded to the terminal or node through the transit node. The synchronization data described in the foregoing fifth embodiment is the synchronous data operation initiated by the standby node. Of course, the responsible node may initiate the data synchronization operation actively. FIG. 9 is a processing flow of the node actively synchronizing data according to an embodiment of the present invention. The specific process of the figure includes steps S902 to S922. Step S902: The terminal or the node sends a SIP request message to the P2P overlay network, and the SIP message is forwarded by the transit node. Step S904, the transit node forwards the message to the responsible node. Step S906, since the responsible node is busy at this time, the new SIP request message cannot be processed. Step S908, the responsible node forwards the request message to the standby node, and the standby node processes, and the responsible node adds an identifier to the forwarded request message, marking the primary node is busy, and the remote node is processed, and the identifier may be added in the message. The node is busy identifying, or it can generate a temporary resource or host ID and insert it into the message. Step S910: After receiving the request message, the standby node searches for the tag added by the responsible node in the message, so the data required for processing the request is obtained, and the request processing is performed. Step S912, after the standby node completes the request, returns a response message. Step S914, the response message is forwarded to the transit node by the responsible node. Step S916, the transit node sends a response message to the terminal or node that sends the request message. In step S918, after the load of the responsible node is reduced and the busy state is released, the data synchronization operation can be completed. Step S920, the node is responsible for initiating a data synchronization operation request to the standby node where the data is changed, and requesting to acquire the data change content. Step S922, the standby node returns the data change content, thereby completing data synchronization. The preferred embodiment 6 of course, in the extreme case, also has the same moment when the node is overloaded, and the standby node is also overloaded at the same time, unable to handle the new request. FIG. 10 is a message processing flowchart of a standby node being simultaneously overloaded according to an embodiment of the present invention, and the specific process includes steps S1002 to S1026. Step SI 002, the terminal or the node sends a SIP request message to the P2P overlay network, and the SIP message is forwarded through the transit node. In step S1004, the transit node forwards the message to the responsible node. In step S1006, since the responsible node is busy at this time, the new SIP request message cannot be processed. Step S1008: The responsible node forwards the request message to the standby node for processing, adds an identifier to the forwarded request message, marks that the primary node is busy, and is handed over to the standby node for processing, and the identifier may be adding the responsible node to the busy identifier in the message, or Is to generate a temporary resource or host ID, inserted into the message. In step S1010, the standby node is busy and cannot process the new SIP request message. Step S1012: The standby node forwards the request message to the next standby node for processing, adds an identifier to the forwarded request message, marks that the standby node is busy, and is processed by the next standby node, and the identifier may be that the standby node is busy in the message. The identifier may also be a temporary resource or a host identifier, which replaces the identifier added by the original responsible node. Step S1014: After receiving the request message, the next standby node searches for the identifier added by the responsible node and/or the standby node in the message, so the data required for processing the request is obtained, and the request processing is performed. Step S1016, returning a response message after completing the processing. In step S1018, the response message is forwarded by the standby node to the responsible node. Step S1020: The response message is forwarded by the responsible node to the transit node. Step S1022: The response message is forwarded by the transit node to the terminal or the node. Step S1024, when the processing in the next standby node causes the modification of the data in the overlay network, the next standby node sends a data update request message to the responsible node of the data to perform data modification, where the responsible node of the data may be the responsible node of the request. Alternatively, the two nodes are combined into the same node for convenience of presentation. Step S1026, after the responsible node of the data completes the data update request message, returns a data update response message, and completes the processing of the message in the case of overload of the overlay network. FIG. 11 is a structural block diagram of a processing device for network overload according to an embodiment of the present invention. As shown in FIG. 11, a receiving module 1102, a determining module 1104, and an indicating module 1106 are included. The structure is described in detail below. The receiving module 1102 is configured to receive a request message from the terminal or the node; the determining module 1104 is connected to the receiving module 1102, and is configured to determine that the request message received by the receiving module 1102 cannot be processed; the indicating module 1106 is connected to the receiving module 1102 and the determining module. 1104. Set, after the determining module 1104 determines that the request message cannot be processed, instructing the standby node to process the request message received by the receiving module 1102. It can be seen that the method provided by the present invention realizes the normal processing of the new request message when the node is overloaded in the P2P network, fully utilizes the advantages of the P2P overlay network, and does not impose a large burden on the overlay network. Of course, the present invention may be embodied in various other various modifications and changes without departing from the spirit and scope of the invention. Modifications are intended to fall within the scope of the appended claims. In summary, according to the above embodiments of the present invention, a method and apparatus for processing network overload are provided. The invention solves the problem that the network overload processing method causes session loss and low processing capability when the responsible node is busy, and the standby node takes care of the new request, thereby achieving full utilization of the P2P overlay in the telecommunication network. The processing power of the network. Obviously, those skilled in the art should understand that the above modules or steps of the present invention can be implemented by a general-purpose computing device, which can be concentrated on a single computing device or distributed over a network composed of multiple computing devices. Alternatively, they may be implemented by program code executable by the computing device, such that they may be stored in the storage device by the computing device, or they may be separately fabricated into individual integrated circuit modules, or they may be Multiple modules or steps are made into a single integrated circuit module. Thus, the invention is not limited to any specific combination of hardware and software. The above is only the preferred embodiment of the present invention, and is not intended to limit the present invention, and various modifications and changes can be made to the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and scope of the present invention are intended to be included within the scope of the present invention.

Claims

Claim

1. A method for processing network overload, comprising:

The responsible node receives the request message from the terminal or node;

Determining that the request message cannot be processed;

Instructing the standby node to process the request message.

2. The method according to claim 1, wherein the instructing the standby node to process the request message comprises: adding an identifier to the request message, wherein the identifier is used to instruct the standby node to process the request message, where The identifier includes one of: a busy identifier indicating that the responsible node is busy, a temporary resource or a host identifier used to instruct the standby node to temporarily process the request message; and an add-on to the standby node Said request message after the identification.

The method according to claim 1, wherein after indicating that the standby node processes the request message, the method further includes:

The responsible node receives a request response from the standby node;

Forwarding the request response to the terminal or node.

The standby node determines that the request message cannot be processed;

The standby node instructs the next standby node to process the request message.

The method according to claim 4, after the standby node instructs the next standby node to process the request message, the method further includes:

The standby node receives a request response from the next standby node;

The standby node forwards the request response to the terminal or node through the responsible node.

The method according to claim 3 or 5, wherein, after forwarding the request response to the terminal or the node, the method further includes: if the request response includes mandatory routing information, for subsequent sending The INVITE request message within the session, the terminal or node is directly sent to the standby node across the responsible node. The method according to any one of claims 1 to 5, wherein, after forwarding the request response to the terminal or the node, the method further comprises: in case the standby node maintains a user registration relationship, for the subsequent The REGISTER request message to be sent, the terminal or node is directly sent to the standby node across the responsible node. The method according to any one of claims 1 to 5, wherein after the instructing the standby node to process the request message, the method further comprises: the standby node processing the request message. The method according to any one of claims 1 to 5, wherein after indicating that the standby node processes the request message, the method further includes: performing, between the responsible node and the standby node, the request The data corresponding to the message is updated. The method according to any one of claims 1 to 5, further comprising: after instructing the standby node to process the request message, further comprising:

Responsible node determines recovery processing capability;

Data update corresponding to the request message is performed between the responsible node and the standby node. A network overload processing device includes:

a receiving module, configured to receive a request message from a terminal or a node;

Determining a module, setting to determine that the request message cannot be processed;

The indication module is configured to instruct the standby node to process the request message.