CN111355764B - Keep-alive message sending method and device, electronic equipment and readable storage medium - Google Patents

Keep-alive message sending method and device, electronic equipment and readable storage medium Download PDF

Info

Publication number
CN111355764B
CN111355764B CN201811587980.4A CN201811587980A CN111355764B CN 111355764 B CN111355764 B CN 111355764B CN 201811587980 A CN201811587980 A CN 201811587980A CN 111355764 B CN111355764 B CN 111355764B
Authority
CN
China
Prior art keywords
keep
time
sending
ppp
alive
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.)
Active
Application number
CN201811587980.4A
Other languages
Chinese (zh)
Other versions
CN111355764A (en
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.)
Maipu Communication Technology Co Ltd
Original Assignee
Maipu Communication Technology Co Ltd
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 Maipu Communication Technology Co Ltd filed Critical Maipu Communication Technology Co Ltd
Priority to CN201811587980.4A priority Critical patent/CN111355764B/en
Publication of CN111355764A publication Critical patent/CN111355764A/en
Application granted granted Critical
Publication of CN111355764B publication Critical patent/CN111355764B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1044—Group management mechanisms 
    • H04L67/1046—Joining mechanisms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/82—Miscellaneous aspects
    • H04L47/825—Involving tunnels, e.g. MPLS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1044—Group management mechanisms 
    • H04L67/1048—Departure or maintenance mechanisms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/142—Managing session states for stateless protocols; Signalling session states; State transitions; Keeping-state mechanisms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/143—Termination or inactivation of sessions, e.g. event-controlled end of session
    • H04L67/145—Termination or inactivation of sessions, e.g. event-controlled end of session avoiding end of session, e.g. keep-alive, heartbeats, resumption message or wake-up for inactive or interrupted session

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Theoretical Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Cardiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

The embodiment of the application provides a keep-alive message sending method, a keep-alive message sending device, electronic equipment and a readable storage medium, and belongs to the technical field of communication. The method comprises the following steps: after any PPP interface is successfully negotiated, calculating the first sending time of a first keep-alive message for sending the PPP interface according to the keep-alive period of the PPP interface; judging whether the number of PPP interfaces which need to send keep-alive messages in the first sending time in all PPP interfaces which are successfully negotiated at present exceeds a preset value; if the preset value is exceeded, the sending time of the first keep-alive message is adjusted to a second sending time, and the second sending time is later than the first sending time; and sending the first keep-alive message at the second sending time. Therefore, the number of PPP interfaces for transmitting the first keep-alive message at the same time is not too large, so that the problem of overlarge load caused by the fact that a network server LNS simultaneously processes the transmission of a large number of keep-alive messages is avoided.

Description

