CN111355764A - 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
CN111355764A
CN111355764A CN201811587980.4A CN201811587980A CN111355764A CN 111355764 A CN111355764 A CN 111355764A CN 201811587980 A CN201811587980 A CN 201811587980A CN 111355764 A CN111355764 A CN 111355764A
Authority
CN
China
Prior art keywords
keep
time
sending
sending time
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.)
Granted
Application number
CN201811587980.4A
Other languages
Chinese (zh)
Other versions
CN111355764B (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

Images

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 first sending time for sending a first keep-alive message of the PPP interface according to the keep-alive period of the PPP interface; judging whether the number of the PPP interfaces needing to send the keep-alive messages in the first sending time in all the PPP interfaces which are successfully negotiated at present exceeds a preset value or not; if the first keep-alive message exceeds a preset value, adjusting the sending time of the first keep-alive message to a second sending time, wherein 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 sending 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 the network server LNS simultaneously processes the sending 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, an apparatus, an electronic device, and a readable storage medium.
Background
With the development of data communication technology, Virtual private networks (VPN for short) have been proposed, which aim to ensure the security of communication by using a public network to implement private communication through a three-layer or two-layer tunnel.
Network tunneling is a key technology for constructing VPNs. The network tunneling technology refers to the transmission of one network protocol by using another network protocol, that is, the existing transparent network information is encapsulated again, so as to ensure the security of network information transmission. It mainly utilizes network tunnel Protocol to implement said function, and includes second Layer tunnel Protocol (L2 Tunneling Protocol, abbreviated as L2TP) and three-Layer tunnel western medicine,
l2TP is commonly used and recognized, especially with the advent of third generation mobile communication technology, to make the L2TP protocol more widely available. The L2TP protocol is a point-to-point PPP based two-layer tunneling protocol. In the VPN constructed by L2TP, there are two types of servers, one is an L2TP Access Concentrator (L2TP Access Concentrator, LAC for short), which is a device attached to the Network and having a PPP end system and L2TP protocol processing capability, the LAC is generally a Network Access Server for providing Network Access services to users, and the other is an L2TP Network Server LNS (L2TP Network Server), which is software on the PPP end system for processing the L2TP protocol Server end portion.
There are two types of connections between the LNS and LAC, one being a tunnel connection which defines an LNS and LAC pair, and the other being a session connection which is multiplexed over the tunnel connection to indicate each PPP session carried over the tunnel connection.
In the practical application process, the LNS supports a lot of client data, such as 1000 sessions, so that the requirements on the performance of processing a lot of session PPP keep-alive and the convergence time by the LNS are higher. In the prior art, when a connection is established between an LAC and an LNS, negotiation is performed first, the negotiation of L2TP includes negotiation of a corresponding PPP protocol, after the negotiation between the LNS and the LAC, two-end devices are triggered to start receiving and sending PPP keep-alive messages, the PPP keep-alive messages are used for enabling the two-end devices to determine whether an opposite side exists, if the LNS periodically sends the PPP keep-alive messages to the LAC, and the LNS does not receive response information returned by the LAC after sending a plurality of PPP keep-alive messages, it is likely that the LAC of the opposite side is offline, and the LNS automatically disconnects the corresponding PPP interface.
However, if the sending and receiving of the keep-alive messages performed by a large number of different PPP interfaces processed by the LNS exceed the processing performance of the LNS, the LNS may not have more processing capability to process the negotiation of the new LAC, so that it is likely to cause a large number of negotiation messages to be repeatedly sent, which causes the session negotiation of L2TP to repeatedly oscillate, and makes the network load with a heavy load more heavy, thereby forming the avalanche effect, but the prior art does not provide a corresponding solution.
Disclosure of Invention
An object of the embodiment of the present application is to provide a keep-alive message sending method, device, electronic device, and readable storage medium.
In a first aspect, an embodiment of the present application provides a keep-alive packet sending method, where the method includes: after any PPP interface is successfully negotiated, calculating first sending time for sending a first keep-alive message of the PPP interface according to the keep-alive period of the PPP interface; judging whether the number of the PPP interfaces needing to send the keep-alive messages in the first sending time in all the PPP interfaces which are successfully negotiated at present exceeds a preset value or not; if the first keep-alive message exceeds a preset value, adjusting the sending time of the first keep-alive message to a second sending time, wherein 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 the PPP interfaces sending the first keep-alive message at the same time is not too large, and the problem of overlarge load caused by the fact that the network server LNS simultaneously processes the sending of a large number of keep-alive messages is solved.
Optionally, the adjusting the sending time of the first keep-alive packet to a second sending time includes: calculating discrete time according to the number of all the PPP interfaces successfully negotiated at present and the number of the PPP interfaces needing to send the keep-alive messages in the first sending time, adding the discrete time to the first sending time to obtain second sending time, and taking the second sending time as the sending time of the first keep-alive message.
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, the second sending time is obtained by adding the first sending time and the obtained discrete time, namely, the time of sending the first keep-alive message by the PPP interface is prolonged, so that the time of sending the PPP interface of 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 packet at the second sending time includes: putting 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 the small root heap; and based on the small root heap, 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 the keep-alive messages sent by each PPP interface through the constructed stub, and the stub has higher performance, so the data processing efficiency of the LNS can be improved.
Optionally, the placing the second sending time into a keep-alive period node of a time array includes: and adding the second sending time to the corresponding position of the node of the keep-alive period of any PPP interface of the time array according to the time array constructed for the node based on the keep-alive period of each PPP interface and the sequence of the time value from small to large.
In the implementation process, the sending time is added into the small root heap according to the time value, so that the LNS can process the sending time of the keep-alive messages sent by each PPP interface through the constructed small root heap, and the data processing efficiency of the LNS can be improved.
Optionally, the sending the first keep-alive packet at the second sending time further includes: when the second sending time is not the minimum value in the time array, adding the second sending time to the small stub when the second sending time is the minimum value in the time array; and based on the small root heap, 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 into the small root heap, so that the number of nodes of the small root heap is reduced, the performance of the small root heap 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 device, where the device includes:
the time calculation module is used for calculating first sending time for sending a 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;
the judging module is used for judging whether the number of the PPP interfaces needing to send the keep-alive messages in the first sending time in all the PPP interfaces which are successfully negotiated at present exceeds a preset value;
the time adjusting 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 needing to send 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 all current successfully negotiated PPP interfaces and the number of PPP interfaces that need to send keep-alive messages in the first sending time, add the discrete time to the first sending time to obtain a 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:
putting 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 the small root heap;
and based on the small root heap, 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 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, in the order of time value first smaller and then larger.
Optionally, the keep-alive message sending module is further configured to add the second sending time to the stub 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 heap, 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, including a processor and a memory, where the memory stores computer-readable instructions, and when the computer-readable instructions are executed by the processor, the steps in the method as provided in the first aspect are executed.
In a fourth aspect, embodiments of the present application provide a readable storage medium, on which a computer program is stored, where the computer program, when executed by a processor, performs the steps in the method as provided in the first aspect.
The embodiment of the application provides a keep-alive message sending method, a device, an electronic device and a readable storage medium, wherein after any PPP interface is successfully negotiated, the first sending time of the first keep-alive message of the PPP interface is calculated according to the keep-alive period of the PPP interface, then whether the number of the PPP interfaces needing to send the keep-alive message in the first sending time in all the PPP interfaces successfully negotiated at present exceeds a preset value is judged, if the number exceeds the preset value, the sending time of the first keep-alive message is adjusted to be second sending time, the second sending time is later than the first sending time, the first keep-alive message is sent in the second sending time, therefore, the number of the PPP interfaces sending the first keep-alive message at the same time is not too many by adjusting the time of sending the first keep-alive message by each PPP interface, the problem of overlarge load caused by the fact that the network server LNS simultaneously processes the sending of a large number of keep-alive messages is solved.
Additional features and advantages of the present application will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by the practice of the embodiments of the present application. The objectives and other advantages of the application may be realized and attained by the structure particularly pointed out in the written description and claims hereof 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 required to be used in the embodiments will be briefly described below, it should be understood that the following drawings only illustrate some embodiments of the present application and therefore should not be considered as limiting the scope, and for those skilled in the art, other related drawings can be obtained from the drawings without inventive effort.
Fig. 1 is a flowchart of a keep-alive message sending method according to an embodiment of the present application;
FIG. 2 is a schematic structural diagram of a small root heap provided by an embodiment of the present application;
FIG. 3 is a schematic structural diagram of a small root heap applied to an embodiment of the present application;
fig. 4 is a block diagram of a keep-alive message sending apparatus 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 technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. The components of the embodiments of the present application, generally described and illustrated in the figures herein, can be arranged and designed in a wide variety of different configurations. Thus, the following detailed description of the embodiments of the present application, presented in the accompanying drawings, is not intended to limit the scope of the claimed application, but is merely representative of selected embodiments of the application. All other embodiments, which can be derived by a person skilled in the art from the embodiments of the present application without making any creative effort, shall fall within the protection scope of the present application.
It should be noted that: like reference numbers and letters refer to like items in the following figures, and thus, once an item is defined in one figure, it need not be further defined and explained in subsequent figures. Meanwhile, in the description of the present application, the terms "first", "second", and the like are used only for distinguishing the description, and are not to be construed as indicating or implying relative importance.
In the prior art, after a negotiation is established between an LNS and an LAC, the LNS allocates a PPP interface to the LAC, where the PPP interface is used for receiving and sending keep-alive messages between the LNS and the LAC, and if the LNS negotiates with multiple LACs, the receive-and-send of the keep-alive messages is processed, if there are thousands of sessions in 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 capability to process the negotiation of a new LAC, and therefore, a large amount of negotiation messages may be repeatedly sent, the processing burden of the LNS is increased again, and the session negotiation of L2TP may repeatedly oscillate, thereby forming an avalanche effect. Therefore, in order to solve the above problem, an 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 is successfully negotiated, calculating first sending time for sending the first keep-alive message of the PPP interface according to the keep-alive period of the PPP interface.
Step S120: and judging whether the number of the PPP interfaces which need to send the keep-alive messages in the first sending time in all the PPP interfaces which are successfully negotiated at present exceeds a preset value.
The LNS may create a large number of PPP interfaces for establishing session connection with the LAC, because the processing of the PPP interfaces by the LNS is one processing, for example, the LAS currently establishes a plurality of PPP interfaces, the LNS sends a keep-alive message to the first PPP interface processing that is established first, and then processes the second PPP interface to send a keep-alive message, because the processing speed of the LNS is fast, it may also be considered as processing all the PPP interfaces simultaneously. Each PPP interface is configured with a corresponding keep-alive message sending period, the keep-alive message sending periods of the plurality of PPP interfaces may be the same or different, and in practical application, the corresponding keep-alive message sending period can be set for each PPP interface according to the requirement.
Therefore, after any PPP interface is successfully negotiated, 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. For example, for one of the PPP interfaces, if the configured keep-alive period is 10s, after the PPP interface successfully negotiates, the first sending time of the PPP interface sending the first keep-alive message is the current system time plus the keep-alive period of 10 s.
In order to reduce the processing pressure caused by the fact that the LNS needs to process the keep-alive messages sent by the plurality of PPP interfaces at the same time, the sending time of the first keep-alive message sent by any PPP interface is adjusted before the first keep-alive message is sent by the PPP interface, and therefore 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 created on the LNS currently, after determining the first sending time of the first keep-alive message sent by the PPP interface that is successfully negotiated currently, then determining whether the number of the PPP interfaces that need to send the keep-alive message in the first sending time among all the PPP interfaces that are successfully negotiated currently exceeds a preset value, that is, first calculating the number of the PPP interfaces that need to send the keep-alive message in the first sending time among the 500 PPP interfaces, since the keep-alive periods of each PPP interface are likely to be set differently, since the times that are successfully negotiated are different, it is likely that a plurality of PPP interfaces will send the keep-alive message in the first sending time, which causes the processing pressure of the LNS.
For example, for any PPP interface successfully negotiated currently, the set keep-alive period is 10s, if the current time is 8:30, the time for any PPP interface successfully negotiated currently 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 successfully negotiated to send the keep-alive message is detected, for example, the time for any PPP interface successfully negotiated currently is checked, the set keep-alive period is 5s, the time for sending the next keep-alive message is 8:35 according to the system record, the time for sending the first keep-alive message is not consistent with the time for sending the first keep-alive message by any PPP interface successfully negotiated currently, the keep-alive period set by the 3 rd PPP interface successfully negotiated is checked to be 8s, but 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 PPP interface successfully negotiated currently, thus, the time for sending the next keep-alive message by all the successfully negotiated PPP interfaces is traversed and obtained one by one, so that the number of the PPP interfaces that need to send the keep-alive message at the first sending time can be counted, and then it is determined whether the number exceeds the preset value, for example, if it is counted that the number of the PPP interfaces that need to send the keep-alive message at the first sending time is 400, since the current processing capability 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, and at this time, if the number exceeds 300, it indicates that the load of the LNS processing the keep-alive is too large, and when the number of the PPP interfaces that need to send the keep-alive message at the first sending time exceeds the preset value, the step S130 is: 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 when the plurality of PPP interfaces transmit the keep-alive messages at the same time, the sending time of the keep-alive messages may be adjusted from the first sending time to a second sending time after the first sending time, for example, if the first sending time for sending the first keep-alive message to any PPP interface that is successfully negotiated currently is 8:40, the first sending time may be adjusted to the second sending time, for example, 8:45, and the first sending time for sending the first keep-alive message to any PPP interface that is successfully negotiated currently is adjusted to the second sending time. In the same way, the PPP interfaces just negotiated 2 are also processed in the same way, that is, if the first sending time for sending the first keep-alive message by the PPP interface just negotiated 2 is 8:32, the number of the PPP interfaces that need to send the keep-alive message in all the PPP interfaces just negotiated 8:32 in the whole system is first determined, and if the number exceeds the preset value, the first sending time for sending the first keep-alive message by the PPP interface just negotiated 2 is adjusted to the second sending time, for example, 8:34, and other PPP interfaces are sequentially processed in this way, so that the number of the PPP interfaces sending the keep-alive message at the same time in all the PPP interfaces does not exceed the preset value. Therefore, the problem of overlarge load caused by the fact that the LNS needs to process 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 messages of the plurality of PPP interfaces is adjusted, the sending time is adjusted to the second sending time, and it should be understood that the second sending time is the time for sending the first keep-alive messages corresponding to each PPP interface, so when the second sending time arrives, the first keep-alive messages can be sent through each PPP interface, if the second sending time of the 1 st PPP interface is 8:30 due, the first keep-alive messages are sent through the 1 st PPP interface, and if the second sending time of the 2 nd PPP interface is 8:40 due, the first keep-alive messages are sent through the 2 nd PPP interface when the second sending time of the 2 nd PPP interface is 8:40 due, so that the corresponding first keep-alive messages can be sent according to the second sending time of each PPP interface in sequence.
Because the time for sending the first keep-alive message by the PPP interface successfully negotiated at present and the time for sending the next keep-alive message by the PPP interface successfully negotiated at present are staggered, therefore, no large number of PPP interfaces need to send keep-alive messages at the same time, the pressure of LNS for processing a large number of keep-alive messages at the same time is reduced, therefore, after the PPP interface after the first keep-alive message is sent 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 at 8:30, if the keep-alive period set by the 1 st PPP interface is 10s, then keep-alive messages sent by the 1 st PPP interface are all sent with 10s as the period, 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 st PPP interface is 8: 50.
Therefore, in the scheme, the time for sending the keep-alive messages by each PPP interface is staggered, so that the number of the PPP interfaces sending the keep-alive messages at the same time is not too large, and the problem of overlarge load caused by the fact that the server LNS simultaneously processes the sending of a large number of keep-alive messages is solved.
In addition, on the basis of the above embodiment, discrete time may be calculated according to the number of all PPP interfaces that have been successfully negotiated currently and the number of PPP interfaces that need to send keep-alive messages in the first sending time, the second sending time is obtained by adding the discrete time to the first sending time, and the second sending time is taken 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, the second sending time is the time after the first sending time passes the discrete time, namely the time of sending the first keep-alive message by the PPP interface is prolonged, so that the time of sending the PPP interface of 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 as follows: the discrete time is ln (the number M of all the PPP interfaces that have successfully negotiated currently + the number P of interfaces that are to send the keep-alive message at the first sending time), or the discrete time is ln (the number M of all the PPP interfaces that have successfully negotiated currently + the number P of interfaces that are to send the keep-alive message at the first sending time) + a first preset value, or the discrete time is ln (the number M of all the PPP interfaces that have successfully negotiated currently + the number P of interfaces that are to send the keep-alive message at the first sending time)/a second preset value, where P is less than or equal to M. Specific values of the first preset value and the second preset value can be set according to actual conditions, such as 1,2,3.
Of course, the above discrete time calculationThe formula is not limited to the above-described calculation method, and may be calculated by itself according to a predetermined rule, for example, discrete time log2(the number M of all the PPP interfaces successfully negotiated at present + the number P of the interfaces which need to send the keep-alive messages in the first sending time), and the like.
It should be noted that the value of the discrete time does not exceed the maximum settable keep-alive period corresponding to the PPP interface, for example, if the maximum settable keep-alive period of the 1 st PPP interface is 10s, the range of the discrete time is 0-10s, which is only that the discrete time is obtained in this way in general, and in a specific practical application process, the corresponding discrete time can also be obtained according to specific requirements.
As an embodiment, in order to improve the performance of LNS processing keep-alive message transmission, sending the first keep-alive message at the second sending time includes: putting 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 the small root heap; and based on the small root heap, 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 property is satisfied:
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, which is a schematic structural diagram of a small root heap, in the small root heap, a node at the topmost end is a root node, and a key value of the root node is the smallest of key values of all heap nodes. In this embodiment, the second sending time of the first keep-alive message sent by the PPP interface that has successfully obtained the current negotiation may be put into the keep-alive period node of the constructed time array.
Specifically, the second sending time may be added 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, where the time values are in a descending order and then in a descending order.
For simplicity of description, taking 5 PPP interfaces as an example, it can be obtained in the above manner that the 5 PPP interfaces are located in the same node of the time array constructed by using the keep-alive periods as nodes because of having the same keep-alive period, and are sorted in time order as follows: 1 st PPP interface: 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, sorting the time values in the time array from small to large, and then constructing a small root heap based on the time array, as shown in fig. 3, where fig. 3 shows the time for sending the keep-alive messages by the PPP interfaces corresponding to the sending period nodes in the small root heap, for example, at the root node, the second sending time at the root node is 8:30, and the value is the value with the earliest time in the small root heap, a timer is provided in the small root heap to detect whether the earliest time of the small root heap expires in real time, if the current time is 8:30, the earliest time in the small root heap is also 8:30, which indicates that the 1 st PPP interface corresponding to 8:30 needs to send the keep-alive messages, and after the time of the 1 st root node is processed, the 8:30 in the small root heap is taken out, and then the keep-alive messages are sent through the 1 st PPP interface. If the keep-alive period set by the 1 st PPP interface is 7s, the time for sending the second keep-alive message by the 1 st PPP interface is 8:37, the stub is updated, the 8:37 is added into the stub again to obtain the stub shown on the right side of the figure 3, the expiration time of the second sending time stored by the root node in the stub is detected again, and then the sending time of the keep-alive message corresponding to each PPP interface in the stub is continuously processed according to the method.
In the above manner, as many PPP interfaces need to construct the stub of many nodes, in the processing process, the stub moves with time, that is, the value of each node is updated, since the performance of stub insertion and deletion can be improved to logN, where N is the number of nodes in the stub, the LNS can process the sending time of each PPP interface sending keep-alive message through the stub, which can improve the processing efficiency of the LNS.
In addition, in order to reduce the number of nodes of the small stub and further improve the performance of the small stub, when the second transmission time is not the minimum value in the time array, and when the second transmission time becomes the minimum value in the time array, the second transmission time may be added to the small stub; and based on the small root heap, after the second sending time is reached, sending the first keep-alive message of any PPP interface.
That is to say, there is a second sending time of the first keep-alive message corresponding to any PPP interface in the time array, the second sending time is not the minimum value of the corresponding keep-alive period node in the time array, the second sending time is added to the keep-alive period node corresponding to the time array according to the size of the time value, when the second sending time of any PPP interface is the minimum value in the time array, the second sending time is added to the stub, and the first keep-alive message of any PPP interface is sent by detecting that the second sending time in the stub arrives.
Certainly, if the number of nodes in the stub is limited, the number of second sending times added to the stub is also limited, if the number of PPP interfaces is 500, the stub with the number of nodes of 500 needs to be established each time, and in the updating process of the stub, it is likely that the values of all the nodes need to be updated, so the stub with the number of nodes as the preset number can be established, that is, the time for sending the keep-alive messages corresponding to the preset number of PPP interfaces is obtained from the 500 PPP interfaces, and if the preset number is 100, the time for sending the keep-alive messages corresponding to the 100 PPP interfaces is all earlier than the time for sending the keep-alive messages by the remaining 400 PPP interfaces. Then, the sending time of sending the keep-alive messages corresponding to the 100 PPP interfaces is added to each node of the stub according to the sequence from morning to evening, that is, the number of the nodes of the stub is 100, and the processing procedure of the stub is the same as that described above, and is not described in detail herein.
Referring to fig. 4, fig. 4 is a block diagram of a keep-alive message sending device 200 according to an embodiment of the present application, where the device includes:
the time calculation module 210 is configured to calculate, according to the keep-alive period of the PPP interface, a first sending time for sending a first keep-alive message of the PPP interface after any PPP interface negotiates successfully;
a determining module 220, configured to determine whether the number of PPP interfaces that need to send keep-alive messages in the first sending time in all current PPP interfaces that have successfully negotiated exceeds a preset value;
a time adjusting module 230, configured to adjust the sending time of the first keep-alive message to a second sending time when the number of PPP interfaces requiring to send keep-alive messages in the first sending time exceeds a preset value, where the second sending time is later than the first sending time;
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 all current successfully negotiated PPP interfaces and the number of PPP interfaces that need to send keep-alive messages in the first sending time, add the discrete time to the first sending time to obtain a 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 240 is specifically configured to:
putting 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 the small root heap;
and based on the small root heap, 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 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, where the time value is in a descending order and then in a ascending order.
Optionally, the keep-alive message sending module 240 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 heap, 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 disclosure, 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 for realizing 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 (e.g., at least one disk memory). Memory 130 may optionally be at least one memory device located remotely from the aforementioned processor. The memory 130 stores computer readable instructions, which when executed by the processor 110, cause the electronic device to perform the method processes described above with reference to fig. 1.
The embodiment of the present application provides a readable storage medium, and when being executed by a processor, the computer program performs the method processes performed by the electronic device in the method embodiment shown in fig. 1.
It is clear to those skilled in the art that, for convenience and brevity of description, the specific working process of the apparatus described above may refer to the corresponding process in the foregoing method, and will not be described in too much detail herein.
To sum up, the embodiment of the present application provides a keep-alive message sending method, apparatus, electronic device and readable storage medium, in the method, after any PPP interface is successfully negotiated, 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, then it is determined whether the number of PPP interfaces that need to send keep-alive messages in the first sending time of all the currently successfully negotiated PPP interfaces exceeds a preset value, if the number exceeds the preset value, the sending time of the first keep-alive message is adjusted to a second sending time, the second sending time is later than the first sending time, the first keep-alive message is sent in the second keep-alive time, and thus, the number of PPP interfaces sending the first keep-alive message at the same time is not too many by adjusting the time for each PPP interface to send the first keep-alive message, the problem of overlarge load caused by the fact that the network server LNS simultaneously processes the sending of a large number of keep-alive messages is solved.
In the embodiments provided in the present application, it should be understood that the disclosed apparatus and method can be implemented in other ways. The apparatus embodiments described above are merely illustrative, and for example, the flowchart and block diagrams in the figures 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 an independent part, or each module may exist separately, or two or more modules may be integrated to form an independent 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 such understanding, the technical solution of the present application or portions thereof that substantially contribute to the prior art may be embodied in the form of a software product stored in a storage medium and including instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute 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), a magnetic disk or an optical disk, and other various media capable of storing program codes.
The above description is only a preferred embodiment of the present application and is not intended to limit the present application, and various modifications and changes may be made by those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the scope of the present application. It should be noted that: like reference numbers and letters refer to like items in the following figures, and thus, once an item is defined in one figure, it need not be further defined and explained in subsequent figures.
The above description is only for the specific embodiments of the present application, but the keep-alive range of the present application is not limited thereto, and any person skilled in the art can easily think of the changes or substitutions within the technical scope disclosed in the present application, and all the changes or substitutions should be covered within the keep-alive range of the present application. Therefore, the keep-alive range of the present application shall be subject to the keep-alive range of the claims.
It is noted that, herein, relational terms such as first and second, and the like may be 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. Also, 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 an … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element.

Claims (12)

1. A keep-alive message sending method is characterized by comprising the following steps:
after any PPP interface is successfully negotiated, calculating first sending time for sending a first keep-alive message of the PPP interface according to the keep-alive period of the PPP interface;
judging whether the number of the PPP interfaces needing to send the keep-alive messages in the first sending time in all the PPP interfaces which are successfully negotiated at present exceeds a preset value or not;
if the first keep-alive message exceeds a preset value, adjusting the sending time of the first keep-alive message to a second sending time, wherein 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 the adjusting the sending time of the first keep-alive message to a second sending time comprises:
calculating discrete time according to the number of all the PPP interfaces successfully negotiated at present and the number of the PPP interfaces needing to send the keep-alive messages in the first sending time, adding the discrete time to the first sending time to obtain second sending time, and taking the second sending time as the sending time of the first keep-alive message.
3. The method according to claim 1 or 2, wherein the sending the first keep-alive message at the second sending time comprises:
putting 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 the small root heap;
and based on the small root heap, after the second sending time is reached, sending the first keep-alive message of any PPP interface.
4. The method of claim 3, wherein placing the second transmission time in a keep-alive period node of a time array comprises:
and adding the second sending time to the corresponding position of the node of the keep-alive period of any PPP interface of the time array according to the time array constructed for the node based on the keep-alive period of each PPP interface and the sequence of the time value from small to large.
5. The method of claim 3, wherein the sending the first keep-alive message at the second sending time further comprises:
when the second sending time is not the minimum value in the time array, adding the second sending time to the small stub when the second sending time is the minimum value in the time array;
and based on the small root heap, after the second sending time is reached, sending the first keep-alive message of any PPP interface.
6. A keep-alive message sending apparatus, comprising:
the time calculation module is used for calculating first sending time for sending a 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;
the judging module is used for judging whether the number of the PPP interfaces needing to send the keep-alive messages in the first sending time in all the PPP interfaces which are successfully negotiated at present exceeds a preset value;
the time adjusting 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 needing to send 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 according to claim 6, wherein the time adjustment module is specifically configured to calculate a discrete time according to the number of all current successfully negotiated PPP interfaces and the number of PPP interfaces that need to send keep-alive messages in 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.
8. The apparatus according to claim 6 or 7, wherein the keep-alive message sending module is specifically configured to:
putting 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 the small root heap;
and based on the small root heap, after the second sending time is reached, sending the first keep-alive message of any PPP interface.
9. The apparatus according to claim 8, wherein the keep-alive message sending module 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, in a descending order and a descending order of time value.
10. The apparatus of claim 8, wherein the keep-alive message sending module is further configured to add the second sending time to the stub 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 heap, 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, said memory storing computer readable instructions which, when executed by said 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 which, when being executed by a processor, carries out the steps of the method according to any one of claims 1 to 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 true CN111355764A (en) 2020-06-30
CN111355764B 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)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113765711A (en) * 2021-08-25 2021-12-07 新华三大数据技术有限公司 Network equipment keep-alive method and device
CN116886755A (en) * 2023-09-08 2023-10-13 安擎计算机信息股份有限公司 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 *
李睿: "VPN隧道技术的研究及其实现", 中国优秀硕士学位论文全文数据库 信息科技辑 *

Cited By (4)

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

Also Published As

Publication number Publication date
CN111355764B (en) 2023-10-24

Similar Documents

Publication Publication Date Title
CN107332876B (en) Method and device for synchronizing block chain state
CN102710554B (en) The service state detection method of distributed information system and distributed information system
CN102404741B (en) Method and device for detecting abnormal online of mobile terminal
CN109391661B (en) Block chain networking method and system for terminal of Internet of things
CN104301161B (en) Computational methods, computing device and the communication system of quality of service index
EP3337093B1 (en) Optimizing information related to a route and/or a next hop for multicase traffic
CN106227780A (en) Automatization&#39;s sectional drawing evidence collecting method of a kind of magnanimity webpage and system
CN107426241B (en) Network security protection method and device
CN106453669A (en) Load balancing method and server
WO2017016084A1 (en) Alarm information notification method and apparatus, and alarm information filtering device
CN111355764A (en) Keep-alive message sending method and device, electronic equipment and readable storage medium
CN106302230B (en) A kind of data transmission method and device
CN108810008B (en) Transmission control protocol flow filtering method, device, server and storage medium
CN106936730A (en) A kind of file transmitting method, TCP agent and TCP Client
CN103167479B (en) Realize that terminal is distant gets killed or the distant methods, devices and systems opened
CN107360012B (en) Link state processing method and network node equipment
CN103188120A (en) Detection method for packet loss of multicast business and device thereof
CN112838989A (en) Data stream management method, network equipment and storage medium
WO2017000625A1 (en) Dynamic host configuration protocol (dhcp) server management method and apparatus
CN108933706B (en) Method, device and system for monitoring data traffic
CN104243473A (en) Data transmission method and device
CN103227733A (en) Topology discovery method and topology discovery system
CN106507507B (en) Wireless mesh network topology structure building system and method
CN106470421A (en) A kind of method and apparatus preventing malicious peer from illegally occupying resources of core network
CN110830295B (en) Equipment management method and system

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