A socket forwarding data monitoring method

Abstract

The application discloses a Socket forwarding data monitoring method, and relates to the communication field, and the method comprises the following steps: performing a receiving operation: receiving 1 byte of return data; then, matching a target packet header template from the received return data based on a sliding matching algorithm; if the matching succeeds, splitting the return data based on the target packet header template to obtain a return data packet and press the return data packet into a receiving queue; otherwise, returning to perform the receiving operation; obtaining the number of return data packets of the receiving queue, determining the state of the receiving queue based on the number of return data packets; if the state is empty, performing a first sending operation based on a preset request data packet sending interval time: sending a request data packet corresponding to the device address to the next target device through a Socket communication mode; taking out the return data packet from the receiving queue to check the legitimacy of the return data packet, and storing the return data packet into a database according to a database table structure when the return data packet is legitimate, so that the accuracy and stability are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of communication, in particular to a Socket forwarding data monitoring method. BACKGROUND

[0002] Network communication is a process of transmitting data, information and instructions between devices through a computer network. Socket communication is one of the application directions of Ethernet communication, and is an abstract mechanism for realizing inter-process communication in a computer network by encapsulating complex TCP / IP protocols into a simple interface between the application layer and the transport layer, and has the characteristics of high compatibility and strong flexibility. The realization of Socket communication provides a new solution for the centralized management, remote control and creation of intelligent and efficient Internet of Things networks of multiple devices in a factory.

[0003] At present, the prior art has designed and implemented a Socket forwarding continuous data monitoring method, which respectively constructs a device communication process and a data processing process, constructs a packaging thread, a sending thread, a receiving thread and a forwarding thread in the device communication process, and constructs a sending thread and a receiving thread in the data processing process. The device communication process and the data processing process communicate through Socket, so as to realize continuous and stable data monitoring of multiple real-time data measurement devices. However, when receiving the returned data packet, the program will receive it byte by byte, and after obtaining the packet header information, it will automatically add the packet header and subsequent elements to the array until the packet header information appears again, that is, batch receiving data. For devices that return data in batches (cannot return data at once or even return data with a phenomenon of sticking together), since these devices cannot return the batch data required by the method at once, the method is in a state of waiting for the return of the batch data of the required length, resulting in a phenomenon of freezing, so that the data stream returned in batches cannot be effectively read and parsed, resulting in a significant decrease in data reading accuracy and stability. SUMMARY

[0004] The purpose of the present application is to provide a Socket forwarding data monitoring method to solve the problem that the existing method cannot effectively read and parse the data stream returned in batches, resulting in a significant decrease in data reading accuracy and stability.

[0005] To achieve the above purpose, the present application provides the following solutions:

[0006] In a first aspect, the present application provides a Socket forwarding data monitoring method, comprising:

[0007] performing a receiving operation: receiving 1 byte of returned data;

[0008] After the receiving operation is executed, a target packet header template is matched from the received return data based on a sliding matching algorithm: if the matching is successful, the return data is segmented based on the target packet header template to obtain a return data packet, and the return data packet is pushed into a receiving queue; otherwise, the receiving operation and subsequent steps are returned to be executed; wherein the target packet header template is a packet header template of a next device address that should be read;

[0009] The number of return data packets in the receiving queue is obtained.

[0010] Based on the number of return data packets, the receiving queue state is determined.

[0011] If the receiving queue state is an empty queue state, a first sending operation is executed based on a preset request data packet sending interval time:

[0012] A request data packet corresponding to a device address is sent to a next target device through a Socket communication mode.

[0013] After receiving a return data packet, the return data packet is taken out from the receiving queue to perform a legality check on the taken return data packet, and when the check result is legal, the return data packet is stored into a database according to a database table structure.

[0014] Optionally, the Socket forwarding data monitoring method further comprises:

[0015] Before the receiving operation is executed, it is detected whether a last packet header template in a packet header template list has been read: if yes, a first packet header template in the packet header template list is re-read, otherwise, a next packet header template in the packet header template list is read as a target packet header template.

[0016] The receiving operation further comprises:

[0017] The received bytes are pushed into a receiving pool list.

[0018] The target packet header template is matched from the read return data based on the sliding matching algorithm: if the matching is successful, the return data is segmented based on the target packet header template to obtain a return data packet, and the return data packet is pushed into the receiving queue; otherwise, the receiving operation and subsequent steps are returned to be executed, specifically comprising:

[0019] It is detected whether the data length of the receiving pool list is less than the length of the target packet header template: if yes, the receiving operation is returned to be executed, otherwise, the receiving pool list is taken as a to-be-matched string, the target packet header template is taken as a substring, and the KMP sliding matching algorithm is used to match the to-be-matched string and the substring from a starting position of the to-be-matched string to calculate a next position that should be matched.

[0020] moving the substring to the next position of the to-be-matched string that should be matched, and cutting the string backward to be consistent with the length of the substring;

[0021] performing a splitting operation:

[0022] sequentially detecting whether the characters in the cut string are completely consistent with the substring: if not, returning to perform the receiving operation and the subsequent steps until the characters in the cut string are completely consistent with the substring; otherwise, pushing the string before the position of the cut string in the receiving pool list as a return data packet into the receiving queue.

[0023] Optionally, the Socket forwarding data monitoring method further comprises:

[0024] if the receiving queue state is a non-full queue state, performing a second sending operation:

[0025] adjusting the request data packet sending interval time based on the number of return data packets of the receiving queue:

[0026] if the number of return data packets is less than a preset warning value, taking the preset request data packet sending interval time as an initial value, and reducing the request data packet sending interval time based on the initial value;

[0027] performing the first sending operation based on the adjusted request data packet sending interval time.

[0028] Optionally, the adjusting the request data packet sending interval time based on the number of return data packets of the receiving queue further comprises:

[0029] if the number of return data packets is equal to a preset warning value, taking the initial value as the request data packet sending interval time;

[0030] if the number of return data packets is greater than a preset warning value, increasing the request data packet sending interval time based on the initial value.

[0031] Optionally, the reducing the request data packet sending interval time based on a preset initial value is performed according to the following formula:

[0032] ;

[0033] ;