Keep-alive message sending method and device, electronic equipment and readable storage medium
Technical Field
The present application relates to the field of communications technologies, and in particular, to a keep-alive message sending method, a keep-alive message sending device, an electronic device, and a readable storage medium.
Background
With the development of data communication technology, a virtual private network (Virtual Private Network, abbreviated as VPN) has been proposed, and the purpose of the virtual private network is to ensure the security of communication, and to implement private communication through a three-layer or two-layer tunnel using a public network.
Network tunneling is a key technology for constructing VPNs. Network tunneling refers to the use of one network protocol to transmit another network protocol, i.e., to repackage existing transparent network information, thereby ensuring the security of network information transmission. It mainly uses network tunnel protocol to implement this function, and specifically includes Layer 2 Tunneling Protocol (L2 TP) and three-Layer tunnel Western medicine,
l2TP is commonly used and accepted, and particularly in the advent of third generation mobile communication technology, the L2TP protocol has become more widely used. The L2TP protocol is a two-layer tunneling protocol based on point-to-point PPP. Among VPNs constructed from L2TP, there are two types of servers, one is an L2TP access concentrator (L2 TP Access Concentrator, abbreviated as LAC), which is a device attached to a network and having a PPP end system and L2TP protocol processing capability, and LAC is generally a network access server for providing network access services to users, and the other is an L2TP network server LNS (L2 TP Network Server), which is software on the PPP end system for processing an L2TP protocol server end portion.
There are two types of connections between the LNS and the LAC, one is a tunnel connection that defines one LNS and LAC pair, and the other is a session connection that multiplexes over the tunnel connection to represent each PPP session procedure carried in the tunnel connection.
In the actual application process, the client data supported by the LNS is much, such as 1000 sessions, so the LNS has higher requirements on the performance of processing a large number of session PPP keep-alive and convergence time. In the prior art, when a connection is established between the LAC and the LNS, negotiation is first performed, the negotiation of the L2TP includes negotiation of a corresponding PPP protocol, after the negotiation between the LNS and the LAC, the two end devices are triggered to start sending and receiving PPP keep-alive messages, where the PPP keep-alive messages are used to enable the two end devices to determine whether the opposite party exists, if the LNS periodically sends the PPP keep-alive messages to the LAC, after the LNS sends a plurality of PPP keep-alive messages, the LNS does not receive response information returned by the LAC, and then the LNS is likely to indicate that the opposite party LAC has been disconnected, and then the LNS automatically disconnects the corresponding PPP interface.
However, if the sending and receiving of keep-alive messages of a large number of different PPP interfaces processed by the LNS exceeds the processing performance of the LNS, the LNS may not have more processing capacity to process the negotiation of a new LAC, so a large number of negotiation messages may be possibly sent repeatedly, resulting in repeated concussion of session negotiation of L2TP, so that the network load with heavy load is more increased, thereby forming an avalanche effect, but a corresponding solution is not proposed in the prior art.
Disclosure of Invention
The embodiment of the application aims to provide a keep-alive message sending method, a keep-alive message sending device, electronic equipment and a readable storage medium.
In a first aspect, an embodiment of the present application provides a keep-alive message sending method, where the method includes: after any PPP interface is successfully negotiated, calculating the first sending time of a first keep-alive message for sending the PPP interface according to the keep-alive period of the PPP interface; judging whether the number of PPP interfaces which need to send keep-alive messages in the first sending time in all PPP interfaces which are successfully negotiated at present exceeds a preset value; if the preset value is exceeded, the sending time of the first keep-alive message is adjusted to a second sending time, and the second sending time is later than the first sending time; and sending the first keep-alive message at the second sending time.
In the implementation process, the time for sending the first keep-alive message by each PPP interface is adjusted so that the number of PPP interfaces for sending the first keep-alive message at the same time is not too large, thereby avoiding the problem of overlarge load caused by that the network server LNS simultaneously processes the sending of a large number of keep-alive messages.
Optionally, the adjusting the sending time of the first keep-alive message to the second sending time includes: calculating discrete time according to the number of PPP interfaces which are successfully negotiated and the number of PPP interfaces which need to send keep-alive messages at the first sending time, adding the discrete time to the first sending time to obtain the second sending time, and taking the second sending time as the sending time of the first keep-alive messages.
In the implementation process, the sending time of the first keep-alive message sent by the PPP interface is adjusted to be the second sending time, and the second sending time is obtained by adding the obtained discrete time to the first sending time, namely, the time of the first keep-alive message sent by the PPP interface is prolonged, so that the time of the PPP interface, which can send the first keep-alive message at the same time, can be staggered, and the processing pressure of the LNS is reduced.
Optionally, the sending the first keep-alive message at the second sending time includes: placing the second sending time into a keep-alive period node of a time array; when the second sending time is the minimum value in the time array, adding the second sending time into a small root pile; and based on the small root stack, after the second sending time is reached, sending the first keep-alive message of any PPP interface.
In the implementation process, the LNS processes the sending time of each PPP interface sending keep-alive message through the constructed small root stack, and the data processing efficiency of the LNS can be improved because the small root stack has higher performance.
Optionally, the placing the second sending time into the keep-alive period node of the time array includes: and adding the second sending time to the corresponding position in the node of the keep-alive period of any PPP interface of the time array according to the order of the time values from small to large according to the time array constructed for the node based on the keep-alive period of each PPP interface.
In the implementation process, the sending time is added into the small root pile according to the time value, so that the LNS can process the sending time of each PPP interface sending keep-alive message through the constructed small root pile, and the data processing efficiency of the LNS can be improved.
Optionally, the sending the first keep-alive message at the second sending time further includes: adding the second transmission time to the small root heap when the second transmission time is not the minimum value in the time array and the second transmission time is the minimum value in the time array; and based on the small root stack, after the second sending time is reached, sending the first keep-alive message of any PPP interface.
In the implementation process, the sending time is added to the small root pile, so that the node number of the small root pile is reduced, the performance of the small root pile is further improved, and the data processing efficiency of the LNS is further improved.
In a second aspect, an embodiment of the present application provides a keep-alive message sending apparatus, where the apparatus includes:
the time calculation module is used for calculating the first sending time of a first keep-alive message for sending the PPP interface according to the keep-alive period of the PPP interface after any PPP interface is successfully negotiated;
the judging module is used for judging whether the number of PPP interfaces which need to send keep-alive messages at the first sending time in all PPP interfaces which are successfully negotiated at present exceeds a preset value;
the time adjustment module is used for adjusting the sending time of the first keep-alive message to a second sending time when the number of PPP interfaces for sending the keep-alive message at the first sending time exceeds a preset value, wherein the second sending time is later than the first sending time;
and the keep-alive message sending module is used for sending the first keep-alive message at the second sending time.
Optionally, the time adjustment module is specifically configured to calculate a discrete time according to the number of PPP interfaces that are successfully negotiated and the number of PPP interfaces that need to send a keep-alive message at the first sending time, add the discrete time to the first sending time to obtain the second sending time, and use the second sending time as the sending time of the first keep-alive message.
Optionally, the keep-alive message sending module is specifically configured to:
placing the second sending time into a keep-alive period node of a time array;
when the second sending time is the minimum value in the time array, adding the second sending time into a small root pile;
and based on the small root stack, after the second sending time is reached, sending the first keep-alive message of any PPP interface.
Optionally, the keep-alive message sending module is further configured to add the second sending time to a corresponding position in a node where a keep-alive period of any PPP interface of the time array is located according to a time array constructed for the node based on the keep-alive period of each PPP interface according to a sequence of time values from first to last.
Optionally, the keep-alive message sending module is further configured to add the second sending time to the small root heap when the second sending time is not the minimum value in the time array and when the second sending time becomes the minimum value in the time array; and based on the small root stack, after the second sending time is reached, sending the first keep-alive message of any PPP interface.
In a third aspect, an embodiment of the present application provides an electronic device comprising a processor and a memory storing computer readable instructions which, when executed by the processor, perform the steps of the method as provided in the first aspect above.
In a fourth aspect, embodiments of the present application provide a readable storage medium having stored thereon a computer program which when executed by a processor performs the steps of the method as provided in the first aspect above.
The embodiment of the application provides a keep-alive message sending method, a device, electronic equipment and a readable storage medium, wherein after any PPP interface is successfully negotiated, the method calculates the first sending time of a first keep-alive message sending the PPP interface according to the keep-alive period of the PPP interface, then judges whether the number of PPP interfaces needing to send the keep-alive message at the first sending time in all PPP interfaces successfully negotiated at present exceeds a preset value, if so, adjusts the sending time of the first keep-alive message to the second sending time, wherein the second sending time is later than the first sending time, and sends the first keep-alive message at the second sending time, so that the number of PPP interfaces sending the first keep-alive message at the same time is not too large by adjusting the sending time of each PPP interface, and the problem of overlarge load caused by simultaneously processing the sending of a large number of keep-alive messages by a network server LNS is avoided.
Additional features and advantages of the application will be set forth in the description which follows, and in part will be apparent from the description, or may be learned by practice of the embodiments of the application. The objectives and other advantages of the application will be realized and attained by the structure particularly pointed out in the written description and claims thereof as well as the appended drawings.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are needed in the embodiments will be briefly described below, it being understood that the following drawings only illustrate some embodiments of the present application and therefore should not be considered as limiting the scope, and other related drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.
FIG. 1 is a flowchart of a keep-alive message sending method provided by an embodiment of the present application;
fig. 2 is a schematic structural diagram of a small root pile according to an embodiment of the present application;
FIG. 3 is a schematic structural diagram of a root pile according to an embodiment of the present application;
FIG. 4 is a block diagram of a keep-alive message sending device according to an embodiment of the present application;
fig. 5 is a schematic structural diagram of an electronic device according to an embodiment of the present application.
Detailed Description
The following description of the embodiments of the present application will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present application, but not all embodiments. The components of the embodiments of the present application generally described and illustrated in the figures herein may be arranged and designed in a wide variety of different configurations. Thus, the following detailed description of the embodiments of the application, as presented in the figures, is not intended to limit the scope of the application, as claimed, but is merely representative of selected embodiments of the application. All other embodiments, which can be made by a person skilled in the art without making any inventive effort, are intended to be within the scope of the present application.
It should be noted that: like reference numerals and letters denote like items in the following figures, and thus once an item is defined in one figure, no further definition or explanation thereof is necessary in the following figures. Meanwhile, in the description of the present application, the terms "first", "second", and the like are used only to distinguish the description, and are not to be construed as indicating or implying relative importance.
In the prior art, after negotiation is established between the LNS and the LAC, the LNS allocates a PPP interface for the LAC, where the PPP interface is used for sending and receiving keep-alive messages between the LNS and the LAC, if the LNS negotiates with a plurality of LACs, the send and receive of the keep-alive messages will be processed, if thousands of sessions need to be processed by the LNS at this time, and the processing of the sessions needs to consume a large amount of processing performance of the LNS, so that the LNS may not have more processing capacity to process negotiation of a new LAC, so that a large amount of negotiation messages are likely to be sent repeatedly, the processing burden of the LNS is again increased, and session negotiation of L2TP may be repeatedly oscillated, so as to form an avalanche effect. Therefore, in order to solve the above-mentioned problems, the embodiment of the present application provides a keep-alive message sending method.
Referring to fig. 1, fig. 1 is a flowchart of a keep-alive message sending method according to an embodiment of the present application, where the method includes the following steps:
step S110: after any PPP interface negotiation is successful, calculating the first sending time of the first keep-alive message of the PPP interface according to the keep-alive period of the PPP interface.
Step S120: judging whether the number of PPP interfaces which need to send keep-alive messages at the first sending time in all PPP interfaces which are successfully negotiated at present exceeds a preset value.
A large number of PPP interfaces are created on the LNS for establishing session connection with the LAC, and because the LNS processes the PPP interfaces one by one, for example, the LAS currently establishes a plurality of PPP interfaces, the LNS processes the first PPP interface which is established first to send a keep-alive message, then processes the second PPP interface to send the keep-alive message, and because the LNS processes the PPP interfaces very fast, the LNS can also be regarded as simultaneously processing all the PPP interfaces. Each PPP interface is configured with a corresponding keep-alive message sending period, and the keep-alive message sending periods of the multiple PPP interfaces may be the same or different.
Therefore, after any PPP interface negotiation is successful, the first sending time of the first keep-alive message of the PPP interface can be calculated according to the keep-alive surrounding period configured by the PPP interface. If the configured keep-alive period is 10s for a certain PPP interface, the first sending time of the first keep-alive message sent by the PPP interface is the current system time plus the keep-alive period of 10s after the PPP interface is successfully negotiated.
In order to reduce the processing pressure caused by that the LNS needs to process the plurality of PPP interfaces to send the keep-alive messages at the same time, before any PPP interface sends the first keep-alive message, the sending time of the first keep-alive message sent by the PPP interface is adjusted, so that the sending time of the keep-alive messages sent by the plurality of PPP interfaces at the same time is staggered.
For example, if 500 PPP interfaces are currently created on the LNS, after determining the first sending time of the first keep-alive message sent by the PPP interface that is currently successfully negotiated, then determining whether the number of PPP interfaces that need to send the keep-alive message at the first sending time in all the PPP interfaces that are currently successfully negotiated exceeds a preset value, that is, firstly calculating the number of PPP interfaces that need to send the keep-alive message at the first sending time in the 500 PPP interfaces, because the keep-alive periods of each PPP interface are likely to be set different, because the negotiation success times are different, there is a high probability that a plurality of PPP interfaces will send the keep-alive message at the first sending time, resulting in the processing pressure of the LNS.
In the following, a specific example will be described, for example, for any PPP interface that is successfully negotiated at present, the set keep-alive period is 10S, if the current time is 8:30, the time for any PPP interface that is successfully negotiated at present to send the first keep-alive message is 8:40, that is, the first sending time is 8:40, at this time, the time for other PPP interfaces that have already been successfully negotiated to send the keep-alive message is detected, for example, the 2 nd PPP interface that has already been successfully negotiated is checked, the set keep-alive period is 5S, according to the system record, the time for sending the next keep-alive message is 8:35, the time for sending the first keep-alive message with any PPP interface that is successfully negotiated at present is inconsistent, the keep-alive period set by the 3 rd PPP interface that has already been successfully negotiated is checked to be 8S, however, the time for sending the next keep-alive message by the 3 rd PPP interface is the same as the time for sending the first keep-alive message by any one PPP interface that is successfully negotiated at present, so that the time for sending the next keep-alive message by all the PPP interfaces that are successfully negotiated is traversed and obtained one by one, so that the number of PPP interfaces that need to send the keep-alive message at the first sending time can be counted, and then whether the number exceeds a preset value is judged, for example, if the number of PPP interfaces that need to send the keep-alive message at the first sending time is counted to be 400, since the current processing capacity of the LNS may only process the sending of the keep-alive messages of 300 PPP interfaces, the preset value can be set to 300, at this time, if the number exceeds 300, the load indicating that the LNS processes keep-alive is too large, and when the number of PPP interfaces that need to send the keep-alive message at the first sending time exceeds the preset value, step S130 is executed: and adjusting the sending time of the first keep-alive message to a second sending time.
Wherein the second transmission time is later than the first transmission time. In order to stagger the time of sending keep-alive messages at the same time by the multiple PPP interfaces, the sending time of the keep-alive messages can be adjusted from the first sending time to a second sending time after the first sending time, for example, if the first sending time of sending the first keep-alive message to any PPP interface that is successfully negotiated at present is 8:40, the first sending time can be adjusted to the second sending time, for example, 8:45, and the first sending time of sending the first keep-alive message to any PPP interface that is successfully negotiated at present can be adjusted to the second sending time. The same principle is that the same processing manner is adopted for the PPP interface which is just successful in negotiation 2, namely if the first sending time of the PPP interface which is just successful in negotiation 2 for sending the first keep-alive message is 8:32, the number of PPP interfaces which need to send the keep-alive message in all PPP interfaces which are successful in negotiation in the whole system is firstly judged when the number is 8:32, if the number exceeds a preset value, the first sending time of the PPP interface which is just successful in negotiation 2 for sending the first keep-alive message is adjusted to be the second sending time, such as 8:34, and other PPP interfaces are processed in sequence according to the manner, so that the number of PPP interfaces which send the keep-alive message at the same time in all PPP interfaces does not exceed the preset value. Therefore, the problem of overload caused by the fact that the LNS processes keep-alive of a plurality of PPP interfaces at the same time can be avoided.
Step S140: and sending the first keep-alive message at the second sending time.
After the sending time of the first keep-alive message of the multiple PPP interfaces is adjusted to the second sending time, it should be understood that the second sending time is the time of sending the first keep-alive message corresponding to each PPP interface, so when the second sending time arrives, the first keep-alive message can be sent through each PPP interface, if the second sending time of the 1 st PPP interface expires 8:30, the first keep-alive message is sent through the 1 st PPP interface, and if the second sending time of the 2 nd PPP interface expires 8:40, the first keep-alive message is sent through the 2 nd PPP interface, so that the corresponding first keep-alive message can be sent sequentially according to the second sending time of each PPP interface.
Because the time of sending the first keep-alive message by the PPP interface which is successfully negotiated at present and the time of sending the next keep-alive message by the PPP interface which is successfully negotiated at present are staggered, so that no great number of PPP interfaces need to send keep-alive messages at the same time, thereby reducing the pressure of LNS for simultaneously processing a great number of keep-alive messages, so that after the PPP interfaces send the first keep-alive message according to the adjusted time, the subsequent keep-alive messages are sent according to the sending period of the keep-alive messages of each PPP interface, for example, the 1 st PPP interface sends the first keep-alive message when the 8:30 time, if the set keep-alive period of the 1 st PPP interface is 10s, the keep-alive messages sent by the 1 st PPP interface are all sent in the period of 10s, for example, the time of the 2 nd keep-alive message sent by the 1 st PPP interface is 8:40, and the time of the 3 rd keep-alive message sent by the 1 PPP interface is 8:50.
Therefore, in the scheme, the time for sending the keep-alive messages is staggered, so that the number of PPP interfaces for sending the keep-alive messages at the same time is not too large, and the problem of overlarge load caused by that a server LNS simultaneously processes a large number of keep-alive messages is avoided.
In addition, based on the above embodiment, the discrete time may be calculated according to the number of PPP interfaces that are successfully negotiated and the number of PPP interfaces that need to send the keep-alive message at the first sending time, the second sending time may be obtained by adding the discrete time to the first sending time, and the second sending time may be used as the sending time of the first keep-alive message.
The sending time of the first keep-alive message sent by the PPP interface is adjusted to be the second sending time, wherein the second sending time is the time after the first sending time passes the discrete time, namely the time of the first keep-alive message sent by the PPP interface is prolonged, so that the time of the PPP interface for sending the keep-alive message at the same time can be staggered, and the processing pressure of the LNS is reduced.
Wherein, the calculation formula of the discrete time is: discrete time=ln (the number M of all PPP interfaces that are currently successful in negotiating+the number P of interfaces that are to transmit keep-alive messages at the first transmission time), or discrete time=ln (the number M of all PPP interfaces that are currently successful in negotiating+the number P of interfaces that are to transmit keep-alive messages at the first transmission time) +the first preset value, or discrete time=ln (the number M of all PPP interfaces that are currently successful in negotiating+the number P of interfaces that are to transmit keep-alive messages at the first transmission time)/the second preset value, where P is less than or equal to M. The specific values of the first preset value and the second preset value can be set according to actual conditions, for example, 1,2,3.
Of course, the above-mentioned discrete-time calculation formula is not limited to the above-mentioned calculation method, and may be calculated by itself according to a rule defined in advance, for example, discrete-time=log 2 (the number of PPP interfaces M+ which are successfully negotiated at present and the number of interfaces P which are required to send keep-alive messages at the first sending time).
It should be noted that, the value of the general discrete time does not exceed the corresponding settable maximum keep-alive period of the PPP interface, if the maximum settable keep-alive period of the 1 st PPP interface is 10s, the value range of the discrete time is 0-10s, which is of course only the general case, and the discrete time is obtained in this way, and in the specific practical application process, the corresponding discrete time can also be obtained according to specific requirements.
As an implementation manner, to improve performance of LNS processing keep-alive message transmission, the first keep-alive message is sent at the second sending time, including: placing the second sending time into a keep-alive period node of a time array; when the second sending time is the minimum value in the time array, adding the second sending time into a small root pile; and based on the small root stack, after the second sending time is reached, sending the first keep-alive message of any PPP interface.
The small root heap is a sorted complete binary tree, wherein the data value of any non-terminal node is not greater than the values of the left child node and the right child node, namely the data value meets the following properties:
key [ i ] <=key [2i+1] & Key [ i ] <=key [2i+2] or
Key[i]>＝Key[2i+1]&&key>＝key[2i+2]。
As shown in fig. 2, a schematic diagram of a small root heap is shown, in which a node at the top is a root node, and the key value of the root node is the smallest of all heap node key values. In this embodiment, the second sending time of the first keep-alive message may be sent by the PPP interface that obtains the current negotiation success, and the second sending time is put into the keep-alive period node of the constructed time array.
Specifically, the second sending time may be added to the corresponding position in the node where the keep-alive period of any PPP interface of the time array is located according to the time array constructed for the node based on the keep-alive period of each PPP interface according to the order of the time values from first to last.
For simplicity of description, taking 5 PPP interfaces as an example, in the above manner, the 5 PPP interfaces may be obtained and are located in the same node of the time array constructed by using the keep-alive period as the node, and are ordered according to the time sequence: PPP interface 1: 8:30, 3 rd PPP interface: 8:35, 2 nd PPP interface: 8:36, 4 th PPP interface: 8:40, 5 th PPP interface: 8:43, in the time array, each time value is ordered from small to large, then a small root heap is built based on the time array, as shown in fig. 3, the time for sending keep-alive messages by the PPP interfaces corresponding to each sending period node in the small root heap is shown in fig. 3, for example, at the root node, the second sending time at the root node is 8:30, the value is the earliest value in the small root heap, a timer is set in the small root heap to detect in real time whether the earliest time of the small root heap expires, if the earliest time in the small root heap is 8:30 at the current time, the first PPP interface corresponding to the first PPP interface when the first PPP interface is 8:30 is required to send the keep-alive messages, and after the time of the first root node is processed, the 8:30 in the small root heap is taken out, and then the keep-alive messages are sent by the first PPP interface. If the keep-alive period set by the 1 st PPP interface is 7s, the time for the 1 st PPP interface to send the second keep-alive message is 8:37, updating the small root stack, adding the 8:37 to the small root stack again to obtain the small root stack as shown in the right side of fig. 3, detecting the expiration time of the second sending time stored by the root node in the small root stack again, and then continuing to process the sending time of the keep-alive message corresponding to each PPP interface in the small root stack according to the method.
In the above manner, how many PPP interfaces need to construct how many root stacks of nodes, and in the processing process, the root stacks move with time, that is, update the values of the nodes, and since the performance of inserting and deleting the root stacks can be improved to log N, where N is the number of nodes of the root stacks, the LNS can process the sending time of the keep-alive message sent by each PPP interface through the root stacks, which can improve the processing efficiency of the LNS.
In addition, in order to reduce the node number of the small root heap and further improve the performance of the small root heap, when the second sending time is not the minimum value in the time array, the second sending time can be added to the small root heap when the second sending time becomes the minimum value in the time array; and based on the small root stack, after the second sending time is reached, sending the first keep-alive message of any PPP interface.
That is, the second sending time of the first keep-alive message corresponding to the any PPP interface in the time array is not the minimum value of the corresponding keep-alive period node in the time array, the second sending time is added to the corresponding keep-alive period node in the time array according to the size of the time value, when the second sending time of the any PPP interface is the minimum value in the time array, the second sending time of the any PPP interface is added to the small root heap, and when the second sending time in the small root heap is detected to be reached, the first keep-alive message of the any PPP interface is sent.
Of course, if the number of nodes of the root heap is limited, the number of second sending times added into the root heap is limited, if the number of PPP interfaces is 500, the root heap with the number of nodes of 500 needs to be built each time, and in the updating process of the root heap, the values of all nodes are likely to need to be updated, so that the root heap with the number of nodes of the preset number can be built, that is, the time for sending keep-alive messages corresponding to the preset number of PPP interfaces is acquired from 500 PPP interfaces, for example, the preset number is 100, and the time for sending keep-alive messages corresponding to the 100 PPP interfaces is earlier than the time for sending keep-alive messages by the remaining 400 PPP interfaces. And then adding the sending time of the keep-alive messages corresponding to the 100 PPP interfaces into each node of the small root stack in the sequence from the early to the late, namely, the number of the nodes of the small root stack is 100, the processing procedure of the small root stack is the same as that described above, and redundant description is omitted.
Referring to fig. 4, fig. 4 is a block diagram of a keep-alive message sending apparatus 200 according to an embodiment of the present application, where the apparatus includes:
the time calculation module 210 is configured to calculate, after any PPP interface negotiation succeeds, a first sending time of a first keep-alive message for sending the PPP interface according to a keep-alive period of the PPP interface;
a judging module 220, configured to judge whether the number of PPP interfaces that need to send a keep-alive message at the first sending time in all PPP interfaces that are successfully negotiated at present exceeds a preset value;
a time adjustment module 230, configured to adjust, when the number of PPP interfaces for which the first sending time needs to send a keep-alive message exceeds a preset value, the sending time of the first keep-alive message to a second sending time, where the second sending time is later than the first sending time;
and a keep-alive message sending module 240, configured to send the first keep-alive message at the second sending time.
Optionally, the time adjustment module 230 is specifically configured to calculate a discrete time according to the number of PPP interfaces that are successfully negotiated and the number of PPP interfaces that need to send a keep-alive message at the first sending time, obtain the second sending time by adding the discrete time to the first sending time, and use the second sending time as the sending time of the first keep-alive message.
Optionally, the keep-alive message sending module 240 is specifically configured to:
placing the second sending time into a keep-alive period node of a time array;
when the second sending time is the minimum value in the time array, adding the second sending time into a small root pile;
and based on the small root stack, after the second sending time is reached, sending the first keep-alive message of any PPP interface.
Optionally, the keep-alive message sending module 240 is further configured to add the second sending time to a corresponding position in the node where the keep-alive period of any PPP interface of the time array is located according to a time array constructed for the node based on the keep-alive period of each PPP interface according to a sequence of time values from first to last.
Optionally, the keep-alive message sending module 240 is further configured to add the second sending time to the root pile when the second sending time is not the minimum value in the time array and when the second sending time becomes the minimum value in the time array; and based on the small root stack, after the second sending time is reached, sending the first keep-alive message of any PPP interface.
Referring to fig. 5, fig. 5 is a schematic structural diagram of an electronic device according to an embodiment of the present application, where the electronic device may include: at least one processor 110, such as a CPU, at least one communication interface 120, at least one memory 130, and at least one communication bus 140. Wherein the communication bus 140 is used to enable direct connection communication of these components. The communication interface 120 of the device in the embodiment of the present application is used for performing signaling or data communication with other node devices. The memory 130 may be a high-speed RAM memory or a non-volatile memory (non-volatile memory), such as at least one disk memory. Memory 130 may also optionally be at least one storage device located remotely from the aforementioned processor. The memory 130 has stored therein computer readable instructions which, when executed by the processor 110, perform the method process described above in fig. 1.
An embodiment of the present application provides a readable storage medium, which when executed by a processor, performs a method process performed by an electronic device in the method embodiment shown in fig. 1.
It will be clear to those skilled in the art that, for convenience and brevity of description, reference may be made to the corresponding procedure in the foregoing method for the specific working procedure of the apparatus described above, and this will not be repeated here.
In summary, the embodiment of the present application provides a method, an apparatus, an electronic device, and a readable storage medium for sending a keep-alive message, where after any PPP interface negotiates successfully, a first sending time for sending a first keep-alive message of the PPP interface is calculated according to a keep-alive period of the PPP interface, and then it is determined whether the number of PPP interfaces that need to send the keep-alive message at the first sending time in all PPP interfaces that are successfully negotiated currently exceeds a preset value, if so, the sending time of the first keep-alive message is adjusted to a second sending time, where the second sending time is later than the first sending time, and the first keep-alive message is sent at the second sending time, so that the number of PPP interfaces that send the first keep-alive message at the same time is not too large by adjusting the time of sending the first keep-alive message of each PPP interface, so as to avoid the problem that the network server simultaneously processes the sending of a large number of keep-alive messages and the LNS has too large load.
In the several embodiments provided in the present application, it should be understood that the disclosed apparatus and method may be implemented in other manners. The apparatus embodiments described above are merely illustrative, for example, of the flowcharts and block diagrams in the figures that illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
In addition, functional modules in the embodiments of the present application may be integrated together to form a single part, or each module may exist alone, or two or more modules may be integrated to form a single part.
The functions, if implemented in the form of software functional modules and sold or used as a stand-alone product, may be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application may be embodied essentially or in a part contributing to the prior art or in a part of the technical solution, in the form of a software product stored in a storage medium, comprising several instructions for causing a computer device (which may be a personal computer, a server, a network device, etc.) to perform all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a random access Memory (RAM, random Access Memory), a magnetic disk, or an optical disk, or other various media capable of storing program codes.
The above description is only of the preferred embodiments of the present application and is not intended to limit the present application, but various modifications and variations can be made to the present application by those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the keep-alive scope of the present application. It should be noted that: like reference numerals and letters denote like items in the following figures, and thus once an item is defined in one figure, no further definition or explanation thereof is necessary in the following figures.
While the application has been described with respect to specific embodiments thereof, the scope of the application is not limited thereto, and variations and substitutions will be apparent to those skilled in the art within the scope of the application, and are intended to be included within the scope of the application. Therefore, the scope of the present application shall be defined by the scope of the claims.
It is noted that relational terms such as first and second, and the like are used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Moreover, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

