[go: up one dir, main page]

WO2013053252A1 - Procédé et appareil de traitement des surcharges de réseau - Google Patents

Procédé et appareil de traitement des surcharges de réseau Download PDF

Info

Publication number
WO2013053252A1
WO2013053252A1 PCT/CN2012/078513 CN2012078513W WO2013053252A1 WO 2013053252 A1 WO2013053252 A1 WO 2013053252A1 CN 2012078513 W CN2012078513 W CN 2012078513W WO 2013053252 A1 WO2013053252 A1 WO 2013053252A1
Authority
WO
WIPO (PCT)
Prior art keywords
node
request message
message
standby
standby node
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2012/078513
Other languages
English (en)
Chinese (zh)
Inventor
陈志峰
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
ZTE Corp
Original Assignee
ZTE Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ZTE Corp filed Critical ZTE Corp
Publication of WO2013053252A1 publication Critical patent/WO2013053252A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/12—Avoiding congestion; Recovering from congestion
    • H04L47/122—Avoiding congestion; Recovering from congestion by diverting traffic away from congested entities

Definitions

  • the present invention relates to the field of communications, and in particular to a method and apparatus for processing network overload.
  • P2P Peer-to-Peer
  • SIP Session Initiation Protocol
  • FIG. 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
  • 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.
  • the access node 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.
  • 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.
  • 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.
  • the IETF is also studying the overload of SIP servers, and the result is called SOC (SIP Load Control).
  • FIG. 1 SIP Load Control
  • Step 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.
  • 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.
  • C/S client/server model
  • 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.
  • a method for processing a network overload 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the method further includes: 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.
  • 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.
  • a network overload processing apparatus 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.
  • 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. 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 REGI
  • 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.
  • the network overload processing method causes session loss and low processing capability.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the next standby node performs processing, thereby avoiding the request failure.
  • 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.
  • 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.
  • 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.
  • the terminal or node can find the actual processing of the request by adding mandatory routing information in the request information. 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.
  • 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.
  • 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.
  • the method further includes: 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. 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.
  • 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.
  • the responsible node can actively synchronize data with the standby node when not busy, thereby ensuring the accuracy of its own data.
  • 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.
  • 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.
  • the destination in the forwarding message needs to be replaced with the relevant identifier of the standby node.
  • 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.
  • 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.
  • 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.
  • 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.
  • a header field needs to be added in the response message for description, otherwise the subsequent message is processed by the responsible node.
  • 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 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.
  • 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.
  • 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 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • Step 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.
  • step S1004 the transit node forwards the message to the responsible node.
  • 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.
  • 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.
  • 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.
  • FIG. 11 is a structural block diagram of a processing device for network overload according to an embodiment of the present invention.
  • 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.
  • 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.
  • 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.
  • 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 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne un procédé et appareil de traitement des surcharges de réseau. Le procédé comporte les étapes suivantes : faire recevoir par un nœud responsable un message de demande envoyé en provenance d'un terminal ou d'un nœud ; déterminer que le message de demande ne peut pas être traité ; donner pour consigne à un nœud de réserve de traiter le message de demande. Dans les modes de réalisation de l'invention, le nœud du réseau qui est occupé peut transmettre les messages de demande à traiter à d'autres nœuds possédant une capacité de traitement, réduisant ainsi les pertes de session et exploitant de façon plus appropriée les caractéristiques et la capacité de traitement du réseau superposé de poste à poste (P2P).
PCT/CN2012/078513 2011-10-10 2012-07-11 Procédé et appareil de traitement des surcharges de réseau Ceased WO2013053252A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN2011103044879A CN103036928A (zh) 2011-10-10 2011-10-10 网络过载的处理方法及装置
CN201110304487.9 2011-10-10

Publications (1)

Publication Number Publication Date
WO2013053252A1 true WO2013053252A1 (fr) 2013-04-18

Family

ID=48023410

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2012/078513 Ceased WO2013053252A1 (fr) 2011-10-10 2012-07-11 Procédé et appareil de traitement des surcharges de réseau

Country Status (2)