[0034] wherein, s is the adjusted request data packet sending interval time, , a minimum data refresh interval of a corresponding target device, x an initial value of a preset request packet sending interval time, a preset alert value, an alert coefficient, w a receiving queue length, k a number of returned data packets, a last transceiving interval, a monotonically increasing binary function.

[0035] Optionally, the request packet sending interval time is increased on the basis of the preset initial value, and the following formula is used:

[0036] ;

[0037] ;

[0038] wherein, s an adjusted request packet sending interval time, , a maximum data refresh interval of a corresponding target device, x an initial value of a preset request packet sending interval time, a preset alert value, an alert coefficient, w a receiving queue length, k a number of returned data packets, a last transceiving interval, a monotonically increasing binary function.

[0039] Optionally, the monotonically increasing binary function is:

[0040] .

[0041] Optionally, the first sending operation further comprises:

[0042] copying a request packet corresponding to a device address in a sending packet list before sending the request packet corresponding to the device address to a next target device through a Socket communication mode, wherein the sending packet list stores request packets corresponding to device addresses of target devices;

[0043] The request packet contains a CRC16 check code.

[0044] Optionally, the Socket forwarding data monitoring method further comprises:

[0045] The returned data packet is subjected to a legality check, and a check result is obtained;

[0046] When the check result is legal, the returned data packet is stored in a database according to a database table structure.

[0047] Optionally, the Socket forwarding data monitoring method further comprises:

[0048] The returned data packet is sent to a server through a Socket communication mode, so that the server performs a legality check on the returned data packet, and a check result is obtained; when the check result is legal, the returned data packet is stored in a database according to a database table structure.

[0049] According to the specific embodiments provided in the application, the following technical effects are disclosed:

[0050] The application provides a Socket forwarding data monitoring method, which comprises the following steps: receiving 1 byte of returned data, and after the receiving operation is performed, matching a target packet header template (a packet header template of a next device address that should be read) from the received returned data based on a sliding matching algorithm; if the matching is successful, the received returned data is segmented based on the target packet header template, and a returned data packet is obtained; otherwise, the receiving operation and the subsequent steps are returned to be performed; since the target packet header template matching operation is performed once for each byte received, and 1 byte of returned data is continuously received when the matching is not successful, the device cannot enter a dead state due to the mismatch between the length of the returned data stream and the demand, and the returned data stream of the device that returns the data in batches can be effectively and completely read; the target packet header template (a packet header template of a next device address that should be read) is matched from the received returned data based on the sliding matching algorithm, and the read returned data is segmented based on the target packet header template, so that the data returned in batches can be received as a returned data packet and subjected to a legality check; when the check result is legal, the returned data packet is stored in a database according to a database table structure, so that the returned data stream of the device that returns the data in batches is effectively parsed; in summary, the application effectively reads and parses the data stream of the device that returns the data in batches, ensures the data reading accuracy and stability of the device that returns the data in batches, and solves the problem that the existing method cannot effectively read and parse the data stream returned in batches, resulting in a significant decrease in data reading accuracy and stability. BRIEF DESCRIPTION OF DRAWINGS

[0051] In order to make the technical solutions in the embodiments of the present application or the prior art clearer, the accompanying drawings needed in the embodiments will be briefly introduced. Obviously, the accompanying drawings in the following description only aim to some embodiments of the present application, and for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0052] Figure 1 An application environment diagram of a Socket forwarding data monitoring method in an embodiment of the present application;

[0053] Figure 2 A flowchart of a Socket forwarding data monitoring method provided in an embodiment of the present application;

[0054] Figure 3 A flowchart of a sending thread provided in an embodiment of the present application;

[0055] Figure 4 A flowchart of a first receiving thread provided in an embodiment of the present application;

[0056] Figure 5 A flowchart of a KMP sliding matching algorithm provided in an embodiment of the present application;

[0057] Figure 6 A flowchart of a KMP sliding matching algorithm provided in another embodiment of the present application;

[0058] Figure 7 A flowchart of a forwarding thread provided in an embodiment of the present application;

[0059] Figure 8 A flowchart of a second receiving thread provided in an embodiment of the present application;

[0060] Figure 9 A flowchart of a writing thread provided in an embodiment of the present application;

[0061] Figure 10 A functional module diagram of a Socket forwarding data monitoring device provided in another embodiment of the present application;

[0062] Figure 11 A structural diagram of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0063] With reference to the drawings and embodiments of the present application, the technical solutions in the embodiments of the present application will be described clearly and completely. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the scope of protection of the present application.

[0064] The above purposes, features and advantages of the present application will be more apparent and understandable. The present application will be further described in detail below with reference to the drawings and specific embodiments.

[0065] The Socket forwarding data monitoring method provided by the embodiments of the present application can be applied to an application environment as shown in Figure 1 The terminal 102 communicates with the server 104 through Ethernet. The data storage system can store data required to be processed by the server 104. The data storage system can be separately arranged, integrated on the server 104, or placed on the cloud or other servers. The terminal 102 can send a return data packet to be processed to the server 104. After receiving the return data packet to be processed, the server 104 performs a legality check on the return data packet to be processed, obtains a check result, and when the check result is legal, stores the return data packet in the data storage system according to the database table structure. In addition, in some embodiments, the Socket forwarding data monitoring method can also be implemented by the server 104 alone, for example, the terminal 102 can directly perform a legality check on the return data packet to be processed, obtain a check result, and when the check result is legal, store the return data packet in the database according to the database table structure.

[0066] The terminal 102 can be, but is not limited to, various desktop computers, notebook computers, smart phones, tablet computers, Internet of Things devices, and portable wearable devices. The Internet of Things device can be a smart speaker, a smart television, a smart air conditioner, a smart vehicle device, etc. The portable wearable device can be a smart watch, a smart bracelet, a head-mounted device, etc. The server 104 can be implemented by an independent server or a server cluster composed of multiple servers, and can also be a cloud server.

[0067] In an exemplary embodiment, as shown in Figure 2 A Socket forwarding data monitoring method is provided, which is executed by a computer device, specifically, can be executed by a terminal or the like computer device alone, or can be executed by a terminal and a server together. In the embodiments of the present application, the terminal 102 in Figure 1 is taken as an example to illustrate the method, which includes the following steps 201 to 206. Wherein:

[0068] Step 201, performing a receiving operation: receiving 1 byte of return data.

[0069] Step 202, after performing the receiving operation, matching a target packet header template from the received return data based on a sliding matching algorithm: if the matching is successful, segmenting the received return data based on the target packet header template to obtain a return data packet, and pushing the return data packet into a receiving queue; otherwise, returning to perform the receiving operation and the subsequent steps; wherein the target packet header template is a packet header template of a next device address that should be read.

[0070] Step 203, obtaining the number of return data packets in the receiving queue.

[0071] Step 204, determining the receiving queue state based on the number of return data packets.

[0072] Step 205, if the receiving queue state is an empty queue state, performing a first sending operation based on a preset request data packet sending interval time: sending a request data packet corresponding to a device address to a next target device through a Socket communication mode.

[0073] In the embodiment of the application, if the number of return data packets in the receiving queue is 0, it indicates that the receiving queue state is an empty queue state, otherwise, it indicates that the receiving queue state is a non-empty queue state.

[0074] The first sending operation is performed based on the preset request data packet sending interval time, that is, the sending interval time of adjacent two request data packets is the preset request data packet sending interval time when the first sending operation is performed.

[0075] The request data packet corresponding to the device address is sent to the next target device, that is, the request data packet with the same device address as the next target device is sent to the next target device.

[0076] Step 206, after receiving the return data packet, taking out the return data packet from the receiving queue to perform a legality check on the taken-out return data packet to obtain a check result, and storing the taken-out return data packet into a database according to a database table structure when the check result is legal.

[0077] In the embodiment of the application, the legality check is performed on the taken-out return data packet, that is, whether the taken-out return data packet meets the requirements of the used communication protocol is checked.

[0078] The steps 201-206 are implemented, and by performing the receiving operation: receiving 1 byte of return data, and after performing the receiving operation, matching the target packet header template (the packet header template of the next device address that should be read) from the received return data based on the sliding matching algorithm, if the matching is successful, then based on the target packet header template, the received return data is segmented to obtain the return data packet; otherwise, the receiving operation and the subsequent steps are returned to perform. Since each byte received is matched with the target packet header template, when it does not match, 1 byte of return data is continuously received, so there is no problem of mismatching the length of the return data stream and the demand, so it will not enter a dead state, and it can effectively and completely read the return data stream of the device that returns data in batches. By matching the target packet header template (the packet header template of the next device address that should be read) from the received return data based on the sliding matching algorithm, and based on the target packet header template, the read return data is segmented to obtain the return data packet, the data returned in batches can be received as a return data packet and checked for legality, and when the check result is legal, the return data packet is stored in the database according to the database table structure, thereby realizing effective parsing of the return data stream of the device that returns data in batches. In summary, the present application realizes effective reading and parsing of the data stream of the device that returns data in batches, ensures the accuracy and stability of data reading of the device that returns data in batches, and solves the problem that the existing method cannot effectively read and parse the data stream returned in batches, resulting in a significant decrease in data reading accuracy and stability.

[0079] In another exemplary embodiment of the present application, as shown in Figure 4 The above-mentioned Socket forwarding data monitoring method further comprises:

[0080] Before step 201, it is detected whether the last packet header template in the packet header template list has been read: if so, the first packet header template in the packet header template list is re-read, otherwise, the next packet header template in the packet header template list is read as the target packet header template.

[0081] For example, as shown in Figure 5 For a single address case, there is only one address "01", and there is only one packet header template "01 04 1C" in the packet header template list, so the packet header template "01 04 1C" is repeatedly read as the target packet header template each time. For example, as shown in Figure 6As shown, in the case of multiple addresses, with addresses "01", "02", and "03", the header templates in the header template list are "01 04 1C", "02 04 1C", and "03 04 1C" respectively. If the last header template "03 04 1C" in the header template list has been read, then the first header template "01 04 1C" in the header template list is read again as the target header template. If the last header template "03 04 1C" in the header template list has not been read initially, then the next header template "02 04 1C" after "01 04 1C" is read as the target header template, and the next header template "03 04 1C" after "02 04 1C" is read as the target header template.

[0082] In another exemplary embodiment of this application, the above-described receiving operation further includes:

[0083] Push the received bytes into the receive pool list.

[0084] In another exemplary embodiment of this application, such as Figure 4 As shown, step 202 specifically includes steps 301 to 303. Wherein:

[0085] Step 301: Check if the length of the data in the receiving pool list is less than the length of the target header template. If it is less, return to execute the receiving operation. Otherwise, use the receiving pool list as the string to be matched and the target header template as the substring. Starting from the beginning of the string to be matched, use the KMP sliding matching algorithm to match the substring and calculate the next position to be matched, i.e., the next value.

[0086] Step 302: Move the substring to the next position where the string to be matched should be matched, and then extract a substring with the same length as the substring.

[0087] Step 303, perform the segmentation operation: sequentially check whether the characters in the truncated string are completely identical to the substring; if they are not completely identical, return to perform the receiving operation and subsequent steps until the characters in the truncated string are completely identical to the substring; otherwise, push the string in the receiving pool list that is located before the position of the truncated string into the receiving queue as a return data packet.

[0088] For example, such as Figure 5 As shown, in the case of a single address, there is only address "01" and the target packet header template is "01 041C". The string before "01 04 1C" in the matched receive pool list is pushed into the receive queue as a return data packet.

[0089] For example, such as Figure 6As shown, the target packet header template is "02 04 1C", "03 04 1C", and "01 04 1C" in turn, and the string before "02 04 1C", "03 04 1C", and "01 04 1C" in the received pool list that is matched in turn is pressed into the receiving queue as a return data packet.

[0090] The existing Socket forwarding data monitoring method uses a sliding string data stream matching algorithm to match the packet header when receiving a return data packet. If the data packet length is large, multiple invalid comparisons will occur, thereby reducing the running efficiency of the algorithm. The KMP sliding matching is used to realize packet header matching in the embodiment of the application. Since the KMP sliding matching can calculate the position of the next matching in real time, the number of unnecessary matching times is effectively reduced, and the matching efficiency is improved. Therefore, the KMP sliding matching is used to receive a return data packet, and the Socket forwarding data monitoring based on KMP sliding matching is realized. Compared with the prior art, the KMP sliding matching significantly reduces the algorithm time complexity, can quickly match the packet header in a large length data packet and return the position, thereby improving the running efficiency of the Socket forwarding data monitoring method.

[0091] In another exemplary embodiment of the application, the above-mentioned Socket forwarding data monitoring method further comprises:

[0092] After the return data packet is pressed into the receiving queue, the receiving operation and the subsequent steps are executed.

[0093] In another exemplary embodiment of the application, the time consumed when using the KMP sliding matching algorithm and the ordinary character matching algorithm is experimented. The experimental environment is as follows: operating system: Galaxy Kylin V10 SP1, software environment: Python3.9.10, Qt 5.12.12, processor: Phytium D2000 (Feiteng D2000).

[0094] In this experiment, a specific length of pattern character and a to-be-matched string are set. When the to-be-matched string is 448, the pattern string is set to 32, 36, and 53 respectively; when the to-be-matched string is 520, the pattern string is set to 32, 72, and 80 respectively; and when the to-be-matched string is 896, the pattern string is set to 53, 106, and 159 respectively. The running time of using the KMP algorithm and not using the KMP algorithm is verified, and the average value of 10 running results is taken. The results are shown in Tables 1 to 3.

[0095] Table 1 Running time of each algorithm when the length of the pattern string is 448 (unit: ms)

[0096]

[0097] Table 2 Running time of each algorithm when the length of pattern string is 520 (unit: ms)

[0098]

[0099] Table 3 Running time of each algorithm when the length of pattern string is 896 (unit: ms)

[0100]

[0101] As can be seen from the above three tables, the KMP algorithm shows good running performance when matching a large amount of data. When the to-be-matched string is 448, the running time is shortened by 0.061 ms compared with the original algorithm; when the to-be-matched string is 520, the running time is shortened by 0.043 ms compared with the original algorithm; and when the to-be-matched string is 896, the running time is shortened by 0.334 ms compared with the original algorithm. The 1024-channel and 2048-channel analyzers of our company return 4K and 8K byte quantities within 1 second, and need to perform data packet cutting in the data stream, and thus are more suitable for this acquisition method.

[0102] In another exemplary embodiment of the present application, as shown in Figure 3 the first sending operation further includes:

[0103] Step 2051, after sending the request data packet corresponding to the device address to the next target device through the Socket communication mode, record the time interval between sending the request data packet corresponding to the device address to the next target device and receiving the corresponding return data, that is, record the last time interval between sending and receiving.

[0104] In another exemplary embodiment of the present application, as shown in Figure 3 the Socket forwarding data monitoring method further includes:

[0105] Step 207, if the receiving queue state is a non-full queue state, perform a second sending operation:

[0106] Adjusting the request data packet sending interval time based on the number of return data packets of the receiving queue, specifically including:

[0107] Step 401, if the number of return data packets is less than a preset warning value, take the preset request data packet sending interval time as an initial value, and reduce the request data packet sending interval time based on the initial value.

[0108] In the embodiment of the present application, if the number of return data packets of the receiving queue is the length value of the receiving queue, it indicates that the receiving queue state is a full queue state. If the number of return data packets of the receiving queue is greater than 0 and less than the length value, the receiving queue state is a non-full queue state.

[0109] The preset request data packet sending interval time is the time interval between the sending of a request data packet and the receiving of a corresponding return data packet when the receiving queue state is empty.

[0110] At step 208, the first sending operation is performed based on the adjusted request data packet sending interval time.

[0111] In the embodiment of the present application, if the number of return data packets is less than the preset warning value, it means that the receiving queue can receive a large number of return data packets. At this time, the speed of sending request data packets is increased by reducing the request data packet sending interval time based on the initial value of the preset request data packet sending interval time, thereby increasing the speed of receiving return data packets and improving the efficiency of data forwarding detection.

[0112] The warning value is not specifically limited and can be set according to actual needs, for example, the warning value is set to two-thirds of the length of the receiving queue.

[0113] In another exemplary embodiment of the present application, the Socket forwarding data monitoring method further includes the following steps:

[0114] After the first sending operation is performed, the step 203 of obtaining the number of return data packets of the receiving queue and the subsequent steps are performed.

[0115] In another exemplary embodiment of the present application, the step 207 of adjusting the request data packet sending interval time based on the number of return data packets of the receiving queue further includes the following steps 402 to 403. Wherein:

[0116] At step 402, if the number of return data packets is equal to the preset warning value, the initial value is taken as the request data packet sending interval time.

[0117] In the embodiment of the present application, if the number of return data packets is equal to the preset warning value, it means that the speed of receiving return data packets needs to be reduced. Therefore, the initial value is taken as the request data packet sending interval time when the number of return data packets is equal to the preset warning value, so as to ensure that the request data packet sending interval time is increased based on the initial value subsequently.

[0118] At step 403, if the number of return data packets is greater than the preset warning value, the request data packet sending interval time is increased based on the initial value.

[0119] In the embodiment of the present application, if the number of return data packets is greater than the preset warning value, it means that the speed of receiving return data packets needs to be reduced, which can avoid the congestion caused by the too fast speed of receiving return data packets.

[0120] In another exemplary embodiment of the present application, a binary function is defined for adjusting the request packet sending interval time In order to ensure that the request packet sending interval time remains at a preset initial value when the request packet sending interval time is adjusted s , the adjusted request packet sending interval time is defined as:

[0121] ; (1)

[0122] which needs to be monotonically increasing and needs to satisfy:

[0123] ; (2)

[0124] ; (3)

[0125] wherein, s the adjusted request packet sending interval time, , is the minimum data refresh interval of the corresponding target device, x is a preset request packet sending interval time, is a preset warning value, is a warning coefficient, w is the length of the receiving queue, k is the number of returned data packets, is the last time interval between transmission and reception (i.e., the last time interval between transmission and reception recorded by step 2051).

[0126] In the embodiment of the present application, step 401 above reduces the request packet sending interval time on the basis of the initial value according to formula (1) and formula (2).

[0127] Step 403 above increases the request packet sending interval time on the basis of the initial value according to formula (1) and formula (3).

[0128] In another exemplary embodiment of the present application, a binary function shown in formula (4) is designed according to formula (1)-(3) :

[0129] ; (4)

[0130] and further obtained as:

[0131] ; (5)

[0132] wherein, sthe adjusted request packet sending interval time, , the minimum data refresh interval of the corresponding target device;

[0133] ; (6)

[0134] wherein, , the maximum data refresh interval of the corresponding target device.

[0135] In the embodiment of the present application, the step 401 reduces the request packet sending interval time based on the initial value according to the above formula (5).

[0136] The step 403 increases the request packet sending interval time based on the initial value according to the above formula (6).

[0137] In another exemplary embodiment of the present application, the first sending operation further comprises, before sending the request packet with the corresponding device address to the next target device through the Socket communication mode:

[0138] Step 2042, copying the request packet with the corresponding device address in the sending packet list, and the request packet contains the CRC16 check code.

[0139] In the embodiment of the present application, the sending packet list stores the request packet corresponding to the device address of each target device.

[0140] In another exemplary embodiment of the present application, the influence of the repeated calculation process of the CRC16 verification on the algorithm itself is verified, and two experiments are set up, one of which generates all request packets containing CRC16 check before sending the request packet through the Socket, and the other generates all request packets containing CRC16 check when sending. The data packet is processed in the byte array mode, and the running time of the two methods when the byte length is 100, 200, and 300 is calculated respectively. The experimental results are shown in Table 4.

[0141] Table 4 CRC cycle check experiment running time (unit: ms)

[0142]

[0143] As can be seen from Table 4, pre-generating all request packets containing CRC16 check can effectively reduce the repeated calculation process in the algorithm running process, save a lot of performance overhead, and reduce the time by about 0.7 ms.

[0144] In another exemplary embodiment of the present application, the Socket forwarding data monitoring method further comprises:

[0145] Step 209, legitimacy check is performed on the extracted return data packet, and a check result is obtained.

[0146] Step 2010, when the check result is legitimate, the legitimate return data packet is stored in the database according to the database table structure.

[0147] In another exemplary embodiment of the present application, the Socket forwarding data monitoring method further comprises:

[0148] Step 501, the extracted return data packet is sent to the server through the Socket communication mode, so that the server performs legitimacy check on the return data packet, and obtains a check result. When the check result is legitimate, the legitimate return data packet is stored in the database according to the database table structure.

[0149] In another exemplary embodiment of the present application, the step 209 specifically comprises the following steps 2091 to 2094. Among them:

[0150] Step 2091, verify whether the length of the extracted return data packet meets the data packet length requirement.

[0151] Step 2092, if the length of any return data packet meets the data packet length requirement, parse the return data packet, otherwise, discard the return data packet.

[0152] Step 2093, verify whether the parsed value of each return data packet meeting the data packet length requirement meets the communication protocol used.

[0153] Step 2094, if the parsed value of any return data packet meeting the length requirement meets the communication protocol used, the return data packet check result is legitimate, otherwise, discard the return data packet meeting the length requirement.

[0154] In another exemplary embodiment of the present application, the Socket forwarding data monitoring method is implemented by multi-process technology, specifically, comprising a communication process and a processing process. The communication process sends the return data packet to the processing process through the Socket communication mode.

[0155] Specifically, the communication process includes three parts of sending thread, first receiving thread and forwarding thread, and uses five data structures of device address list, sending packet list, packet header template list, receiving pool list and receiving queue. The device address list is used to store the device addresses of each target device, and the sending packet list is used to store the request data packets of each target device generated in advance. The packet header template list is used to store the packet header templates of each device address composed of bytes. The receiving pool list is used to store the return data read by bytes. The receiving queue is used to store the return data packet.

[0156] The sending thread is used to continuously send request data packets to each target device. For example... Figure 3 As shown, before the program loop of the sending thread starts, the enabled device address (i.e., the device address of each target device) is read, and a request data packet (including the CRC16 checksum at the end of the packet) is generated according to the specified communication protocol format for the corresponding device address. At the start of the sending thread's program loop, the loop flag variable is checked. If it is false, the loop is exited; if it is true, the loop begins: the length of the receive queue (i.e., the number of returned data packets in the receive queue) is checked, and it is determined whether the receive queue is empty. If empty, the preset request data packet sending interval is used as the current interval, and based on the current interval, a request data packet corresponding to the device address is sent to the next target device via Socket communication. Otherwise, it is determined whether the receive queue is full. If so, it waits until the receive queue is empty. If not full, it verifies whether the number of returned data packets in the receive queue has reached a warning value. If so, the request data packet sending interval is increased, and the increased interval is used as the current interval. The process returns to execute the step of sending the request data packet corresponding to the device address to the next target device via Socket communication based on the current interval. If not, the interval is decreased, and the decreased interval is used as the current interval. The process returns to execute the step of sending the request data packet corresponding to the device address to the next target device via Socket communication based on the current interval.

[0157] The first receiving thread is used to store the return data from each target device. For example... Figure 4As shown, before the program loop of the first receiving thread starts: read the enabled device address (i.e. the device address of the target device) from the database, generate a packet header template corresponding to the device address in the format of the established communication protocol, and push the generated packet header template into the packet header template list; verify whether the Socket connection (i.e. the Socket connection between the terminal 102 and each target device) is valid, and if not, end the program, and if so, generate an empty receiving pool list. At the start of the program loop of the first receiving thread, detect whether the sending loop flag variable is true, and if not, jump out of the loop, and if so, detect whether the last packet header template in the packet header template list has been read, and if so, re-read the first packet header template in the packet header template list, and if not, read the next packet header template in the packet header template list, and perform a receiving operation: receive 1 byte of return data and push the read byte into the receiving pool list, detect whether the data length of the receiving pool list is less than the target packet header template length: if so, return to perform the receiving operation, and if not, take the receiving pool list as a to-be-matched string, take the target packet header template as a substring, use the KMP sliding matching algorithm to match the substring from the start position of the to-be-matched string, calculate the next matching position (i.e. the next value), move the substring to the next matching position of the to-be-matched string, and cut off a string with a length consistent with the substring length, perform a splitting operation: detect whether the characters in the cut-off string are completely consistent with the substring: if not, return to perform the receiving operation and the subsequent steps until the characters in the cut-off string are completely consistent with the substring; otherwise, push the string in the receiving pool list located before the position of the cut-off string into the receiving queue as a return data packet, and then return to perform the detection of whether the last packet header template in the packet header template list has been read and the subsequent steps.

[0158] The forwarding thread is used to take out the return data packet in the receiving queue and forward the taken return data packet to the processing process through the Socket communication mode. As shown, Figure 7 As shown, before the program loop of the first receiving thread starts: read the enabled device address (i.e. the device address of the target device) from the database, generate a packet header template corresponding to the device address in the format of the established communication protocol, and push the generated packet header template into the packet header template list; verify whether the Socket connection (i.e. the Socket connection between the terminal 102 and each target device) is valid, and if not, end the program, and if so, generate an empty receiving pool list. At the start of the program loop of the first receiving thread, detect whether the sending loop flag variable is true, and if not, jump out of the loop, and if so, detect whether the last packet header template in the packet header template list has been read, and if so, re-read the first packet header template in the packet header template list, and if not, read the next packet header template in the packet header template list, and perform a receiving operation: receive 1 byte of return data and push the read byte into the receiving pool list, detect whether the data length of the receiving pool list is less than the target packet header template length: if so, return to perform the receiving operation, and if not, take the receiving pool list as a to-be-matched string, take the target packet header template as a substring, use the KMP sliding matching algorithm to match the substring from the start position of the to-be-matched string, calculate the next matching position (i.e. the next value), move the substring to the next matching position of the to-be-matched string, and cut off a string with a length consistent with the substring length, perform a splitting operation: detect whether the characters in the cut-off string are completely consistent with the substring: if not, return to perform the receiving operation and the subsequent steps until the characters in the cut-off string are completely consistent with the substring; otherwise, push the string in the receiving pool list located before the position of the cut-off string into the receiving queue as a return data packet, and then return to perform the detection of whether the last packet header template in the packet header template list has been read and the subsequent steps.

[0159] The processing process is used to obtain the return data packet sent by the communication process and write it into the database after parsing. The processing process includes two parts: the second receiving thread and the writing thread, and uses a data structure of the processing queue.

[0160] The second receiving thread is used to acquire the real-time data packet sent by the communication thread through the Socket mode and to push it into the processing queue. As shown in Figure 8 , before the program loop of the second receiving thread starts, it is detected whether the Socket connection is valid. If not, the program ends. If yes, it is detected whether the loop flag variable is true. If not, the loop is exited. If yes, all data packets sent by the communication process are received, and it is verified whether the length of the received data packet meets the data packet length requirement. If not, the data packet is automatically discarded, and the subsequent step of detecting whether the loop flag variable is true is returned. If yes, the data packet meeting the data packet length requirement is pushed into the processing queue, and the subsequent step of detecting whether the loop flag variable is true is returned.

[0161] The writing thread is used to read the data in the data packet of the processing queue, parse it into bytes, and write it into the database. As shown in Figure 9 , before the program loop of the writing thread starts, it is detected whether the loop flag variable is true. If not, the loop is exited. If yes, it is detected whether the processing queue is empty. If yes, it is waited and the subsequent step of detecting whether the loop flag variable is true is returned. If not, the head element in the processing queue is taken out, parsed according to the regulation (converted into the corresponding data type), and it is verified whether the parsed data meets the communication protocol regulation (for example, the parsed data value range exceeds the value range specified in the communication protocol). If yes, it is written into the database. If not, the data packet with the parsed data not meeting the communication protocol regulation is discarded, and the subsequent step of detecting whether the processing queue is empty is returned. After writing into the database, it is detected whether the writing is successful. If yes, the subsequent step of detecting whether the processing queue is empty is returned. If not, the data packet with the writing not successful is discarded, and the subsequent step of detecting whether the processing queue is empty is returned.

[0162] The loop flag refers to a switch quantity for controlling whether the receiving thread starts. If true, the program flow of each thread starts. If false, the program flow of each thread is closed. Since the Socket forwarding data monitoring method of the embodiment of the present application is performed in multiple threads, the overall multiple threads need to be centrally controlled to avoid the program not being completely closed due to residual threads not being ended, which affects the next program start and system performance. Therefore, a flag variable is set to control all threads at one time and ensure that the program is completely ended at one time.

[0163] In another exemplary embodiment of the present application, as shown in Figure 3 , the sending thread further includes:

[0164] Before the request data packet of the corresponding device address is sent to the next target device through the Socket communication mode based on the current interval time, the request data packet of the corresponding device address is copied from the sending packet list.

[0165] In another exemplary embodiment of the present application, as shown in Figure 3 The sending thread further includes:

[0166] After sending the request data packet of the corresponding device address to the next target device through the Socket communication mode based on the current interval time, the time interval between sending the request data packet of the corresponding device address to the next target device and receiving the corresponding return data is recorded, i.e., the last time interval between sending and receiving is recorded.

[0167] Based on the same inventive concept, the present application also provides a Socket forwarding data monitoring device for implementing the above-mentioned Socket forwarding data monitoring method. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme described in the above method, so the specific limitations in one or more Socket forwarding data monitoring device embodiments provided below can refer to the limitations of the Socket forwarding data monitoring method in the foregoing, which will not be described here again.

[0168] In an exemplary embodiment, as shown in Figure 10 A Socket forwarding data monitoring device 60 is provided, comprising:

[0169] The receiving module 601 is configured to:

[0170] perform a receiving operation: receiving 1 byte of return data;

[0171] After performing the receiving operation, a target packet header template is matched from the received return data based on a sliding matching algorithm: if the matching is successful, the return data is segmented based on the target packet header template to obtain a return data packet, and the return data packet is pushed into the receiving queue; otherwise, the receiving operation and the subsequent steps are returned to be performed; wherein the target packet header template is a packet header template of the next device address that should be read;

[0172] The state determining module 602 is configured to:

[0173] obtain the number of return data packets in the receiving queue;

[0174] determine the receiving queue state based on the number of return data packets;

[0175] The sending module 603 is configured to, if the receiving queue state is empty, perform a first sending operation based on a preset request data packet sending interval time:

[0176] send a request data packet of the corresponding device address to the next target device through the Socket communication mode;

[0177] The processing module 604 is configured to:

[0178] After receiving the return data packet, the return data packet is taken out from the receiving queue to perform a legitimacy check on the taken return data packet, to obtain a check result, and when the check result is legitimate, the return data packet is stored into a database according to a database table structure.

[0179] In another example embodiment of the present application, the receiving module 601 is further configured to:

[0180] Before performing the receiving operation, it is detected whether the last packet header template in the packet header template list has been read: if yes, the first packet header template in the packet header template list is re-read, otherwise, the next packet header template in the packet header template list is read as the target packet header template;

[0181] The received bytes are pushed into the receiving pool list;

[0182] It is detected whether the data length of the receiving pool list is less than the length of the target packet header template: if yes, the receiving operation is returned to be performed, otherwise, the receiving pool list is taken as a to-be-matched string, the target packet header template is taken as a substring, and the KMP sliding matching algorithm is used to match the to-be-matched string and the substring from the start position of the to-be-matched string to calculate the next position that should be matched;

[0183] The substring is moved to the next position that should be matched of the to-be-matched string and a string with a length consistent with the substring is cut back;

[0184] The splitting operation is performed:

[0185] Characters in the cut string are sequentially detected to see whether they are completely consistent with the substring: if not completely consistent, the receiving operation and the subsequent steps are returned to be performed until the characters in the cut string are completely consistent with the substring; otherwise, a string in the receiving pool list located before the position of the cut string is taken as a return data packet and is pushed into the receiving queue.

[0186] In another example embodiment of the present application, the sending module 603 is further configured to:

[0187] After sending the request data packet of the corresponding device address to the next target device through the Socket communication mode, a time interval between sending the request data packet of the corresponding device address to the next target device and receiving the corresponding return data is recorded, i.e., the last time interval between sending and receiving is recorded.

[0188] In another example embodiment of the present application, the sending module 603 is further configured to:

[0189] If the receiving queue state is a non-full queue state, a second sending operation is performed:

[0190] Based on the number of returned data packets of the receiving queue, the request data packet sending interval time is adjusted;

[0191] Based on the adjusted request data packet sending interval time, the first sending operation is performed;

[0192] The second sending operation specifically includes:

[0193] If the number of returned data packets is less than a preset warning value, a preset request data packet sending interval time is taken as an initial value, and the request data packet sending interval time is reduced based on the initial value.

[0194] In another exemplary embodiment of the present application, the sending module 603 is further configured to:

[0195] If the number of returned data packets is equal to the preset warning value, the initial value is taken as the request data packet sending interval time.

[0196] If the number of returned data packets is greater than the preset warning value, the request data packet sending interval time is increased based on the initial value.

[0197] In another exemplary embodiment of the present application, the sending module 603 is further configured to:

[0198] According to the above formula (1) and formula (2), the request data packet sending interval time is reduced based on the initial value of the preset request data packet sending interval time.

[0199] In another exemplary embodiment of the present application, the sending module 603 is further configured to:

[0200] According to the above formula (1) and formula (3), the request data packet sending interval time is increased based on the initial value of the preset request data packet sending interval time.

[0201] In another exemplary embodiment of the present application, the sending module 603 is further configured to:

[0202] According to the above formula (5), the request data packet sending interval time is reduced based on the initial value of the preset request data packet sending interval time.

[0203] In another exemplary embodiment of the present application, the sending module 603 is further configured to:

[0204] According to the above formula (6), the request data packet sending interval time is increased based on the initial value of the preset request data packet sending interval time.

[0205] In another example embodiment of the present application, the sending module 603 is further configured to:

[0206] Before sending the request data packet corresponding to the device address in the package list to the next target device through the Socket communication mode, the request data packet corresponding to the device address is copied and sent, and the request data packet contains a CRC16 check code.

[0207] In another example embodiment of the present application, the processing module 604 is further configured to:

[0208] The returned data packet is checked for legitimacy, and a check result is obtained.

[0209] When the check result is legitimate, the legitimate returned data packet is stored in the database according to the database table structure.

[0210] In another example embodiment of the present application, the processing module 604 is further configured to:

[0211] The returned data packet is sent to the server through the Socket communication mode, so that the server checks the returned data packet for legitimacy and obtains a check result, and when the check result is legitimate, the legitimate returned data packet is stored in the database 605 according to the database table structure.

[0212] In another example embodiment of the present application, the processing module 604 is further configured to:

[0213] The length of the returned data packet is verified to see whether it meets the data packet length requirement.

[0214] If the length of any returned data packet meets the data packet length requirement, the returned data packet is parsed, otherwise, the returned data packet is discarded.

[0215] The parsed value of each returned data packet meeting the data packet length requirement is verified to see whether it meets the communication protocol used.

[0216] If the parsed value of any returned data packet meeting the length requirement meets the communication protocol used, the returned data packet is checked to be legitimate, otherwise, the returned data packet meeting the length requirement is discarded.

[0217] In an example embodiment, a computer device is provided, which can be a server or a terminal, and an internal structure diagram of the computer device can be as shown in Figure 11As shown in the figure. The computer device includes a processor, a memory, an Input / Output (I / O) interface and a communication interface. Among them, the processor, the memory and the input / output interface are connected through the system bus, and the communication interface is connected to the system bus through the input / output interface. Among them, the processor of the computer device is used to provide computing and control capability. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store the data of the Socket forwarding data monitoring method. The input / output interface of the computer device is used to exchange information between the processor and external devices. The communication interface of the computer device is used to communicate with external terminals through network connection. The computer program is executed by the processor to implement a Socket forwarding data monitoring method.

[0218] Those skilled in the art can understand that, Figure 11 The structure shown in the figure is only a block diagram of part of the structure related to the scheme of the present application, and does not constitute a limitation on the computer device to which the scheme of the present application is applied. The specific computer device can include more or fewer components than those shown in the figure, or combine certain components, or have a different component arrangement.

[0219] In one exemplary embodiment, a computer device is also provided, including a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the steps in each of the method embodiments described above.

[0220] In one exemplary embodiment, a computer readable storage medium is provided, storing a computer program, which is executed by a processor to implement the steps in each of the method embodiments described above.

[0221] In one exemplary embodiment, a computer program product is provided, including a computer program, which is executed by a processor to implement the steps in each of the method embodiments described above.

[0222] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in the present application are all information and data authorized by the user or authorized by all parties, and the collection, use and processing of related data need to comply with relevant regulations.

[0223] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer readable storage medium, and when the computer program is executed, the processes of the above-mentioned embodiments of the methods can be included. Any reference to a memory, a database or other medium used in the embodiments provided in the present application can include at least one of a non-volatile and a volatile memory. The non-volatile memory can include a read-only memory (ROM), a magnetic tape, a floppy disk, a flash memory, an optical storage, a high-density embedded non-volatile memory, a resistive random access memory (ReRAM), a magnetoresistive random access memory (MRAM), a ferroelectric random access memory (FRAM), a phase change memory (PCM), a graphene memory, etc. The volatile memory can include a random access memory (RAM) or an external cache memory, etc. As an illustration but not limitation, the RAM can be in various forms, such as a static random access memory (SRAM) or a dynamic random access memory (DRAM), etc.

[0224] The database involved in the embodiments provided in the present application can include at least one of a relational database and a non-relational database. The non-relational database can include a distributed database based on a blockchain, etc., without being limited thereto. The processor involved in the embodiments provided in the present application can be a general-purpose processor, a central processing unit, a graphics processing unit, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, etc., without being limited thereto.

[0225] The technical features of the above embodiments can be combined arbitrarily. In order to make the description concise, all possible combinations of the technical features in the above embodiments are not described, however, as long as the combinations of the technical features do not exist contradictory, they should be considered as the scope of the present application.

[0226] The principles and implementation modes of the present application are described by applying specific examples in the present application. The above-mentioned embodiments are only used to help understand the method and its core idea of the present application; meanwhile, for those skilled in the art, according to the idea of the present application, the specific implementation mode and application range can be changed. In conclusion, the content of the present application should not be understood as a limitation.

Claims

1. A method for monitoring Socket forwarding data, characterized in that, Applied to terminals, the Socket forwarding data monitoring method includes: Check if the last header template in the header template list has been read: if so, reread the first header template in the header template list; otherwise, read the next header template in the header template list as the target header template. Perform a receive operation: Receive 1 byte of returned data; Push the received bytes into the receive pool list; After performing the receiving operation, a target header template is matched from the returned data in the receiving pool list based on a sliding matching algorithm. If the match is successful, the returned data is segmented based on the target header template to obtain a returned data packet, and the returned data packet is pushed into the receiving queue. Otherwise, the receiving operation and subsequent steps are returned to be executed. The target header template is the header template of the next device address that should be read. Get the number of returned data packets in the receive queue; The receive queue status is determined based on the number of returned data packets; If the receive queue is empty, the first sending operation is performed based on the preset request data packet sending interval: Copy the request data packet corresponding to the device address in the packet sending list; wherein, the packet sending list stores the request data packets corresponding to the device address of each target device, and the request data packets contain a CRC16 checksum; Send a request data packet with the corresponding device address to the next target device via Socket communication; The return data packet is retrieved from the receiving queue, and the validity of the retrieved return data packet is checked. If the check result is valid, the return data packet is stored in the database according to the database table structure. If the receive queue is not full, perform the second sending operation: Based on the number of returned data packets in the received queue, adjust the request data packet sending interval: If the number of returned data packets is less than a preset warning value, the preset request data packet sending interval is used as the initial value, and the request data packet sending interval is reduced based on the initial value. If the number of returned data packets is equal to the preset warning value, the initial value is used as the request data packet sending interval. If the number of returned data packets exceeds a preset warning value, the interval between sending the request data packets will be increased based on the initial value. The first sending operation is performed based on the adjusted request data packet sending interval.

2. The Socket forwarding data monitoring method according to claim 1, characterized in that, The sliding matching algorithm is used to match the target header template from the read return data. If the match is successful, the return data is segmented based on the target header template to obtain a return data packet, and the return data packet is pushed into the receiving queue. Otherwise, return to perform the receiving operation and subsequent steps, specifically including: Check if the data length of the receiving pool list is less than the length of the target packet header template: if it is less, return to execute the receiving operation; otherwise, take the receiving pool list as the string to be matched and the target packet header template as the substring, and start from the beginning position of the string to be matched, use the KMP sliding matching algorithm to match the substring, and calculate the next position to be matched. Move the substring to the next position where the string to be matched should be matched, and then extract a substring with the same length as the substring. Perform the splitting operation: The system sequentially checks whether the characters in the extracted string are completely identical to the substring. If they are not completely identical, it returns to the receiving operation and subsequent steps until the characters in the extracted string are completely identical to the substring. Otherwise, the string in the receiving pool list that is located before the position of the extracted string is pushed into the receiving queue as a return data packet.

3. The Socket forwarding data monitoring method according to claim 1, characterized in that, The reduction of the request data packet sending interval time based on the initial value is performed according to the following formula: ； ； in, s This refers to the adjusted request packet sending interval. , This refers to the minimum data refresh interval for the corresponding target device. x The preset interval for sending request data packets. The preset warning value, As a warning coefficient, w The length of the receive queue. k For the number of returned data packets, The most recent interval between sending and receiving messages. It is a monotonically increasing bivariate function.

4. The Socket forwarding data monitoring method according to claim 1, characterized in that, The request data packet sending interval is increased based on the initial value, according to the following formula: ； ； in, s This refers to the adjusted request packet sending interval. , This represents the maximum data refresh interval for the corresponding target device. x The preset interval for sending request data packets. The preset warning value, As a warning coefficient, w The length of the receive queue. k For the number of returned data packets, The most recent interval between sending and receiving messages. It is a monotonically increasing bivariate function.

5. The Socket forwarding data monitoring method according to claim 1, characterized in that, Also includes: Perform a validity check on the retrieved return data packet to obtain the check result; When the check result is valid, the valid returned data packet is stored in the database according to the database table structure.

6. The Socket forwarding data monitoring method according to claim 1, characterized in that, Also includes: The retrieved return data packet is sent to the server via Socket communication, so that the server can perform a validity check on the return data packet and obtain the check result. When the check result is valid, the return data packet is stored in the database according to the database table structure.

Images