Claims (12)

1. The keep-alive message sending method is characterized by comprising the following steps:
after any PPP interface is successfully negotiated, calculating a first sending time of a first keep-alive message of the PPP interface according to a keep-alive period of the PPP interface, wherein the PPP interface is a pointing-to-point protocol interface;
judging whether the number of PPP interfaces which need to send keep-alive messages in the first sending time in all PPP interfaces which are successfully negotiated at present exceeds a preset value;
if the preset value is exceeded, the sending time of the first keep-alive message is adjusted to a second sending time, and the second sending time is later than the first sending time;
and sending the first keep-alive message at the second sending time.
2. The method of claim 1, wherein said adjusting the transmission time of the first keep-alive message to a second transmission time comprises:
calculating discrete time according to the number of PPP interfaces which are successfully negotiated and the number of PPP interfaces which need to send keep-alive messages at the first sending time, adding the discrete time to the first sending time to obtain the second sending time, and taking the second sending time as the sending time of the first keep-alive messages.
3. The method according to claim 1 or 2, wherein said sending the first keep-alive message at the second sending time comprises:
placing the second sending time into a keep-alive period node of a time array;
when the second sending time is the minimum value in the time array, adding the second sending time into a small root pile;
and based on the small root stack, after the second sending time is reached, sending the first keep-alive message of any PPP interface.
4. The method of claim 3, wherein the placing the second transmit time into the keep-alive period node of the time array comprises:
and adding the second sending time to the corresponding position in the node of the keep-alive period of any PPP interface of the time array according to the order of the time values from small to large according to the time array constructed for the node based on the keep-alive period of each PPP interface.
5. The method of claim 3, wherein the sending the first keep-alive message at the second sending time further comprises:
adding the second transmission time to the small root heap when the second transmission time is not the minimum value in the time array and the second transmission time is the minimum value in the time array;
and based on the small root stack, after the second sending time is reached, sending the first keep-alive message of any PPP interface.
6. A keep-alive message sending device, the device comprising:
the time calculation module is used for calculating the first sending time of the first keep-alive message of the PPP interface according to the keep-alive period of the PPP interface after any PPP interface is successfully negotiated, wherein the PPP interface is a pointing-to-point protocol interface;
the judging module is used for judging whether the number of PPP interfaces which need to send keep-alive messages at the first sending time in all PPP interfaces which are successfully negotiated at present exceeds a preset value;
the time adjustment module is used for adjusting the sending time of the first keep-alive message to a second sending time when the number of PPP interfaces for sending the keep-alive message at the first sending time exceeds a preset value, wherein the second sending time is later than the first sending time;
and the keep-alive message sending module is used for sending the first keep-alive message at the second sending time.
7. The apparatus of claim 6, wherein the time adjustment module is specifically configured to calculate a discrete time according to a number of PPP interfaces that are successfully negotiated and a number of PPP interfaces that need to send a keep-alive message at the first sending time, obtain the second sending time by adding the discrete time to the first sending time, and use the second sending time as the sending time of the first keep-alive message.
8. The apparatus according to claim 6 or 7, wherein the keep-alive message sending module is specifically configured to:
placing the second sending time into a keep-alive period node of a time array;
when the second sending time is the minimum value in the time array, adding the second sending time into a small root pile;
and based on the small root stack, after the second sending time is reached, sending the first keep-alive message of any PPP interface.
9. The apparatus of claim 8, wherein the keep-alive message sending module is further configured to add the second sending time to a corresponding position in a node where a keep-alive period of any one PPP interface of the time array is located according to a time array constructed for the node based on the keep-alive period of each PPP interface in order of time values from first to last.
10. The apparatus of claim 8, wherein the keep-alive message sending module is further configured to add the second sending time to the root heap when the second sending time is not the minimum value in the time array, and when the second sending time is the minimum value in the time array; and based on the small root stack, after the second sending time is reached, sending the first keep-alive message of any PPP interface.
11. An electronic device comprising a processor and a memory storing computer readable instructions which, when executed by the processor, perform the steps of the method of any of claims 1-5.
12. A readable storage medium, on which a computer program is stored, characterized in that the computer program, when being executed by a processor, performs the steps of the method according to any of claims 1-5.
CN201811587980.4A 2018-12-24 2018-12-24 Keep-alive message sending method and device, electronic equipment and readable storage medium Active CN111355764B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201811587980.4A CN111355764B (en) 2018-12-24 2018-12-24 Keep-alive message sending method and device, electronic equipment and readable storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201811587980.4A CN111355764B (en) 2018-12-24 2018-12-24 Keep-alive message sending method and device, electronic equipment and readable storage medium

