Protocol debugging method, device and storage medium based on long connection service

Abstract

The embodiments of the present application provide a protocol debugging method, device and storage medium based on a long connection service, and relate to the field of protocol debugging technology. The method includes: responding to a long connection service request from a client, establishing a long connection link between the client and the server; obtaining the request protocol data sent by the client through the long connection link in real time; filtering the request protocol data based on preset data filtering configuration information to obtain the protocol data to be tested; synchronizing the protocol data to be tested to a debugging console, so that the debugging console performs debugging operations based on the protocol data to be tested. The embodiments of the present application establish a long connection link between the client and the server based on a link proxy service, and synchronize the protocol data in the long connection link to the debugging console, thereby achieving the purpose of protocol debugging of the long connection service.

Description

Technical Field

[0001] The present application relates to the field of protocol debugging technology, and in particular to a protocol debugging method, device and storage medium based on a long connection service. Background Art

[0002] With the rapid development of Internet game products, users' requirements for gaming experience are also increasing. Since the long connection protocol has some incomparable advantages over the short connection protocol, such as high concurrency, low memory consumption, high transmission efficiency, low network latency, simple transmission model and low R&D cost, more and more game services use the long connection protocol to implement the business logic of the game.

[0003] At present, the debugging of game services mainly adopts the debugging solution based on the short connection protocol. However, since the long connection protocol and the short connection protocol have completely different debugging methods, the protocol debugging solution of the short connection service cannot be directly reused, resulting in the existing solution being unable to meet the current debugging needs of game services based on the long connection protocol. In summary, there is an urgent need for a solution that can effectively debug the protocol for the long connection service. Summary of the invention

[0004] The purpose of the embodiments of the present application is to provide a protocol debugging method, device and storage medium based on a persistent connection service, so as to implement protocol debugging for a persistent connection service.

[0005] In a first aspect, an embodiment of the present application provides a protocol debugging method based on a long connection service, including:

[0006] Responding to the client's persistent connection service request, establishing a persistent connection link between the client and the server;

[0007] Acquire request protocol data sent by the client through the persistent connection link in real time;

[0008] Filter the requested protocol data based on preset data filtering configuration information to obtain the protocol data to be tested;

[0009] The protocol data to be tested is synchronized to a debugging console, so that the debugging console performs debugging operations based on the protocol data to be tested.

[0010] In an embodiment of the present application, a persistent connection link between the client and the server is established based on a link proxy service, and the protocol data in the persistent connection link is synchronized to the debugging console, thereby achieving the purpose of protocol debugging of the persistent connection service.

[0011] In some possible embodiments, synchronizing the protocol data to be tested to a debugging console so that the debugging console performs a debugging operation based on the protocol data to be tested includes:

[0012] Synchronizing the protocol data to be tested to a debugging console so that the debugging console displays the protocol data to be tested in the form of a message list;

[0013] Obtaining a resend request packet fed back by the debugging console, and adding the resend request packet to the head of a message queue, so as to perform resend debugging on the first target message in the message list;

[0014] The resend request packet is generated by the debugging console based on the first target message selected by the debugging personnel for the message list.

[0015] In the embodiment of the present application, the message list is displayed based on the debugging console, and retransmission debugging is performed based on the message selected by the debugger, thereby meeting the message retransmission debugging requirements in the long connection service.

[0016] In some possible embodiments, synchronizing the protocol data to be tested to a debugging console so that the debugging console performs a debugging operation based on the protocol data to be tested includes:

[0017] Synchronizing the protocol data to be tested to a debugging console so that the debugging console displays the protocol data to be tested in the form of a message list;

[0018] Responding to a manual debugging request from the debugging console, and suspending the data transmission service in the long connection link;

[0019] Obtaining a first custom request packet fed back by the debugging console, and restarting the data transmission service in the long connection link based on the first custom request packet;

[0020] The first custom request packet is generated by the debugging console based on the custom editing performed by the debugging personnel on the second target message in the message list.

[0021] In an embodiment of the present application, the captured messages are synchronized to the debugging console for display, and manual debugging of the messages is performed based on the operations and editing of the debugger, thereby meeting the manual debugging requirements in the long connection service.

[0022] In some possible embodiments, after the request protocol data is screened based on the preset data screening configuration information to obtain the protocol data to be tested, the method further includes:

[0023] Determine based on a preset breakpoint rule that the protocol data to be tested meets a debugging condition, and suspend the data transmission service in the long connection link;

[0024] Extracting a target breakpoint message matching the breakpoint rule from the protocol data to be tested, and synchronizing the target breakpoint message to the debugging console;

[0025] Obtaining a second custom request packet fed back by the debugging console, and restarting the data transmission service in the long connection link based on the second custom request packet;

[0026] The second customized request packet is generated by the debugging console based on the customized editing performed by the debugger on the target breakpoint message.

[0027] In an embodiment of the present application, breakpoints are automatically identified and protocol data transmission is suspended by configuring breakpoint rules, so that the debugging mode can be automatically entered according to the identified specific messages, thereby meeting the automatic debugging requirements in the long connection service.

[0028] In some possible embodiments, after the request protocol data is screened based on the preset data screening configuration information to obtain the protocol data to be tested, the method further includes:

[0029] Identifying a third target message in the protocol data to be tested that matches a preset message screening rule;

[0030] Determining, according to preset message configuration information corresponding to the message screening rule, an automatic configuration message corresponding to the third target message;

[0031] The third target message in the protocol data to be tested is replaced based on the automatic configuration message, and a debugging operation is performed based on the replaced protocol data to be tested.

[0032] In an embodiment of the present application, specific messages in the protocol data are automatically identified through configuration rules and pre-configured modified messages are automatically replaced, thereby further improving the efficiency of automatic debugging.

[0033] In some possible embodiments, before filtering the request protocol data based on the preset data filtering configuration information to obtain the protocol data to be tested, the method further includes:

[0034] Synchronizing the request protocol data to a debugging console so that the debugging console displays the request protocol data;

[0035] Acquire the data screening rule sent by the debugging console, and determine the preset data screening configuration information based on the data screening rule;

[0036] The data screening rule is generated by the debugging console according to the editing performed by the debugger based on the request protocol data.

[0037] In an embodiment of the present application, by synchronizing all protocol data to the debugging console for display, the debugging personnel can configure data screening rules according to needs, thereby filtering out protocol data of no interest in the link, further improving the efficiency of protocol debugging.

[0038] In some possible embodiments, after acquiring in real time the request protocol data sent by the client through the persistent connection link, the method further includes:

[0039] If it is determined that the protocol data transmitted between the client and the server belongs to a preset target protocol type, the protocol data is sequence converted based on a protocol interpretation file corresponding to the target protocol type.

[0040] In the embodiment of the present application, a specific type of protocol data is converted into a sequence by configuring a protocol parsing file, thereby meeting the need to debug different protocol data and improving the flexibility of protocol debugging.

[0041] In a second aspect, an embodiment of the present application provides a protocol debugging device based on a long connection service, including:

[0042] A connection establishment module, used to respond to a persistent connection service request from a client and establish a persistent connection link between the client and the server;

[0043] A data acquisition module, used for acquiring in real time the request protocol data sent by the client through the persistent connection link;

[0044] A data screening module, used to screen the requested protocol data based on preset data screening configuration information to obtain the protocol data to be tested;

[0045] The data debugging module is used to synchronize the protocol data to be tested to the debugging console, so that the debugging console performs debugging operations based on the protocol data to be tested.

[0046] In a third aspect, an embodiment of the present application provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor can implement the method described in any embodiment of the first aspect when executing the program.

[0047] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the method described in any embodiment of the first aspect can be implemented.

[0048] In a fifth aspect, an embodiment of the present application provides a computer program product, wherein the computer program product includes a computer program, wherein when the computer program is executed by a processor, the method described in any embodiment of the first aspect can be implemented. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments of the present application will be briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0050] Figure 1 A flowchart of a protocol debugging method based on a long connection service provided in an embodiment of the present application;

[0051] Figure 2 A schematic diagram of the overall architecture of a protocol debugging method based on a long connection service provided in an embodiment of the present application;

[0052] Figure 3 A schematic diagram of a retransmission debugging scenario of a protocol debugging method based on a long connection service provided in an embodiment of the present application;

[0053] Figure 4 A schematic diagram of a manual debugging scenario of a protocol debugging method based on a long connection service provided in an embodiment of the present application;

[0054] Figure 5 A schematic diagram of the structure of a protocol debugging device based on a long connection service provided in an embodiment of the present application;

[0055] Figure 6 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0056] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application.

[0057] It should be noted that similar reference numerals and letters represent similar items in the following drawings, so once an item is defined in one drawing, it does not need to be further defined and explained in subsequent drawings. At the same time, in the description of this application, the terms "first", "second", etc. are only used to distinguish the description and cannot be understood as indicating or implying relative importance.

[0058] It should be noted that a long connection refers to a persistent connection link established between the client and the server. Once the connection is established, communication can be maintained for a long time. In a long connection, the client and the server can send and receive data at any time without having to connect and close each time. A short connection refers to a connection established each time data is exchanged between the client and the server. After the data is sent, the connection is disconnected. Due to the unique advantages of long connections over short connections, more and more game services use long connection protocols for data transmission.

[0059] In an existing debugging scheme for short connection protocols, first, the server and the client need to jointly draft the structure file of the connection protocol; then, when the server and the client establish a connection, the server's protocol is intercepted and the protocol testing platform modifies the protocol and returns it to the client; finally, the server and the client transmit data through defined encryption and decryption files to implement debugging operations.

[0060] It can be seen that the existing protocol debugging solutions have at least the following defects: they need to be heavily embedded in the code of the game itself, which has a high degree of coupling with the game software and is not conducive to promotion; they need to develop plug-in information for the game itself, and have a high dependence on the business; it is difficult to monitor the sending and receiving of messages on the mobile terminal, and it is necessary to additionally intervene in the serialization and deserialization process, and different protocol types require different processing methods; it is necessary to intervene in some encryption and decryption and serialization and deserialization algorithms on the client, which has a certain adverse effect on the protocol security of the game; the protocols of each game project are quite different, and different games need to implement protocol testing tools separately, which brings a large amount of repetitive work process.

[0061] In view of the problems existing in the above-mentioned prior art, the embodiment of the present application provides a new solution for protocol debugging of long connection services, which mainly includes three parts: link proxy service, debugging console, and lightly intrusive plug-in. Among them, the link proxy service is mainly used to open the channel between the client and the server, and process the request and response messages through the channel; the debugging console can adopt a B / S structure, that is, a browser and server architecture mode, and all user viewing, debugging and other operations during the debugging process can be implemented in the debugging console; the lightly intrusive plug-in is deployed to the client, mainly used to obtain the connection information of the service, for example, a specific method can be called to obtain the IP and port to be connected.

[0062] like Figure 1 As shown, the embodiment of the present application provides a protocol debugging method based on a long connection service, which can be executed by a link proxy service, including the steps of:

[0063] S1. Respond to the client's persistent connection service request and establish a persistent connection link between the client and the server.

[0064] It should be noted that, first, a game debugging proxy service can be used to dynamically start the link proxy service. Exemplarily, a switch can be added to implement two working modes: proxy (link proxy service) and non-proxy. When a client needs to establish a long connection service, the proxy working mode can be turned on, that is, the link proxy service is started to establish a long connection link between the client and the server.

[0065] S2. Obtain the request protocol data sent by the client through the long connection link in real time.

[0066] After the connection link between the client and the server is established through the link proxy service, various requests (request protocol data) and response messages transmitted in the link can be obtained in real time. During the debugging process, the request protocol data initiated by the client is mainly obtained in real time.

[0067] S3. Filter the requested protocol data based on preset data filtering configuration information to obtain the protocol data to be tested.

[0068] It is understandable that, since the long connection protocol data may contain a large amount of data that is irrelevant to the debugging process, these data can be filtered based on the pre-configured data screening configuration information, thereby filtering out the protocol data to be tested that is of interest. For example, in order to keep the long connection link able to effectively transmit data, the communication link will contain some data such as heartbeat requests, which are sent regularly to monitor the connection status of the client and the server, but are usually meaningless data for the debugging process, so these data can be filtered by configuring filtering rules, thereby improving the efficiency of long connection protocol debugging.

[0069] S4. Synchronize the protocol data to be tested to the debugging console, so that the debugging console performs debugging operations based on the protocol data to be tested.

[0070] It should be noted that the protocol data to be tested captured and filtered from the long connection link can be synchronized to the debugging console so that the debugger can view the data and debug according to the needs. For example, a captured message data can be modified and edited so that the server can respond to the modified message, thereby testing the game service effect after the message is modified.

[0071] Based on this, a persistent connection link between the client and the server is established based on the link proxy service, and the protocol data in the persistent connection link is synchronized to the debugging console, so as to achieve the purpose of protocol debugging of the persistent connection service.

[0072] For example, the overall architecture of the protocol debugging solution based on the long connection service is as follows: Figure 2As shown, for the scenario of upstream request, the connection between the game client and the server is first established through the link proxy service, where the link proxy service mainly includes FS (Fake TCP Server), Handler, FC (Fake TCP Client) and other modules; Handler is mainly used to capture the request data (request packet) in the communication link, and serialize, deserialize, encrypt and decrypt these request protocol data, and synchronize these request protocol data to the debugging console for display.

[0073] In some possible embodiments, after step S2, the following steps may also be included:

[0074] If it is determined that the protocol data transmitted between the client and the server belongs to a preset target protocol type, the protocol data is sequenced based on a protocol interpretation file corresponding to the target protocol type.

[0075] It is understandable that the debugger can choose to configure the protocol interpretation file according to the protocol type of the request packet. For example, protocols such as json / mspack do not need serialization and deserialization, so they do not need protocol interpretation files, while protobuf and thrift need to configure protocol interpretation files for serialization and deserialization. Similarly, for the data downlink scenario of the server facing the client, it can be regarded as the reverse process of the above request uplink scenario.

[0076] In some possible embodiments, step S4, synchronizing the protocol data to be tested to the debugging console so that the debugging console performs debugging operations based on the protocol data to be tested, may include:

[0077] Synchronize the protocol data to be tested to the debugging console, so that the debugging console displays the protocol data to be tested in the form of a message list;

[0078] Obtain a resend request packet fed back by the debugging console, and add the resend request packet to the head of the message queue to perform resend debugging on the first target message in the message list;

[0079] The resend request packet is generated by the debugging console based on the first target message selected by the debugging personnel for the message list.

[0080] It should be noted that for some test scenarios, such as testing the stability of the server when sending the same request multiple times, it is necessary to resend the captured messages for debugging.

[0081] Specifically, Figure 3As shown, for the captured protocol data to be tested, it can be displayed in the form of a message list through the debugging console. Since data is usually transmitted continuously through a long connection link during the game operation, it is necessary to scroll and display the captured and filtered protocol data to be tested. Exemplarily, the message list can be scrolled one by one. For example, the message list displays a maximum of three message data at the same time. When the new fourth message is captured, the first message is removed from the message list. Exemplarily, it can also be scrolled in the form of turning pages. For example, the message list can display up to three messages at the same time. Whenever three new messages are captured, the three currently displayed messages are replaced with three new messages (whole page replacement).

[0082] It is understandable that when the client establishes multiple persistent links with the server, a message list is displayed for each persistent link. When multiple clients establish persistent links with the server, a debugging window can be displayed for each client to perform debugging tasks such as viewing and operating each client.

[0083] For the message list displayed on the debugging console, when the debugger sees the message he wants to test, he can choose to suspend the data transmission of the link and select the message to be tested (the first target message) to resend. Optionally, after selecting the message he wants to resend, he can customize the message or resend it directly according to the needs.

[0084] It should be noted that, for the retransmitted request packet, the link proxy service can directly put it at the head of the message queue, so that the retransmitted request packet can be sent to the server first. It can be understood that by configuring the number of retransmissions, intervals, message content and other information for message retransmission debugging, it is possible to simulate delays, packet loss and other events in real scenarios.

[0085] In some possible embodiments, step S4, synchronizing the protocol data to be tested to the debugging console so that the debugging console performs debugging operations based on the protocol data to be tested, may include:

[0086] Synchronize the protocol data to be tested to the debugging console, so that the debugging console displays the protocol data to be tested in the form of a message list;

[0087] Respond to a manual debugging request from the debugging console and suspend the data transmission service in the persistent connection link;

[0088] Obtain a first custom request packet fed back by the debugging console, and restart the data transmission service in the long connection link based on the first custom request packet;

[0089] The first custom request packet is generated by the debugging console based on the custom editing performed by the debugging personnel on the second target message in the message list.

[0090] It should be noted that, since the captured and filtered protocol data to be tested can be viewed through the debugging console (displayed in the form of a message list), the debugger can choose to manually pause and edit the custom request package for manual debugging according to needs.

[0091] Specifically, Figure 4 As shown, when the debugger views the client's uplink request data based on the debugging console and needs to debug a certain request, he can click Pause, then edit (tamper with) the request, and click Next. The link proxy service can send the modified request package to the server, thereby completing the manual debugging process of a certain request package.

[0092] In some possible embodiments, after step S3, the following steps may also be included:

[0093] Determine whether the protocol data to be tested meets the debugging conditions based on the preset breakpoint rules, and suspend the data transmission service in the long connection link;

[0094] Extract the target breakpoint message matching the breakpoint rule from the protocol data to be tested, and synchronize the target breakpoint message to the debugging console;

[0095] Obtain a second custom request packet fed back by the debugging console, and restart the data transmission service in the persistent connection link based on the second custom request packet;

[0096] The second custom request packet is generated by the debugging console based on the custom editing of the target breakpoint message by the debugger.

[0097] It should be noted that in addition to the debugging mode manually paused by the debugger, the debugger can also configure breakpoint rules. When the incoming request data packets are monitored to meet the preset debugging conditions, the debugging mode can be automatically triggered and the corresponding request package message can be synchronously displayed on the debugging console, so that the debugger can complete the debugging process of a certain request package by custom editing the request package message.

[0098] Specifically, in the first step, the user first sets the breakpoint rules through the debugging console. For example, the protocol name can be pre-configured as the breakpoint rule. When the protocol name of the received request data packet matches the protocol name of the preset breakpoint rule, the debugging mode is automatically entered; optionally, the message body content can also be configured. When the content of the request data packet is detected to match the pre-configured content, the debugging mode is automatically entered. The second step is to pass the breakpoint rules configured by the user to the Handler for storage. The third step is that after receiving the request data, the Handler determines whether the request packet matches the breakpoint rules set by the user. If so, it sends an instruction to notify the debugging console to enter the debugging mode, and synchronously displays the corresponding request data to the debugging console, waiting for the debugger to view the request packet data and edit it before executing the debugging.

[0099] In some possible embodiments, after step S3, the following steps may also be included:

[0100] Identifying a third target message that matches a preset message screening rule in the protocol data to be tested;

[0101] Determining, according to preset message configuration information corresponding to the message screening rule, an automatic configuration message corresponding to the third target message;

[0102] The third target message in the protocol data to be tested is replaced based on the automatic configuration message, and a debugging operation is performed based on the replaced protocol data to be tested.

[0103] It should be noted that, in addition to manually editing and modifying the debugging message by the debugging personnel, the specific message can also be automatically edited by configuring the modification rules (message configuration information) to complete the debugging process.

[0104] Specifically, in the first step, the user first configures the message filtering rules and message configuration information through the debugging console. In the second step, the debugging console passes these rules and configuration information to the Handler, and the Handler saves the corresponding message filtering rules and message configuration information. In the third step, the Handler identifies the corresponding third target message that meets the rule conditions according to the message filtering rules, and modifies it into an automatic configuration message according to the message configuration information, and then sends the automatic configuration message to the server to complete the automatic detection and debugging process of the specific message.

[0105] In some possible embodiments, before step S3, the following steps may also be included:

[0106] Synchronize the request protocol data to the debugging console so that the debugging console displays the request protocol data;

[0107] Obtaining the data filtering rules sent by the debugging console, and determining the preset data filtering configuration information based on the data filtering rules;

[0108] The data filtering rules are generated by the debugging console according to the debugging personnel's editing based on the request protocol data.

[0109] It should be noted that, through the debugging console, the debugger can also customize the configuration data filtering rules, so as to set the request data that needs to be filtered or wants to be filtered according to the needs. Specifically, the data filtering rules are configured through the debugging console and passed to the Handler. The Handler can determine the data filtering configuration information based on the data filtering rules; when the Handler receives the request data and determines that it matches the data filtering configuration information, it can filter or filter the request data. Optionally, when the data filtering configuration information is a bupass configuration for the request data, when the request data that matches the data filtering configuration information is detected, the request data can be directly placed in the message queue and sent to the server, without the need for the Handler to capture the data and synchronize it to the debugging console.

[0110] Please refer to Figure 5 , Figure 5 The following is a block diagram showing the composition of a protocol debugging device based on a long connection service provided by some embodiments of the present application. It should be understood that the protocol debugging device based on a long connection service is similar to the above Figure 1 Corresponding to the method embodiment, each step involved in the above method embodiment can be executed. The specific functions of the protocol debugging device based on the long connection service can be found in the description above. To avoid repetition, the detailed description is appropriately omitted here.

[0111] Figure 5 The protocol debugging device based on the long connection service includes at least one software function module that can be stored in the memory in the form of software or firmware or solidified in the protocol debugging device based on the long connection service, and the protocol debugging device based on the long connection service includes:

[0112] The connection establishment module 510 is used to respond to the persistent connection service request of the client and establish a persistent connection link between the client and the server;

[0113] The data acquisition module 520 is used to acquire the request protocol data sent by the client through the persistent connection link in real time;

[0114] The data screening module 530 is used to screen the request protocol data based on the preset data screening configuration information to obtain the protocol data to be tested;

[0115] The data debugging module 540 is used to synchronize the protocol data to be tested to the debugging console, so that the debugging console performs debugging operations based on the protocol data to be tested.

[0116] It can be understood that the above-mentioned device item embodiment corresponds to the method item embodiment of the present invention. The protocol debugging device based on long connection service provided by the embodiment of the present invention can implement the protocol debugging method based on long connection service provided by any method item embodiment of the present invention.

[0117] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working process of the device described above can refer to the corresponding process in the aforementioned method, and will not be described in detail here.

[0118] like Figure 6 As shown, some embodiments of the present application provide an electronic device 600, which includes: a memory 610, a processor 620, and a computer program stored in the memory 610 and executable on the processor 620, wherein the processor 620 reads the program from the memory 610 through a bus 630 and executes the program to implement a method of any embodiment of the protocol debugging method based on a long connection service as described above.

[0119] Processor 620 can process digital signals and can include various computing structures, such as complex instruction set computer structure, reduced instruction set computer structure, or a structure that implements a combination of multiple instruction sets. In some examples, processor 620 can be a microprocessor.

[0120] The memory 610 may be used to store instructions executed by the processor 620 or data related to the execution of instructions. These instructions and / or data may include codes for implementing some or all functions of one or more modules described in the embodiments of the present application. The processor 620 of the disclosed embodiment may be used to execute instructions in the memory 610 to implement the method shown above. The memory 610 includes a dynamic random access memory, a static random access memory, a flash memory, an optical memory, or other memory known to those skilled in the art.

[0121] Some embodiments of the present application further provide a computer-readable storage medium having a computer program stored thereon. The computer program is executed by a processor to execute the method described in the method embodiment.

[0122] Some embodiments of the present application further provide a computer program product, which, when executed on a computer, enables the computer to execute the method described in the method embodiment.

[0123] It should be noted that each embodiment in this specification is described in a progressive manner, and each embodiment focuses on the differences from other embodiments, and the same or similar parts between the embodiments can be referred to each other. For the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0124] In several embodiments provided by the present application, it should be understood that the disclosed devices and methods can also be implemented in other ways. The device embodiments described above are merely schematic. For example, the flowcharts and block diagrams in the accompanying drawings show the possible architecture, functions and operations of the devices, methods and computer program products according to multiple embodiments of the present application. In this regard, each box in the flowchart or block diagram can represent a module, a program segment or a part of a code, and the module, a program segment or a part of a code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two consecutive boxes can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart, and the combination of boxes in the block diagram and / or flowchart can be implemented with a dedicated hardware-based system that performs a specified function or action, or can be implemented with a combination of dedicated hardware and computer instructions.

[0125] In addition, the functional modules in the various embodiments of the present application may be integrated together to form an independent part, or each module may exist separately, or two or more modules may be integrated to form an independent part.

[0126] If the functions are implemented in the form of software function modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application can be essentially or partly embodied in the form of a software product that contributes to the prior art. The computer software product is stored in a storage medium, including several instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0127] The above description is only an embodiment of the present application and is not intended to limit the scope of protection of the present application. For those skilled in the art, the present application may have various changes and variations. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application should be included in the scope of protection of the present application. It should be noted that similar reference numerals and letters represent similar items in the following drawings, so once an item is defined in one drawing, it does not need to be further defined and explained in the subsequent drawings.

[0128] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0129] It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or device including the elements.

Claims

1. A protocol debugging method based on a long connection service, characterized in that: Performed by the link agent service, including: Responding to the client's persistent connection service request, establishing a persistent connection link between the client and the server; Acquire request protocol data sent by the client through the persistent connection link in real time; Filter the requested protocol data based on preset data filtering configuration information to obtain the protocol data to be tested; Synchronizing the protocol data to be tested to a debugging console, so that the debugging console performs debugging operations based on the protocol data to be tested; After the real-time acquisition of the request protocol data sent by the client through the persistent connection link, the method further includes: If it is determined that the protocol data transmitted between the client and the server belongs to a preset target protocol type, performing sequence conversion on the protocol data based on a protocol interpretation file corresponding to the target protocol type; The step of synchronizing the protocol data to be tested to a debugging console so that the debugging console performs debugging operations based on the protocol data to be tested includes: Synchronizing the protocol data to be tested to a debugging console so that the debugging console displays the protocol data to be tested in the form of a message list; Responding to a manual debugging request from the debugging console, and suspending the data transmission service in the long connection link; Obtaining a first custom request packet fed back by the debugging console, and restarting the data transmission service in the long connection link based on the first custom request packet; The first custom request packet is generated by the debugging console based on the custom editing performed by the debugging personnel on the second target message in the message list; After the request protocol data is screened based on the preset data screening configuration information to obtain the protocol data to be tested, the method further includes: Determine based on a preset breakpoint rule that the protocol data to be tested meets a debugging condition, and suspend the data transmission service in the long connection link; Extracting a target breakpoint message matching the breakpoint rule from the protocol data to be tested, and synchronizing the target breakpoint message to the debugging console; Obtaining a second custom request packet fed back by the debugging console, and restarting the data transmission service in the long connection link based on the second custom request packet; The second customized request packet is generated by the debugging console based on the customized editing performed by the debugger on the target breakpoint message.

2. The protocol debugging method based on long connection service according to claim 1, characterized in that: The step of synchronizing the protocol data to be tested to a debugging console so that the debugging console performs debugging operations based on the protocol data to be tested includes: Synchronizing the protocol data to be tested to a debugging console so that the debugging console displays the protocol data to be tested in the form of a message list; Obtaining a resend request packet fed back by the debugging console, and adding the resend request packet to the head of a message queue, so as to perform resend debugging on the first target message in the message list; The resend request packet is generated by the debugging console based on the first target message selected by the debugging personnel for the message list.

3. The protocol debugging method based on long connection service according to claim 1, characterized in that: After the request protocol data is screened based on the preset data screening configuration information to obtain the protocol data to be tested, the method further includes: Identifying a third target message in the protocol data to be tested that matches a preset message screening rule; Determining, according to preset message configuration information corresponding to the message screening rule, an automatic configuration message corresponding to the third target message; The third target message in the protocol data to be tested is replaced based on the automatic configuration message, and a debugging operation is performed based on the replaced protocol data to be tested.

4. The protocol debugging method based on long connection service according to claim 1, characterized in that: Before the request protocol data is screened based on the preset data screening configuration information to obtain the protocol data to be tested, the method further includes: Synchronizing the request protocol data to a debugging console so that the debugging console displays the request protocol data; Acquire the data screening rule sent by the debugging console, and determine the preset data screening configuration information based on the data screening rule; The data screening rule is generated by the debugging console according to the editing performed by the debugger based on the request protocol data.

5. An electronic device, characterized in that: It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, it can implement the protocol debugging method based on the long connection service described in any one of claims 1 to 4.

6. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by the processor, the protocol debugging method based on the persistent connection service according to any one of claims 1 to 4 is executed.

7. A computer program product, characterized in that The computer program product includes a computer program, and when the computer program is executed by a processor, the protocol debugging method based on the long connection service according to any one of claims 1 to 4 is implemented.

Images