Country Link
CN (1) CN103036928A (fr)
WO (1) WO2013053252A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109936603A (zh) * 2017-12-18 2019-06-25 厦门本能管家科技有限公司 一种基于http非直联网络通信方法

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103944974B (zh) * 2014-04-02 2017-10-17 华为技术有限公司 一种协议报文处理方法、控制器故障处理方法及相关设备
CN107786460A (zh) * 2017-09-08 2018-03-09 北京科东电力控制系统有限责任公司 一种基于令牌桶算法的电力交易系统请求管理与限流方法
CN108304455B (zh) * 2017-12-20 2022-04-29 创新先进技术有限公司 一种处理业务请求的方法、装置及设备

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101039263A (zh) * 2007-03-01 2007-09-19 华为技术有限公司 核心网节点过载的处理方法及移动交换设备和通信系统
CN101686172A (zh) * 2008-09-27 2010-03-31 华为技术有限公司 一种网关节点的选择方法、系统和设备

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6885634B1 (en) * 2001-01-24 2005-04-26 At&T Corp. Network protocol having staggered recovery
CN100471091C (zh) * 2003-10-10 2009-03-18 清华大学 基于fcp协议的san的双节点镜像集群的方法及系统
CN100396006C (zh) * 2005-12-20 2008-06-18 华为技术有限公司 一种网格计算中节点间负载转移的方法
CN101052212B (zh) * 2006-04-03 2010-09-22 华为技术有限公司 一种移动终端重新附着网络的方法
US7797426B1 (en) * 2008-06-27 2010-09-14 BitGravity, Inc. Managing TCP anycast requests
CN102118828A (zh) * 2009-12-30 2011-07-06 华为技术有限公司 用户设备接入控制的方法和装置
CN106850730A (zh) * 2011-04-08 2017-06-13 中兴通讯股份有限公司 一种对等网络节点过负荷过程中数据迁移的方法及系统

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101039263A (zh) * 2007-03-01 2007-09-19 华为技术有限公司 核心网节点过载的处理方法及移动交换设备和通信系统
CN101686172A (zh) * 2008-09-27 2010-03-31 华为技术有限公司 一种网关节点的选择方法、系统和设备

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109936603A (zh) * 2017-12-18 2019-06-25 厦门本能管家科技有限公司 一种基于http非直联网络通信方法
CN109936603B (zh) * 2017-12-18 2022-07-01 本无链科技(深圳)有限公司 一种基于http非直联网络通信方法

Also Published As

Publication number Publication date
CN103036928A (zh) 2013-04-10

Similar Documents

Publication Publication Date Title
JP6047229B2 (ja) 情報中心ネットワークにおける名前ベースの近隣探索及びマルチホップサービス探索
US7978631B1 (en) Method and apparatus for encoding and mapping of virtual addresses for clusters
JP5086475B2 (ja) ピアツーピア・オーバーレイ・ネットワークへのデバイスの最適参加のための方法および装置
TWI507077B (zh) 多路徑覆蓋網路及其多路徑管理協定（二）
WO2022179218A1 (fr) Procédé et appareil de communication
WO2021047515A1 (fr) Procédé et appareil d'acheminement de service
WO2012041604A1 (fr) Agrégation d'interfaces d'un réseau à large bande mobile
WO2011006324A1 (fr) Procédé et terminal destinés à une transmission de fichier
WO2013040970A1 (fr) Procédé et dispositif de sélection de nœud de relais
CN104660550B (zh) 一种在多服务器之间进行会话迁移的方法
US20230217355A1 (en) METHODS, SYSTEMS, AND COMPUTER READABLE MEDIA FOR COMMUNICATING DELEGATED NETWORK FUNCTION (NF) DISCOVERY RESULTS BETWEEN SERVICE COMMUNICATION PROXIES (SCPs) AND USING THE DELEGATED NF DISCOVERY RESULTS FOR ALTERNATE ROUTING
WO2021008591A1 (fr) Procédé, dispositif et système de transmission de données
CN101567769A (zh) 数据重传方法、系统及对等节点
WO2007033363A2 (fr) Systeme et procede permettant d'obtenir une connectivite par paquets entre des reseaux heterogenes
WO2013053252A1 (fr) Procédé et appareil de traitement des surcharges de réseau
WO2009000181A1 (fr) Procédé servant à acquérir des ressources transversales, un nœud pair à pair et un système pair à pair
CN102904761B (zh) 一种nvr堆叠的方法和nvr
JP2010068107A (ja) 通信装置、通信方法、及び通信プログラム
JP2011166453A (ja) ＳＩＰ（ＳｅｓｓｉｏｎＩｎｉｔｉａｔｉｏｎＰｒｏｔｏｃｏｌ）中継装置、パケット変換装置、ネットワークシステム、制御方法及び制御プログラム
CN102821118B (zh) 一种具备异构节点的网络中业务备份的方法和系统
CN110381007B (zh) Tcp加速方法及装置
US20150156164A1 (en) Communication system, communication control method, communication relay system, and communication relay control method
WO2011044835A1 (fr) Procédé et routeur d'accès pour optimisation de trajet
CN102739711B (zh) 一种对等网络中控制过负荷的方法及系统
CN114172965B (zh) 一种用户服务请求及处理方法、设备及介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12839968

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12839968

Country of ref document: EP

Kind code of ref document: A1