Publications (2)

Publication Number Publication Date
CN111355764A CN111355764A (en) 2020-06-30
CN111355764B true CN111355764B (en) 2023-10-24

Family

ID=71195582

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201811587980.4A Active CN111355764B (en) 2018-12-24 2018-12-24 Keep-alive message sending method and device, electronic equipment and readable storage medium

Country Status (1)

Country Link
CN (1) CN111355764B (en)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113765711B (en) * 2021-08-25 2023-12-26 新华三大数据技术有限公司 Network equipment keep-alive method and device
CN116886755B (en) * 2023-09-08 2023-11-17 安擎计算机信息股份有限公司 Keep-alive method and keep-alive device for tested server

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101094186A (en) * 2007-07-30 2007-12-26 杭州华三通信技术有限公司 Method and interface board of retaining neighbourhood
WO2010083739A1 (en) * 2009-01-21 2010-07-29 华为技术有限公司 Ip session liveness monitoring method and system, home gateway and network equipment
CN102014054A (en) * 2010-11-22 2011-04-13 中兴通讯股份有限公司 Sending method and equipment for keep-alive messages
CN102104531A (en) * 2009-12-17 2011-06-22 华为技术有限公司 Message processing device, method and system
CN102347909A (en) * 2011-11-22 2012-02-08 迈普通信技术股份有限公司 Method and device for sending massive protocol messages
US8156209B1 (en) * 2001-02-15 2012-04-10 Cisco Technology, Inc. Aggregation devices processing keep-alive messages of point-to-point sessions
CN102917408A (en) * 2012-10-26 2013-02-06 迈普通信技术股份有限公司 Downlink flow control method and system of LNS (L2TP network server) device in 3G (third-generation) network
CN106911696A (en) * 2017-02-28 2017-06-30 新华三技术有限公司 A kind of keep Alive Packet transmission method and device
CN107566213A (en) * 2017-08-28 2018-01-09 新华三技术有限公司 A kind of keep-alive detection method and device

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8156209B1 (en) * 2001-02-15 2012-04-10 Cisco Technology, Inc. Aggregation devices processing keep-alive messages of point-to-point sessions
CN101094186A (en) * 2007-07-30 2007-12-26 杭州华三通信技术有限公司 Method and interface board of retaining neighbourhood
WO2010083739A1 (en) * 2009-01-21 2010-07-29 华为技术有限公司 Ip session liveness monitoring method and system, home gateway and network equipment
CN102104531A (en) * 2009-12-17 2011-06-22 华为技术有限公司 Message processing device, method and system
CN102014054A (en) * 2010-11-22 2011-04-13 中兴通讯股份有限公司 Sending method and equipment for keep-alive messages
CN102347909A (en) * 2011-11-22 2012-02-08 迈普通信技术股份有限公司 Method and device for sending massive protocol messages
CN102917408A (en) * 2012-10-26 2013-02-06 迈普通信技术股份有限公司 Downlink flow control method and system of LNS (L2TP network server) device in 3G (third-generation) network
CN106911696A (en) * 2017-02-28 2017-06-30 新华三技术有限公司 A kind of keep Alive Packet transmission method and device
CN107566213A (en) * 2017-08-28 2018-01-09 新华三技术有限公司 A kind of keep-alive detection method and device

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
D. Tsiang ; G. Suwala ; Cisco Systems ; .The Cisco SRP MAC Layer Protocol.IETF rfc2892.2000,全文. *
VPN隧道技术的研究及其实现;李睿;中国优秀硕士学位论文全文数据库 信息科技辑;全文 *

