Universal method for extracting complete message based on protocol length characteristic function
By inheriting AbstractByteToMessageDecoder and using a protocol length feature function, the method addresses the challenge of decoding private protocols in Netty, enabling efficient and compatible message extraction across diverse protocols, reducing development complexity and errors.
Patent Information
- Application Number
- CN202411274892.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-09-11
- Publication Date
- 2024-12-27
AI Technical Summary
Existing network communication frameworks like Netty struggle to efficiently decode private protocols due to their proprietary and non-standard nature, requiring developers to write complex and error-prone custom code, which is inefficient and prone to compatibility issues.
A general method is proposed that inherits the AbstractByteToMessageDecoder class from ByteToMessageDecoder, embedding a general decoder in the Netty framework to define a constructor and initialize it, abstracting the parsing action of any protocol into a general process using a protocol length feature function, allowing easy integration of new protocols by filling in the transition function with their specific length features.
This approach simplifies the access to new protocols, enhances compatibility, reduces development time and errors, and ensures efficient message extraction across various protocols, improving maintainability and robustness of software.
Smart Images
Figure CN119211379A_ABST
Abstract
Description
Technical Field
[0001] The invention belongs to the technical field of digital information transmission, and in particular relates to a universal method for extracting complete messages based on a protocol length characteristic function. Background Art
[0002] In the TCP / IP model (Transmission Control Protocol / Internet Protocol), there are four layers: Application Layer, Transport Layer, Network Layer, and Link Layer. At the transport layer, there are two protocols: TCP and UDP. The advantage of TCP is that it can dynamically adapt to network conditions and application requirements, automatically handle the reorganization and retransmission of data packets, and thus provide reliable data transmission services to ensure that data arrives at the other party in order without error checking or loss. In most business scenarios, such as using APP to browse products, shop, place orders, and transfer files and emails, they are all based on the TCP protocol.
[0003] TCP (Transmission Control Protocol) is a streaming protocol. Its main feature is that it treats the transmitted data as a continuous stream of water without obvious boundary markers. In this network connection, data is regarded as a byte stream without structure and fixed message boundaries. The sender can send data continuously, and the receiver also treats this data as a continuous stream. The TCP protocol itself does not care how this streaming data is divided into complete messages or data packets at the business level, nor does it guarantee that the sent data packets and the received data packets are one-to-one corresponding. This brings a problem: if the sender sends two data fragments continuously, the receiver may receive all the data at once, or it may receive it in multiple times. Therefore, when using the TCP protocol for network communication, developers need to handle the boundary problem of data packets themselves. For example, by inserting some specific characters in the data stream, or implementing the complete message extraction mechanism at the application layer to distinguish different messages.
[0004] The above describes that the TCP protocol requires developers to design complete message extraction rules at the application layer. Therefore, some open source network engines provide some ready-made protocol extraction rules for developers to use on demand according to actual scenarios. Taking the most popular Netty framework on the Internet as an example, Netty is a high-performance, asynchronous, event-driven network application framework for quickly developing high-performance protocol servers and client programs. It is written in Java as a whole and provides a simple and powerful API to simplify network programming, especially for the development of high-concurrency and high-throughput network applications.
[0005] Netty is an asynchronous, event-driven network application framework for rapid development of maintainable, high-performance servers and clients.
[0006] In the design of the Netty network protocol framework, the processor that handles the message length is mainly used to solve the problem of extracting complete messages and ensure that the data transmitted to the application layer is correct and complete. Some decoders have been designed in the Netty framework: for example
[0007] 1)LengthFieldBasedFrameDecoder
[0008] According to the following content
[0009]
[0010] Its principle is to first agree to set an N-byte field in front of the data. The value of this field is the length of the subsequent application layer message. According to this length, the content of the corresponding length is extracted and passed to the application layer.
[0011] For example, the value of Length is 0x000C, which corresponds to decimal 12, indicating that there are 12 bytes of content to be extracted. The client extracts the subsequent 12 bytes, which are exactly "HELL0, WORLD", which contains a comma + 1 space in the middle.
[0012] Another example is FixedLengthFrameDecoder, which divides the received data into several groups, each with a fixed length, for example:
[0013] The client received the following data
[0014]
[0015] Assuming that it is agreed that each group consists of 3 bytes, the client can divide the above content into the following groups of data:
[0016]
[0017] Then each group of messages can be passed to the application layer!
[0018] There are also delimiter decoders such as DelimiterBasedFrameDecoder, which means that one or more delimiters are agreed upon in the message in advance. When parsing the received message, if a delimiter is encountered, the previous content is passed to the application layer for processing as a complete message.
[0019] For example, the client agrees to use \n as the delimiter, and the message content in the client's receiving buffer is:
[0020]
[0021] So the client decodes it into 2 groups of messages as follows:
[0022]
[0023] Then upload it to the application layer for processing. There are other similar decoders in Netty, which are not listed here one by one. From this, we can see that Netty has encapsulated some decoders of common message formats for specific scenarios for development and use, which simplifies the problem of extracting complete messages based on TCP stream protocol.
[0024] However, in many business scenarios, such as the Internet of Things, there are some requirements for network communication based on private protocol formats. In the Internet of Things, different hardware manufacturers may use their own protocol formats, which are not the universal formats in Netty. This leads to the following problems:
[0025] 1) The existing decoder preset in Netty cannot be used normally.
[0026] 2) Users need to write their own code for each manufacturer's protocol for extraction, and the protocols between different manufacturers are different, resulting in a large workload for self-writing code. In addition, in the process, the written code may be incompatible. The more manufacturer protocols are connected, the easier it is to make mistakes.
[0027] 3) The complex protocols provided by manufacturers require very high personal skills from programmers. Even if they successfully write the code themselves, the results obtained are too complicated and sometimes require a lot of time to optimize. Summary of the invention
[0028] Aiming at the problem that the existing technology is not friendly to the decoding of private protocols provided by different developers under the Netty network protocol framework and it is difficult to use a general decoder, the present invention proposes a general method for extracting complete messages based on a protocol length feature function. Based on the Netty framework, the system abstract tool class AbstractByteToMessageDecoder is inherited from the basic class ByteToMessageDecoder, and the general decoder is embedded in the Netty framework to define a constructor and initialize it. The parsing action of any protocol is abstracted into a general process through the constructor, and the distinguishing protocol format code of the private protocol is built into the transition(times, in, in.readerlndex()) protocol length feature function. When any new protocol is connected, the transition(times, in, in.readerlndex()) protocol length feature function is filled according to the length feature of the corresponding protocol to complete the decoder that meets the entire complete message extraction logic, and the decoder is used to realize message extraction during operation.
[0029] Preferably, the specific structure of the constructor is: define the initialization of the current decoding round number, the reserved initial round to be read bytes and the number of bytes that need to be read in the corresponding round, the constructor accepts an integer parameter length, which is used to initialize several key member variables of the class, and sets the reserved initial round to be read bytes and the number of bytes that need to be read in the corresponding round to the passed length parameter value. For example, the most basic constructor is:
[0030]
[0031] Preferably, in the constructor, times is the current decoding round number; initialFrameLength is the reserved initial round bytes to be read; currentFrameLength is the number of bytes that need to wait to be read in the corresponding round, and times is initialized to 1. initialFrameLength and currentFrameLength are initialized to the passed length value.
[0032] Preferably, the initialFrameLength is a final variable, indicating the length of the initial frame and cannot be changed, and the currentFrameLength is used to indicate the length of the currently processed frame and can be modified during the object life cycle.
[0033] Preferably, the parsing action of any protocol is abstracted into a general process through a constructor through a decoding framework, and the decoding framework includes the following steps:
[0034] S1: Initialization: Set currentFrameLength to initialFrameLength,
[0035] That is, the number of bytes expected to be read in the first round of decoding;
[0036] S2: Decoding loop: Enter an infinite while(true) loop to continue decoding operations;
[0037] S3: Check the number of readable bytes: In each round of decoding, first check whether the current number of readable bytes in.readableBytes() is less than the expected number of bytes in the current round, currentFrameLength; if it is less, it means that the data of the current round has not arrived completely, return null, and continue to read network data;
[0038] S4: Data arrival processing: If the number of readable bytes reaches or exceeds the number of bytes expected in the current round, call the transition method and pass the current round times, input data in, and current reading position in.readerlndex() to the protocol length feature function; the transition method analyzes according to the protocol characteristics and returns the number of bytes newFrameLength expected for the next round of decoding;
[0039] S5: Check newFrameLength to determine whether the decoding is finished; until a non-null ByteBuf is returned after a certain decoding is completed, or an instruction is received to force the loop to jump out.
[0040] Preferably, when judging whether the decoding is finished in S5, if newFrameLength is not equal to the predefined end mark END, the decoding is not finished yet and it is necessary to enter the next round. At this time, times is increased to indicate entering the next round of decoding, currentFrameLength is updated to newFrameLength, and the expected number of bytes to be read is set for the next round of decoding.
[0041] Preferably, when determining whether the decoding is finished in S5, newFrameLength is equal to the predefined end flag END, then the current round of decoding is finished, and the complete message has been read, and a byte message with a length of currentFrameLength is read from the input data, stored in ByteBuf, times is reset to 1, currentFrameLength is reset to initialFrameLength, and preparations are made for subsequent parsing, and ByteBuf is returned, that is, the complete message of this application layer.
[0042] Preferably, when a private protocol carries multiple groups of protocol format codes, each group of protocol format codes is built into the transition(times, in, in.readerlndex()) protocol length feature function in turn, and multiple groups of associated decoders are generated in turn, the decoders are executed in turn, and the temporary decoding results are placed in a buffer, waiting for the call in the subsequent round of decoding. When all groups of protocol format codes are decoded, the final result is output.
[0043] Preferably, if any decoder encounters an unexpected situation during the decoding process, the decoder will throw an exception or return a specific end mark.
[0044] The present invention also includes a storage device, characterized in that:
[0045] The storage device is used to store a computer program, and the computer program is used to execute a general method for extracting a complete message based on a protocol length feature function.
[0046] Due to the adoption of the technical solution, the present invention only needs to fill in the transition(times, in, in.readerlndex()) protocol length feature function according to the requirements of the framework. When any new protocol is accessed, a decoder that meets the entire complete message extraction logic can be generated according to the protocol length feature function of the corresponding protocol. The access to the new protocol can be achieved by inputting the length feature array corresponding to the new protocol into the decoder and notifying the framework. This not only simplifies the access cost of the new protocol and improves the development efficiency, but also ensures the compatibility between different protocols and reduces the risk of compatibility errors. BRIEF DESCRIPTION OF THE DRAWINGS
[0047] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the present invention.
[0048] Figure 1 It is a schematic diagram of the workflow of a general method for extracting complete messages based on a protocol length feature function of the present invention.
[0049] Figure 2 It is a flow chart of making a decoding framework in a general method for extracting a complete message based on a protocol length feature function of the present invention. DETAILED DESCRIPTION
[0050] The following will be combined with the accompanying drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. It can be understood that the specific implementation methods described here are only used to explain the relevant content, rather than to limit the present disclosure.
[0051] The implementation of the present invention is based on the TCP / IP model. At the transport layer, TCP (Transmission Control Protocol) and UDP (User Datagram Protocol) together constitute the two cornerstones of network communication. Among them, the TCP protocol, with its unique advantages, occupies a dominant position in most business scenarios. The core value of TCP lies in its ability to dynamically adapt to complex and changeable network conditions and diversified application requirements, and ensures the reliability of data transmission through a series of carefully designed mechanisms, such as automatic data packet reorganization and retransmission. This feature enables the TCP protocol to perform well in ensuring that data arrives without errors, loss, and in order, thereby winning widespread trust and application.
[0052] As a streaming protocol, TCP is unique in that it treats the transmitted data as a continuous stream of water without setting clear boundary markers. In this type of network connection, data is regarded as an unstructured byte stream without fixed message boundaries. The sender can send data continuously without restriction, and the receiver treats the data as a coherent stream for processing. The TCP protocol itself does not pay attention to how the streaming data is divided into complete messages or data packets at the business level, nor does it ensure a one-to-one correspondence between the sent and received data packets. Although this feature gives the TCP protocol great flexibility and adaptability, it also brings a problem that cannot be ignored: when the sender sends multiple data fragments continuously, the receiver may receive all the data at once or in multiple times, which increases the complexity of data processing.
[0053] Therefore, when using the TCP protocol for network communication, developers are faced with the challenge of how to deal with the packet boundary problem. To solve this problem, developers need to design complete packet extraction rules at the application layer. This usually involves inserting specific characters as delimiters in the data stream, or implementing more complex packet extraction mechanisms at the application layer to accurately distinguish different messages. These measures ensure that the receiver can correctly parse and process the received data, thereby ensuring the accuracy and reliability of communication.
[0054] However, for many developers, designing packet extraction rules by themselves can be a tedious and error-prone task. Fortunately, some open source network engines provide ready-made protocol extraction rules for developers to use on demand according to actual scenarios. These network engines provide simple and powerful APIs by encapsulating the underlying network communication details, greatly simplifying the complexity of network programming. Among them, Netty, as one of the most popular network engines on the Internet, has become the preferred framework for rapid development of high-performance protocol servers and client programs with its high-performance, asynchronous, and event-driven features.
[0055] Netty is written in Java and provides a rich feature set, as well as excellent scalability and flexibility. It supports multiple transport protocols (such as TCP, UDP, etc.) and encoders / decoders (such as ByteToMessageDecoder, MessageToByteEncoder, etc.), allowing developers to easily build complex network communication applications. In addition, Netty also provides comprehensive memory management, security features, and an efficient I / 0 processing mechanism to ensure application stability and performance.
[0056] ByteToMessageDecoder parses the byte stream in the push handler into other types of message types, called decoders.
[0057] The decoder inherits from ChannelInboundHandlerAdapter, which is the top-level abstract class of all decoding classes. It defines the decoding operation process. Users can implement the abstract method decode by themselves to implement specific decoding.
[0058] In the Netty framework, developers can use the encoder / decoder framework it provides to easily handle the message extraction problem caused by the streaming characteristics of the TCP protocol. By inheriting the ByteToMessageDecoder class and implementing its decode method, developers can extract complete messages from the byte stream according to the protocol rules of the application layer. As described in the background technology, many general decoders have been built into the Netty framework, but these decoders cannot decode private protocols.
[0059] The present invention is mainly designed for private protocols. Private protocols, also known as non-standard protocols, refer to a set of communication or interaction rules formulated by a certain enterprise or organization without review, adoption, or approval by international or national standardization organizations. These protocols are usually not open to the public and are only used between devices produced by a specific enterprise or in the internal network of the enterprise. The implementation details of private protocols are not open to the public, which means that it is difficult for other enterprises or organizations to understand and use these protocols without authorization. However, in most fields, private protocols are often closely related to the products or technologies of specific enterprises and are a reflection of the technological strength of the enterprise.
[0060] In particular, as leading companies in some fields, they often enter the market early and promote their private protocols, gradually obtaining, maintaining and strengthening their market monopoly. These private protocols have become de facto standards before being adopted by international or national standardization organizations, forcing other companies to follow these protocols when they are compatible with Cisco products. It is precisely these characteristics of private protocols that make them widely used in actual work.
[0061] Although private protocols have certain advantages in some aspects, such as achieving close integration between devices and providing efficient network management, their closedness and proprietary nature also bring a series of challenges and disputes. On the one hand, private protocols may hinder the openness and sharing of technology and restrict market competition; on the other hand, with the continuous development of technology, private protocols may not keep up with the pace of standardization, resulting in technological backwardness and compatibility issues. This is also the problem to be solved by the present invention.
[0062] like Figure 1 As shown, the present invention provides a general method for extracting complete messages based on a protocol length feature function. Based on the Netty framework, the system abstract tool class AbstractByteToMessageDecoder is inherited from the basic class ByteToMessageDecoder, and the general decoder is embedded in the Netty framework to define a constructor and initialize it.
[0063] public abstract class AbstractByteToMessageDecoder
[0064] extends ByteToMessageDecoder{
[0065] In this way, the universal decoder generated by the present invention is embedded in the Netty framework for use.
[0066] The constructor abstracts the parsing action of any protocol into a general process, and builds the distinguishing protocol format code of the private protocol into the transition(times, in, in.readerlndex()) protocol length feature function. When any new protocol is connected, the transition(times, in, in.readerlndex()) protocol length feature function is filled according to the length feature of the corresponding protocol to complete the decoder that meets the entire complete message extraction logic.
[0067] The specific structure of the constructor is: define the initialization of the current decoding round number, the reserved initial round to be read bytes and the number of bytes that need to be read in the corresponding round. The constructor accepts an integer parameter length, which is used to initialize several key member variables of the class, and sets the reserved initial round to be read bytes and the number of bytes that need to be read in the corresponding round to the passed length parameter value. For example, the most basic constructor is:
[0068]
[0069] In the constructor, times is the current decoding round number; initialFrameLength is the reserved initial round bytes to be read; currentFrameLength is the number of bytes that need to be read in the corresponding round, and times is initialized to 1. initialFrameLength and currentFrameLength are initialized to the passed length value. The initialFrameLength is a final variable that represents the length of the initial frame and cannot be changed. The currentFrameLength is used to represent the length of the currently processed frame.
[0070] And can be modified during the object life cycle.
[0071] This decoder is used to extract messages during operation.
[0072] like Figure 2 As shown, the parsing action of any protocol is abstracted into a general process through the constructor through the decoding framework, and the decoding framework includes the following steps:
[0073] S1: Initialization: Set currentFrameLength to initialFrameLength.
[0074] That is, the number of bytes expected to be read in the first round of decoding;
[0075] S2: Decoding loop: Enter an infinite while(true) loop to continue decoding operations;
[0076] S3: Check the number of readable bytes: In each round of decoding, first check whether the current number of readable bytes in.readableBytes() is less than the expected number of bytes in the current round, currentFrameLength; if it is less, it means that the data of the current round has not arrived completely, return null, and continue to read network data;
[0077] S4: Data arrival processing: If the number of readable bytes reaches or exceeds the number of bytes expected in the current round, call the transition method and pass the current round times, input data in, and current reading position in.readerlndex() to the protocol length feature function; the transition method analyzes according to the protocol characteristics and returns the number of bytes newFrameLength expected for the next round of decoding;
[0078] S5: Check newFrameLength to determine whether decoding is finished: When newFrameLength is not equal to the predefined end mark END, decoding is not finished yet and it is necessary to enter the next round. At this time, times is increased to indicate entering the next round of decoding, and currentFrameLength is updated to newFrameLength, and the expected number of bytes to be read for the next round of decoding is set. When newFrameLength is equal to the predefined end mark END, the current round of decoding is finished and the complete message has been read. The byte message with a length of currentFrameLength is read from the input data and stored in ByteBuf. Times is reset to 1 and currentFrameLength is reset to initialFrameLength to prepare for subsequent parsing. ByteBuf is returned, which is the complete message of this application layer.
[0079] Its specific manifestations are:
[0080]
[0081]
[0082]
[0083] In order to better understand the technical solution of the present invention, several decoders that have been configured in the Netty framework mentioned in the background technology are taken as examples and remade using the technical solution of the present invention.
[0084] Embodiment 1: LengthFieldBasedFrameDecoder, using the technical solution of the present invention to process, then:
[0085] We assume that the value of the first 4 bytes of a message is the complete length of the message that needs to be read later, then:
[0086] The parameter value of the constructor is passed to 4
[0087] The protocol length characteristic function is written as follows:
[0088]
[0089]
[0090] It can be seen that without comments, only 9 lines of code are needed to define the length characteristics of this protocol to implement the complete message extraction action.
[0091] Embodiment 2: FixedLengthFrameDecoder, using the technical solution of the present invention to process, then:
[0092] Assume that there is a fixed-length protocol with a length of 66, then:
[0093] The constructor passes in 66,
[0094] The protocol length characteristic function is written as follows:
[0095]
[0096]
[0097] It can be seen that under the same framework, the protocol length characteristic function corresponding to this protocol can be defined through a few lines of code, and the protocol parsing action can be successfully completed!
[0098] Embodiment 3: DelimiterBasedFrameDecoder, using the technical solution of the present invention to process, then:
[0099] Assuming that the delimiter here is \n, the user cannot perceive the specific length of the complete message in bytes, but it is certain that the length is greater than or equal to 1, so the constructor passes in parameter 1, indicating that 1 byte is expected to be read in the first round.
[0100] Even if any number of bytes are sent later, there is no guarantee that the \n delimiter will exist. For this special protocol format, the protocol length feature function is written as follows:
[0101]
[0102] The technical solution described in the invention can access various private protocols at a very low protocol access cost, and is also compatible with public protocols. The above embodiment uses the technical solution recorded in the present invention to implement the decoder that has been preset in the Netty framework. If the above implementation method is adopted, users can access various public / private protocols in a completely unified way, which improves the maintainability and robustness of the software, reduces the access cost, and thus generates greater economic value.
[0103] Embodiment 4: For complex multiple protocols, that is, when a private protocol carries multiple sets of protocol format codes, each set of protocol format codes is built into the transition(times, in, in.readerlndex()) protocol length feature function in turn, and multiple sets of associated decoders are generated in turn, the decoders are executed in turn, and the temporary decoding results are placed in the buffer, waiting for the call in the subsequent round of decoding. When all sets of protocol format codes are decoded, the final result is output.
[0104] For example, there is a private protocol format as follows:
[0105] 1) The first 4 bytes indicate the initial length
[0106] 2) After reading the bytes of the above length, determine whether the value of the 5th or 6th byte is "ab" or "cd". If it is the former, 1024 bytes need to be read again; if it is the latter, 2048 bytes need to be read again.
[0107] The code is written as follows:
[0108] The constructor passes in parameter 4, which means that 4 bytes are expected to be read in the first round.
[0109] The protocol length characteristic function is as follows:
[0110]
[0111]
[0112] During this process, if any decoder encounters an unexpected situation during decoding, the decoder will throw an exception or return a specific end mark.
[0113] This type of protocol does not have a preset decoder in the Netty framework. If the technical solution described in the present invention is not adopted, the only option is to recompile a corresponding decoder. It can be seen that even for complex protocols, by using the method proposed in the present invention, a simple protocol length feature function is filled in for each protocol, and the complete application layer message extraction based on the TCP stream can be completed. A large amount of repetitive underlying technical work has been encapsulated by the framework, and application layer developers only need to fill in the protocol length feature function for each protocol, which greatly reduces the access workload of the protocol. The decoder produced in this way greatly simplifies the message extraction process and improves the efficiency and accuracy of development.
[0114] The present invention also includes a storage device, which is used to store a computer program, and the computer program is used to execute a general method for extracting a complete message based on a protocol length feature function.
[0115] Although the present invention is disclosed as above with preferred embodiments, it is not intended to limit the scope of the present invention. Any person of ordinary skill in the art can make some improvements without departing from the scope of the present invention, that is, all equivalent improvements made in accordance with the present invention should be covered by the scope of the present invention. In the description of this specification, the description of reference terms "an embodiment / method", "some embodiments / methods", "examples", "specific examples", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment / method or example are included in at least one embodiment / method or example of the present application. In this specification, the schematic representation of the above terms does not necessarily target the same embodiment / method or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or more embodiments / methods or examples in a suitable manner. In addition, without contradicting each other, a person of ordinary skill in the art can combine and combine the different embodiments / methods or examples described in this specification and the features of different embodiments / methods or examples.
[0116] In addition, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Therefore, the features defined as "first" and "second" may explicitly or implicitly include at least one of the features. In the description of this application, the meaning of "plurality" is at least two, such as two, three, etc., unless otherwise clearly and specifically defined.
[0117] Those skilled in the art should understand that the above embodiments are only for the purpose of clearly illustrating the present disclosure, and are not intended to limit the scope of the present disclosure. For those skilled in the art, other changes or modifications may be made based on the above disclosure, and these changes or modifications are still within the scope of the present disclosure.
Claims
1. A general method for extracting complete messages based on protocol length feature function, based on Netty framework, characterized in that: The system abstract tool class AbstractByteToMessageDecoder is inherited from the base class ByteToMessageDecoder, and the general decoder is embedded in the Netty framework to define the constructor and initialize it. The parsing action of any protocol is abstracted into a general process through the constructor, and the protocol format code that distinguishes the private protocol is built into the transition(times, in, in.readerIndex()) protocol length feature function. When any new protocol is connected, the transition(times, in, in.readerlndex()) protocol length feature function is filled according to the length characteristics of the corresponding protocol to complete the decoder that meets the entire complete message extraction logic. The decoder is used to implement message extraction during operation.
2. A general method for extracting complete messages based on a protocol length characteristic function as described in claim 1, characterized in that: The specific structure of the constructor is: define and initialize the current decoding round number, the reserved initial round bytes to be read, and the number of bytes that need to wait to be read in the corresponding round. The constructor accepts an integer parameter length, which is used to initialize several key member variables of the class, and sets the reserved initial round bytes to be read and the number of bytes that need to wait to be read in the corresponding round to the passed in length parameter value.
3. A general method for extracting complete messages based on a protocol length characteristic function as described in claim 2, characterized in that: In the constructor, times is the current decoding round number; initialFrameLength is the reserved initial round bytes to be read; currentFrameLength is the number of bytes that need to wait to be read in the corresponding round, and times is initialized to 1. initialFrameLength and currentFrameLength are initialized to the passed length value.
4. A general method for extracting complete messages based on a protocol length characteristic function as described in claim 3, characterized in that: The initialFrameLength is a final variable, which indicates the length of the initial frame and cannot be changed. The currentFrameLength is used to indicate the length of the currently processed frame and can be modified during the object life cycle.
5. A general method for extracting complete messages based on a protocol length characteristic function as described in claim 1, characterized in that: The constructor uses a decoding framework to abstract the parsing action of any protocol into a general process. The decoding framework includes the following steps: S1: Initialization: Set currentFrameLength to initialFrameLength, which is the number of bytes expected to be read in the first round of decoding; S2: Decoding loop: Enter an infinite while(true) loop to continue decoding operations; S3: Check the number of readable bytes: In each round of decoding, first check whether the current number of readable bytes in.readableBytes() is less than the expected number of bytes in the current round, currentFrameLength; if it is less, it means that the data of the current round has not arrived completely, return null, and continue to read network data; S4: Data arrival processing: If the number of readable bytes reaches or exceeds the number of bytes expected in the current round, call the transition method and pass the current round times, input data in, and current reading position in.readerlndex() to the protocol length feature function; the transition method analyzes according to the protocol characteristics and returns the number of bytes newFrameLength expected for the next round of decoding; S5: Check newFrameLength to determine whether the decoding is finished, until a non-null ByteBuf is returned after a certain decoding is completed, or an instruction is received to force the loop to jump out.
6. A general method for extracting complete messages based on a protocol length characteristic function as described in claim 5, characterized in that: When determining whether decoding is finished in S5, if newFrameLength is not equal to the predefined end mark END, decoding is not finished yet and it is necessary to enter the next round. At this time, times is increased to indicate entering the next round of decoding, currentFrameLength is updated to newFrameLength, and the expected number of bytes to be read is set for the next round of decoding.
7. A general method for extracting complete messages based on a protocol length characteristic function as described in claim 5, characterized in that: When determining whether decoding is finished in S5, if newFrameLength is equal to the predefined end flag END, the current round of decoding is finished and the complete message has been read. A byte message with a length of currentFrameLength is read from the input data and stored in ByteBuf. Times is reset to 1 and currentFrameLength is reset to initialFrameLength to prepare for subsequent parsing. ByteBuf is returned, i.e., the complete message of this application layer.
8. A general method for extracting complete messages based on a protocol length characteristic function as described in claim 1, characterized in that: When a private protocol carries multiple sets of protocol format codes, each set of protocol format codes is built into the transition(times, in, in.readerlndex()) protocol length feature function in turn, and multiple sets of associated decoders are generated in turn. The decoders are executed in turn, and the temporary decoding results are placed in the buffer, waiting for the call in the subsequent round of decoding. When all sets of protocol format codes are decoded, the final result is output.
9. A general method for extracting complete messages based on a protocol length characteristic function as described in claim 8, characterized in that: If any decoder encounters an unexpected situation during the decoding process, the decoder will throw an exception or return a specific end mark.
10. A storage device, characterized in that: The storage device is used to store a computer program, and the computer program is used to execute the general method for extracting a complete message based on a protocol length feature function as described in any one of claims 1-9.