CN102299923B - Session-Receiver register method in Internet performance measurement system - Google Patents

Abstract

The invention discloses a probe registration method in an Internet performance measurement system. The purpose of the present invention is to set up a probe registration method between the control server and probes (Session-Sender and Session-Receiver) on the TWAMP protocol system to ensure the authenticity of the probes, that is, the probes should be The "real" probes recognized by system users, rather than false or counterfeit measurement nodes, maintain the status of the probes through Keepalive information, thereby ensuring the security of the entire measurement system.

Description

A probe registration method in an Internet performance measurement system

technical field

The invention relates to the technical field of the Internet, in particular to a probe registration method in an Internet performance measurement system.

Background technique

The Internet is one of the important infrastructures of the current information network. However, the end-to-end performance of the Internet has always been a major problem for network managers.

With the rapid development of Internet technology and network services, users' demand for network resources has increased unprecedentedly, and networks have become more and more complex. The ever-increasing network users and applications lead to heavy network load and overloading of network equipment, resulting in network performance degradation. This requires extraction and analysis of network performance indicators to improve and improve network performance. Therefore, network performance measurement emerges as the times require. Discover network bottlenecks, optimize network configuration, and further discover potential dangers that may exist in the network, manage network performance more effectively, provide verification and control of network service quality, and quantify, compare and verify service quality indicators of service providers , is the main purpose of network performance measurement.

The Internet is a packetized network, based on TCP/IP technology, addressing and forwarding data packets hop by hop at the network layer. Since the network node of each hop is only responsible for the data forwarding of the node, the nodes are independent of each other, and the current network management system only takes a single node as the management object, so it is difficult for the network manager to obtain the overall picture of the network performance. In this context, network measurement systems are required to actively measure network performance by using the network as a black box in the identity of Internet users.

There are many research projects on network active measurement in the world, such as IEPM, NIMI, NLANRAMP, Surveyor, etc. Among them, the TWAMP (Two Way Active Measurement Protocol) protocol (RFC5357) developed by IETF is one of the more influential methods.

The TWAMP protocol is based on the end-to-end measurement method, that is, the measurement entities are all hosts, and network devices do not participate in the measurement. TWAMP consists of two mutually independent protocols:

TWAMP-Control: used to establish a measurement session, negotiate session parameters (such as packet length, start time, termination time, packet distribution parameters, etc.), start and terminate a measurement session, and obtain measurement results (TCP protocol);

●TWAMP-Test: specifies the format of the measurement message, etc., and is used for the exchange of measurement messages between the measurement nodes (using the UDP protocol).

In order to improve its openness, TWAMP adopts the idea of separating the control protocol from the measurement protocol. That is to say, the control protocol of the actual TWAMP system does not necessarily use TWAMP-Control, but the underlying measurement protocol must use TWAMP-Test, which can ensure both It not only ensures the interoperability of the measurement process, but also enables the measurement nodes using different control protocols to participate in the measurement, reflecting the openness of the measurement.

The TWAMP protocol includes five functional entities:

●Session-Sender: the measurement node that sends the measurement message in the TWAMP-Test session;

●Session-Receiver: the measurement node that receives the measurement message in the TWAMP-Test session;

●Server: a server that manages one or more TWAMP-Test sessions, can be configured for each TWAMP-Test session on each measurement node, and can return the measurement results of each TWAMP-Test session;

●Control-Client: a host, used to initiate a request to establish a TWAMP-Test session, and control the start and termination of the session;

● Fetch-Client: a host, used to initiate a request to obtain the measurement results of the TWAMP-Test session;

The relationship between the five functional entities is shown in Figure 1:

The TWAMP protocol first assumes that the nodes participating in the measurement (Session-Sender and Session-Receiver) are under the control of different controllers. Session-Sender is controlled by Control-Client, and Session-Receiver is controlled by Server. Therefore, Session-Sender and Control-Client Between, and between Session-Receiver and Server can be the control protocol defined by the controller itself, but between Control-Client and Server, and between Fetch-Client and Server can use the public TWAMP-Control protocol, so that It is possible to perform network performance measurements between hosts of different controllers and obtain data through an open interface. At present, some research institutions, such as Aveiro University, have implemented the TWAMP protocol system. In their system, the undecided protocol in the figure also adopts the TWAMP-Control protocol.

Because the TWAMP protocol is based on the end-to-end measurement method and uses ordinary UDP packets, the measurement process is not easy to be perceived and monitored, and can reflect the real business situation of the user; at the same time, security issues are considered in the design, and the protocol content includes Client and Server The authentication and encryption mechanism between Sender and Receiver; in addition, TWAMP also supports small packet measurement, the minimum packet reaches 42 bytes when it is not encrypted, and 60 bytes when it is encrypted. But the TWAMP protocol also has some shortcomings. First, the measurement results only reflect the performance between hosts at the edge of the network, which is not conducive to network Troubleshooting. Second, the protocol itself is very open. It also introduces security issues, such as man-in-the-middle attacks. Therefore, in summary, the TWAMP protocol is a network performance measurement protocol that is more suitable for users.

TWAMP itself is just a communication protocol for measurement types and measurement control parameters between probes and probes, and between probes and servers. If the TWAMP protocol is used in an actual measurement system, the security of the entire system must be considered. The most important It is to ensure the authenticity of the probe, that is, the probe should be a "real" probe recognized by the system user, rather than a false or counterfeit measurement node.

At present, through network search, it is found that no relevant organization or individual has proposed a similar idea to realize the registration mechanism between the probe and the control server in the Internet performance measurement system supporting the TWAMP protocol.

Contents of the invention

The purpose of the present invention is to establish a probe registration method on the control server and probes (Session-Sender and Session-Receiver) on the TWAMP protocol system, so that the entire system can meet the requirements for safety and reliability in the use of the existing network. Require.

In order to meet the above object, the present invention adopts the following technical solutions:

A probe registration method in an Internet performance measurement system, applied to a system including a server and at least one probe, the probe registration method specifically includes:

Step 1, create probe information in the server database, and write the registration information to the local file on the probe side;

Step 2, send a registration connection request to the server;

Step 3, receiving a registration connection request sent from the probe, and obtaining a connection identifier;

Step 4, start the registration thread of the probe according to the connection identifier, and receive the registration message sent by the probe at the specified TCP port;

Step 5, extracting the probe name and password in the registration message sent by the probe;

Step 6, judging whether the probe name and password match the information in the server database, if so, proceed to step 7; if not, proceed to step 8;

Step 7, saving the basic information of the probe of the message to the database;

Step 8: Send a registration reply message to the probe, if the registration is successful, reply with a "successful registration message", and if the registration is unsuccessful, reply with a "registration unsuccessful message";

Step 9, receiving and reading the registration reply message sent by the server;

Step 10, close the connection.

Further, the probe in step 2 sends a registration connection request, specifically:

Step 210, creating a TCP port used for registration;

Step 220, send a connection request to the server through the TCP port;

Step 230, after the connection request is accepted, a registration message is generated according to the registration information file, and a registration request is sent to the server.

Further, after the step 10, it also includes:

Step 11, according to the registration reply message read in step 9, take out the Accept field in it, and this field represents whether the registration is successful. Return the registration result according to the Accept value.

Further, the step 10 is specifically:

Step 10, calling the public module to close the connection.

Further, the meaning of each field of the registration message is set as: message length, message type, probe capability, probe name, password, probe IP address and probe gateway IP address.

Further, after the probe is successfully registered, it also includes:

Step 310, after starting the Keepalive processing thread, empty the server memory table;

Step 320, receiving Keepalive data sent by the probe;

Step 330, read the probe name information in the received keepalive data sent by the probe, and judge whether it is consistent with the probe name in the memory table, if it is consistent, return to step 320, and continue to wait for receiving data ; If inconsistent, store the probe name in the memory table, and return to step 320, and continue to wait for receiving data.

Further, the probe in step 320 sends Keepalive data, specifically:

Step 3201, read keepalive related information, specifically, read the IP address of the server and the information of the keepalive timing interval from the memory;

Step 3202, setting the timer time as the configuration time interval, calling Keepalive to send the code at a fixed time to achieve the purpose of reporting to the online status, when the timing time is up, the thread processing will be automatically started and the process will be transferred to step 3203;

Step 3203, create a UDP port for Keepalive report;

Step 3204, encapsulating the Keepalive packet, and filling in the corresponding information according to the defined Keepalive message;

Step 3205, send the Keepalive data packet, and send the data packet to the server through the UDP port by calling the sending function;

Step 3206, close the Keepalive UDP port.

Further, the meaning of each field of the Keepalive packet message is set as:

Packet length, packet type, probe name.

The invention provides a probe registration method in the Internet performance measurement system, which enables the server and the probe to perform mutual authentication, and realizes the identification and distribution of the authority of the probe by the server. In the present invention, it is necessary to add a processing mechanism for the registration process on the probe and the server. When the probe starts, it registers with the server according to the configuration information, and the server authenticates the registration information to determine the legitimacy of the probe. After registration, the probe will still periodically send keepalive information to the server to maintain the state.

Description of drawings

FIG. 1 is a schematic diagram of the relationship between TWAMP protocol functional entities in the prior art;

Fig. 2 is a schematic diagram of the server-side registration process of the present invention;

Fig. 3 is a schematic diagram of the registration reply message format of the present invention;

Fig. 4 is the server Keepalive processing flow schematic diagram of the present invention;

Fig. 5 is a schematic diagram of the registration process of the probe end of the present invention;

Fig. 6 is a schematic diagram of the format of the probe registration request message of the present invention;

Fig. 7 is a schematic diagram of the Keepalive message format of the present invention;

FIG. 8 is a schematic diagram of the processing flow of the Keepalive thread at the probe end of the present invention.

Detailed ways

In order to make the purpose, technical solution and advantages of the present invention clearer, the present invention will be further described in detail below in conjunction with the accompanying drawings and embodiments. The specific embodiments described here are only used to explain the present invention, but not to limit the present invention. The registration method in the present invention includes the processing flow of both the server and the probe.

As shown in Figure 2, the server-side processing flow includes the following steps:

Step 1. Create probe information in the server database, which includes: probe name, registration password, probe IP address, probe next-hop gateway address, and probe capability description.

Step 2, the server starts, accepts the probe registration connection request, and obtains the connection identifier FD.

Step 3, start the probe registration thread, and wait for the probe registration message at the designated TCP Socket port.

Step 4, if a probe sends a registration request, the registration data is received.

Step 5, extracting the probe name and password in the registration message.

Step 6, compare the probe name and password with the information in the database. If they match, go to step 7; if not, go to step 8.

Step 7, saving the basic information of the probe such as the IP address of the message probe and the probe capability to the corresponding position of the database.

Step 8: Send a registration reply message to the probe. If the registration is successful, reply with a "successful registration message", and if the registration is unsuccessful, reply with a "registration unsuccessful message".

Step 9, close the connection.

As shown in Figure 2, the format of the registration request reply message is as follows:

●Message length: 4 bytes.

●Message type: 2 bytes. 3 stands for probe registration reply.

• Registration Reply: 2 bytes. 0 means that the registration is successful, 1 means that the probe does not exist, 2 means that the probe name does not match the password, 3 means that the IP address or probe capability description is wrong, and 4 means that the probe has been registered.

After the probe is successfully registered, it will periodically send Keepalive messages (UDP) to the server, and the server needs to create a UDP Socket to receive these Keepalive messages. As shown in Figure 4, the server processes the Keepalive message as follows:

Step 310, after starting the Keepalive processing thread, clear the server memory table 1 (memory table 1 stores the state information of the probe).

Step 320, receiving keepalive data.

Step 330, read the probe name information in the received Keepalive data, and match it with the probe name in memory table 1. If it matches, go back to step 320 and continue to wait for receiving data; if not, store the probe name in memory table 1, and go back to step 320 and continue to wait for receiving data.

On the probe side, the administrator first needs to write the registration information into the local file on the probe side. After the probe is started, the registration process will start automatically. As shown in Figure 5, the processing flow includes the following steps:

Step 10, create the TCP Socket used for registration.

Step 20, send a connection request to the server through the TCP Socket.

Step 30, after the connection request is accepted, a registration message is generated according to the registration information file, and the registration request is sent to the server.

Step 40, receiving and reading the registration reply message returned by the server.

Step 50, calling the public module to close the connection.

Step 60, according to the registration reply message read in step 40, take out the Accept field in it, and this field represents whether the registration is successful. Return the registration result according to the Accept value.

As shown in Figure 6, the probe registration request message is as follows:

●Message length: 4 bytes.

●Message type: 2 bytes, 1 represents the probe registration command, 2 represents the timing online command.

●Probe capability: 4 bytes, 32bit.

●Probe name: 32 bytes, the name configured by the user for the probe.

●Password: 32 bytes, the registration password configured by the user for the probe.

● Probe IP address: 256 bytes, the IP address of the probe.

● Probe gateway IP address: 256 bytes, the gateway address of the probe.

After the probe is successfully registered, a keepalive thread will be started to periodically maintain the probe status on the server. As shown in Figure 8, the processing flow of the Keepalive thread on the probe side is as follows:

Step 10, read keepalive related information, you need to read information such as the IP address of the control server, keepalive timing interval, etc. from the memory.

Step 20, set the timer time as the configuration time interval, and call Keepalive to send the code at a fixed time to achieve the purpose of reporting the online status. When the timing time is up, the thread processing will be automatically opened and the process will be forwarded to step 21.

Step 21, create a UDP Socket for Keepalive report.

Step 22, encapsulating the Keepalive data packet, and filling in corresponding information according to the defined Keepalive message.

Step 23, send the Keepalive data packet, and send the datagram to the control server through the UDP port by calling the sending function.

Step 24, close the Keepalive UDP Socket.

The probe side sends keepalive packets using the UDP port. As shown in Figure 7, the meanings of the fields in the Keepalive packet are as follows:

●Message length: 4 bytes.

●Message type: 2 bytes, 2 means timing online command, 1 means probe registration command.

●Probe name: 32 bytes, the name configured by the user for the probe.

Although the present invention has been clearly illustrated by the above embodiments and accompanying drawings, those skilled in the art can make various corresponding changes and modifications according to the present invention without departing from the spirit and essence of the present invention , but these corresponding changes and amendments should all belong to the protection scope of the claims of the present invention.

Claims (7)

1. the probe register method in internet performance measuring system, be applied in the system comprising server and at least one probe, it is characterized in that, described probe register method specifically comprises:

Step 1, creates detecting probe information in server database, and log-on message is write sound end local file;

Step 2, sends registration connection request to server;

Step 3, receives the registration connection request sent from described probe, obtains connection identifier (CID;

Step 4, opens the registration thread of described probe according to described connection identifier (CID, and the logon message of specifying tcp port to receive the transmission of described probe;

Step 5, extracts the probe title in the logon message of described probe transmission and password;

Step 6, judges whether probe title and password mate with information in server database, if so, then enter step 7; If not, then step 8 is entered;

Step 7, is saved in database by the essential information of the probe of described message;

Step 8, sends registration to described probe and replys message, if succeed in registration, then replys " successful registration message ", if register unsuccessful, then replys " registering unsuccessful message ";

Step 9, receive and read server send registration reply message;

Step 10, closes and connects;

Wherein, the probe in described step 2 sends registration connection request, is specially:

Step 210, creates the tcp port registered and use;

Step 220, sends connection request by this tcp port to server end;

Step 230, after connection request accepts, according to log-on message file generated logon message, sends registration request to server.

2. the probe register method in a kind of internet performance measuring system according to claim 1, is characterized in that, also comprise after described step 10:

Step 11, replys message according to the registration of reading in step 9, takes out Accept field wherein, and whether the registration of this field references is successful, returns this registering result according to Accept value.

3. the probe register method in a kind of internet performance measuring system according to claim 1, it is characterized in that, described step 10 is specially:

Step 10, calls public module and closes connection.

4. according to the probe register method in a kind of internet performance measuring system in claim 1-3 described in any one, it is characterized in that, each for described logon message field meanings is set as: message length, type of message, probe capacity, probe title, password, probe I P address and probe gateway ip address.

5. the probe register method in a kind of internet performance measuring system according to claim 1, is characterized in that, also comprise after probe successful registration:

Step 310, after starting Keepalive processing threads, empties server memory table;

Step 320, receives the Keepalive data that probe sends;

Step 330, reads the probe name information in the Keepalive data of the described probe transmission received, and judges whether consistent with the probe title in memory table, if unanimously, then get back to step 320, continue wait-receiving mode data; If inconsistent, by probe name storage in memory table, and get back to step 320, continue wait-receiving mode data.

6. the probe register method in a kind of internet performance measuring system according to claim 5, is characterized in that, the probe in described step 320 sends Keepalive data, is specially:

Step 3201, reads keepalive relevant information, particularly, reads out the IP address of server, the information of keepalive timed interval from internal memory;

Step 3202, the setting timer time is interval setup time, calls Keepalive and sends code, reach the object of presence of reporting for work, then just automatically can open thread process go to step 3203 and manage everywhere when timing by the set time;

Step 3203, creates the udp port of Keepalive report;

Step 3204, encapsulation Keepalive packet, according to defined Keepalive message, inserts corresponding information;

Step 3205, sends Keepalive packet, by calling transmission function, packet is sent to server by udp port;

Step 3206, closes Keepalive udp port.

7. according to the probe register method in a kind of internet performance measuring system described in claim 5 or 6, it is characterized in that, the implication of each field of described Keepalive data packet messages be set as:

Message length, type of message, probe title.