Also Published As

Publication number Publication date
CN111355764A (en) 2020-06-30

Similar Documents

Publication Publication Date Title
CN107332876B (en) Method and device for synchronizing block chain state
CN102685204B (en) Method and equipment for transmitting data resource
CN107979592B (en) Method and device for sending service request message
CN104811459A (en) Processing method, processing device and system for message services and message service system
CN111355764B (en) Keep-alive message sending method and device, electronic equipment and readable storage medium
CN109218126B (en) Method, device and system for monitoring node survival state
CN110460484B (en) Single-node abnormal active recovery method improved based on PBFT algorithm
JP2022034012A (en) Radio link recovery for user equipment
CN104683259A (en) TCP congestion control method and device
CN103167479B (en) Realize that terminal is distant gets killed or the distant methods, devices and systems opened
CN109194521B (en) Flow forwarding method and equipment
CN107707689A (en) A kind of DHCP message processing method, Dynamic Host Configuration Protocol server and gateway device
CN103516766A (en) Method and system of communication between client-side and application server
WO2017000625A1 (en) Dynamic host configuration protocol (dhcp) server management method and apparatus
CN104243473B (en) A kind of method and device of data transmission
CN103731424B (en) A kind of transmission method of network data, apparatus and system
US20200336432A1 (en) Methods for dynamically controlling transmission control protocol push functionality and devices thereof
CN104009961A (en) PPPoE session ID distribution method and equipment thereof
US20220346186A1 (en) Timer for emergency text messages
CN104754760B (en) A kind of Packet Service method for reconstructing and terminal
CN109788520A (en) Method for switching network, AMF and RAN node
CN107302803B (en) A kind of GTP-U tunnel error processing method and processing device
EP3796598A1 (en) Node switching method, network node, network system, and storage medium
CN108924200B (en) Message processing method and device
CN112988891B (en) Method and device for storing blockchain ledger, electronic equipment and storage medium

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant