Protocol interaction method based on self-analysis description language

Abstract

The invention discloses a protocol interaction method based on a self-analysis description language, and belongs to the technical field of communication. According to the method, a general description format of the protocol is defined, the protocol is segmented and described by using a metadata thought, all protocols can be described by using self-description configuration, only one protocol processing unit is needed for self-analysis description, and analysis and identification of general description information are realized. According to the method, the abstraction degree is higher, the protocol is described by metadata, the protocol characteristics are not reflected, the method is not limited to appointing one or one kind of similar protocols and irregular concepts, and actions such as understanding, analysis and organization are carried out only according to self-description configuration file information. The method is higher in applicability, and is suitable for the analysis and organization process of all protocols which can be recognized by natural persons. According to the method, the development cost is saved, only one-time coding is needed, and only a new configuration file needs to be added to access a new protocol subsequently.

Description

Technical Field

[0001] The present invention relates to the field of communication technology, and in particular to a protocol interaction method based on a self-analyzing description language. Background Art

[0002] There are many extraction methods for protocol parsing at present. Most of them extract the features of a specific protocol or a group of similar protocols, define rules based on the protocol features, and perform parsing based on the rules. The scope of application is one or a group of similar protocols.

[0003] For multiple groups of similar protocols, the development process is as follows Figure 1 As shown, a group of similar protocols requires a corresponding protocol processing module. Multiple groups of similar protocols require multiple groups of protocol processing modules, which requires multiple development and debugging.

[0004] The current mainstream extraction and parsing methods for protocols are only applicable to the parsing of one or a group of similar protocols, and their applicability is low. The level of abstraction for the protocol is low, and only one or a group of similar protocols are abstracted to extract the same rules. The characteristics of the protocol still need to be considered during the coding process. When adding a new protocol, if it is not a similar protocol, the portability is poor and needs to be redeveloped. Summary of the invention

[0005] The present invention provides a protocol interaction method based on a self-parsing description language, which uses metadata to describe the protocol in segments. Only one protocol processing unit is required for the self-parsing description, and only one encoding is required, which saves development costs. When a new protocol is subsequently accessed, only a new configuration file needs to be added.

[0006] The present invention provides the following technical solutions:

[0007] A protocol interaction method based on a self-analyzing description language, the method comprising:

[0008] S10: splitting the protocol into multiple segments of metadata that can be described, understood and parsed, and decomposing the protocol into multiple understandable segments; the metadata includes a data segment of the protocol and self-descriptive information of the data segment;

[0009] S20: Define a description language and describe the protocol through a protocol self-description configuration file, so that the encoding is separated from the characteristics of the specific protocol;

[0010] S30: By using a protocol processing unit based on protocol self-description, the protocol metadata is understood according to the protocol self-description configuration file, thereby realizing understanding, parsing and organizing the protocol.

[0011] Furthermore, the self-description information includes the location, length, type, content, content source and response of the data segment.

[0012] Furthermore, if a new protocol needs to be accessed later, it is only necessary to add a new protocol self-describing configuration file.

[0013] Furthermore, the method further comprises:

[0014] S40: performing scheduled message sending, active message sending, and message receiving and processing through the protocol.

[0015] Furthermore, the message timing sending includes:

[0016] S401: Determine whether there is a scheduled message to be sent. If so, traverse each scheduled message to be sent to determine whether the sending time point has been reached;

[0017] S402: When the sending time point is reached, the message content is organized from top to bottom according to the template, and the message is sent.

[0018] Furthermore, the message actively sending includes:

[0019] S403: searching for a corresponding protocol template based on the protocol type according to the business requirements;

[0020] S404: Organize the message content from top to bottom according to the template, and send the message.

[0021] Furthermore, the message receiving and processing includes:

[0022] S405: receiving the message and putting it into a queue, performing message segmentation and message identification;

[0023] S406: Confirm the template of the received message according to the message identity field. If the received message is a response message, enter the response message processing process; if the received message is a request message, enter the request message processing process.

[0024] Furthermore, the request message processing process includes:

[0025] S 407: confirm the message identity, and perform message parsing and information extraction;

[0026] S408: Determine whether a service needs to be triggered. If so, trigger the corresponding service and execute S409. Otherwise, directly execute S409.

[0027] S409: Determine whether there is a reply confirmation request, and if so, organize and send the message according to the template and the request message.

[0028] Furthermore, the response message processing process includes:

[0029] S410: confirm the message identity and perform message analysis;

[0030] S411: Determine whether there is a service triggering requirement, and if so, trigger the corresponding service.

[0031] The present invention has the following beneficial effects:

[0032] In the present invention, a general protocol description format is defined, and the protocol is described in segments using the metadata concept. All protocols can be described using self-describing configurations. Only one protocol processing unit is required for self-analysis descriptions to achieve parsing and identification of general description information. The present invention has a higher level of abstraction. The protocol is described using metadata, does not reflect protocol features, is not limited to specifying one or a class of similar protocols, and has no concept of rules. It only needs to understand, parse, and organize based on the self-describing configuration file information. The present invention is more applicable and is suitable for the parsing and organization process of all protocols that can be identified by natural persons. The present invention saves development costs and only requires one-time coding. To subsequently access new protocols, only new configuration files need to be added. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] Figure 1 A schematic diagram of a protocol extraction and parsing method of the prior art;

[0034] Figure 2 It is a flow chart of the protocol interaction method based on the self-analysis description language of the present invention;

[0035] Figure 3 A schematic diagram of a protocol interaction method based on a self-analyzing description language of the present invention;

[0036] Figure 4 This is a schematic diagram of the protocol processing flow. DETAILED DESCRIPTION

[0037] In order to make the technical problems, technical solutions and advantages to be solved by the present invention more clear, a detailed description will be given below with reference to the accompanying drawings and specific embodiments.

[0038] The present invention provides a protocol interaction method based on a self-analyzing description language, such as Figure 2 As shown, the method includes:

[0039] S10: Split the protocol into multiple segments of metadata that can be described, understood and parsed, and decompose the protocol into multiple understandable segments; the metadata includes a data segment of the protocol and self-descriptive information of the data segment.

[0040] S20: Define a description language and describe the protocol through a protocol self-description configuration file, so that the encoding is independent of the characteristics of the specific protocol.

[0041] S30: By using a protocol processing unit based on protocol self-description, the protocol metadata is understood according to the protocol self-description configuration file, thereby realizing understanding, parsing and organizing the protocol.

[0042] In view of the low applicability of the current protocol extraction and analysis methods, the present invention abandons the idea of ​​extracting a rule set for the protocol features, introduces the concept of metadata, splits the protocol into describable, understandable and parseable metadata, decomposes the protocol into understandable segments, defines a description language, and describes the protocol, so that the encoding can be separated from the features of the specific protocol. The main process of the present invention is as follows: Figure 3 shown.

[0043] The metadata in the present invention is explained as follows: each segment of the protocol is split into metadata, which has a self-descriptive function for the segment of data, including the location, length, type, content, content source, response, etc. of the data segment. The understanding of metadata is realized in template parsing, and then the parsing and organization of the protocol is realized.

[0044] In the present invention, a general protocol description format is defined, and the protocol is described in segments using the metadata concept. All protocols can be described using self-describing configurations. Only one protocol processing unit is required for self-analysis descriptions to achieve parsing and identification of general description information. The present invention has a higher level of abstraction. The protocol is described using metadata, does not reflect protocol features, is not limited to specifying one or a class of similar protocols, and has no concept of rules. It only needs to understand, parse, and organize based on the self-describing configuration file information. The present invention is more applicable and is suitable for the parsing and organization process of all protocols that can be identified by natural persons. The present invention saves development costs and only requires one-time coding. To subsequently access new protocols, only new configuration files need to be added.

[0045] The present invention can realize datagram splitting, message identification, automatic message parsing, automatic organization, automatic response, and realize functions such as periodic message automatic organization and automatic sending. Figure 4 As shown, the method also includes:

[0046] S40: performing scheduled message sending (ie, scheduled message sending by the main body), active message sending (ie, active service sending), and message receiving and processing (ie, main body receiving) through the protocol.

[0047] The message timing sending includes:

[0048] S401: Determine whether there is a scheduled message to be sent. If so, traverse each scheduled message to be sent to determine whether the sending time point has been reached.

[0049] S402: When the sending time point is reached, the message content is organized from top to bottom according to the template, and the message is sent.

[0050] The process of organizing messages includes:

[0051] Organize messages from top to bottom.

[0052] Metadata organization: data source, data type, data length, etc.

[0053] Field data source: fixed, obtained by INFUC function; or self-adjusting (such as self-increment), field length and so on.

[0054] Explanation on INFUC function call: According to the mapping relationship between the name of INFUC_** and the function handle, call the corresponding function to obtain the value from the business layer.

[0055] The message actively sent includes:

[0056] S403: According to business requirements, the corresponding protocol template is searched based on the protocol type to locate the message identity.

[0057] S404: Organize the message content from top to bottom according to the template, and send the message.

[0058] The message organization in this step is similar to S402 and will not be described in detail.

[0059] The message receiving and processing includes:

[0060] S405: Receive the message and put it into the queue, perform message segmentation and message identification.

[0061] S406: Confirm the template of the received message according to the message identity field. If the received message is a response message (i.e. the received message matches the "response" corresponding to "active"), enter the response message processing process. If the received message is a request message (i.e. the received message matches "receive"), enter the request message processing process.

[0062] The request message processing process includes:

[0063] S 407: Confirm the message identity, and perform message parsing and information extraction.

[0064] S408: Determine whether a service needs to be triggered. If so, trigger the corresponding service and execute S409. Otherwise, directly execute S409.

[0065] S409: Determine whether there is a reply confirmation request, and if so, organize the message (the response message of receive) according to the template and the request message and send it.

[0066] The message organization in this step is similar to S402, except that the information source may be information from the corresponding request message (receive message).

[0067] The response message processing process includes:

[0068] S410: Confirm the message identity and perform message analysis.

[0069] S411: Determine whether there is a service triggering requirement, and if so, trigger the corresponding service.

[0070] The response message should confirm that active has been delivered, for example, there is identityFuc, which notifies the business layer to confirm after receiving the response. For the "response" of "active", cascading "response" can also be supported to achieve cascading interaction.

[0071] The following is a detailed description of the protocol self-description configuration file using a specific example:

[0072] Taking desc_0200.json as an example, briefly describe the description language definition.

[0073] desc_0200.json saves the configuration file in json format.

[0074] "split": message segmentation flag.

[0075] When the main body receives a data stream with sticky packets or half packets, it can first put the message into the queue and split it into a complete packet of data according to the delimiter.

[0076]

[0077] Use the above example to illustrate "split":

[0078] split: protocol split definition;

[0079] dateType: data type;

[0080] Endian: byte order little-endian is small endian and big-endian is big endian;

[0081] value: value;

[0082] "protocols": a set of message descriptions;

[0083] "schedule": the definition of the message sent regularly or periodically by the main body;

[0084] "receive": the entity receives the message;

[0085] "active": the entity actively sends messages;

[0086] "response": the response message of schedule|active|receive;

[0087] "identity": message identity;

[0088] Adapt the received protocol message template.

[0089]

[0090] Use the above example to illustrate "identity":

[0091] pos: character position;

[0092] dateType: data type;

[0093] value: value;

[0094] Indicates that if the 21st byte of the message is 0x09 and the 22nd byte is 0xE6, then the template is matched; "actionInterval": message sending interval;

[0095] "protocoltype": protocol name, which is available when the business layer directly maps the message template;

[0096] "protocolcontent": description of the message content, the content is represented by metadata.

[0097] Metadata mainly includes:

[0098] ″itemIndex″: metadata serial number, starting from 0;

[0099] ″itemDesc″: metadata description, for reading convenience only;

[0100] "byteLen": metadata byte length;

[0101] "endian": metadata byte order, which can be omitted if it is consistent with the protocol byte order;

[0102] "dateType": metadata type;

[0103] ″value_fixed″: metadata content, the content is fixed;

[0104] ″value_unfixed″: metadata content, the content is not fixed.

[0105] Here is an example of self-analyzing description language processing:

[0106] The description file desc_0200.json is taken as an example for explanation.

[0107] There are three demonstration messages in the description file.

[0108] The first one is the heartbeat message: the subject periodically sends a heartbeat; the object responds.

[0109] The second is the time synchronization message: the object sends a time synchronization request, the entity handles the business; the entity responds to the object.

[0110] The third one is that the subject actively sends a request and the object responds.

[0111] 1. The main body sends regularly

[0112] 1.1. Traverse the timed sending of reports

[0113] Traverse the description file desc_0200.json and find the message node that needs to be sent regularly.

[0114] [schedule] is a node for sending messages at a scheduled time.

[0115] 1.2. Organize the message content

[0116] When "itemIndex": 0, it is a header, and the content is fixed ("value_fixed": "0x5AA5"). Because of the little endian ("endian": "little-endian"), the sendBuffer is:

[0117] sendBuffer=A5 5A

[0118] When "itemIndex": 1, the node length is two bytes ("byteLen": 2), and the content is the length of node 6 ("value_unfixed": "SUMLEN[6,6]"), and the length of the node is 4, so the sendBuffer is:

[0119] sendBuffer=A5 5A 04 00.

[0120] When "itemIndex": 2, it is the device ID. By calling the business layer interface ("value_unfixed": "INFUC_DevId"), 17 bytes ("byteLen": 17,) length characters ("dateType": "string") are obtained. According to the demonstration example, the devID is "86281004999194501", so sendBuffer is:

[0121] sendBuffer=A5 5A 04 00 38 36 32 38 31 30 30 34 39 39 39 31 39 34 3530 31.

[0122] ″itemIndex″:3 and ″itemIndex″:4, the description length and content are fixed, so sendBuffer is:

[0123] sendBuffer=A5 5A 04 00 38 36 32 38 31 30 30 34 39 39 39 31 39 34 3530 31 09 E6.

[0124] When "itemIndex": 5, it is the frame number, which is an auto-increment type. According to the RISE function, the value obtained is 4, so sendBuffer is:

[0125] sendBuffer=A5 5A 04 00 38 36 32 38 31 30 30 34 39 39 39 31 39 34 3530 31 09 E6 04.

[0126] When "itemIndex": 6, the current time is obtained ("value_unfixed": "INFUC_CurTime"), and the current time is "2023-06-09 17:19:09". According to INFUC_CurTime, the current time in the century is 1,686,302,349, which is 0x6482EE8D in hexadecimal. Because it is in little endian order, sendBuffer is:

[0127] sendBuffer=A5 5A 04 00 38 36 32 38 31 30 30 34 39 39 39 31 39 34 3530 31 09 E6 04 8D EE 82 64.

[0128] When "itemIndex": 7, it is CRC16 checksum ("value_unfixed": "CRC16[1,6]"), and the checksum of nodes 1 to 6 is calculated, that is, "04 00 38 36 32 38 31 30 30 34 39 39 39 31 39 34 35 30 31 09 E6 048D EE 82 64", and the calculated value is 0xBF51. Because it is little endian, sendBuffer is:

[0129] sendBuffer=A5 5A 04 00 38 36 32 38 31 30 30 34 39 39 39 31 39 34 3530 31 09 E6 04 8D EE 82 64 51 BF.

[0130] When "itemIndex": 8, it is fixed content, so sendBuffer is:

[0131] sendBuffer=A5 5A 04 00 38 36 32 38 31 30 30 34 39 39 39 31 39 34 3530 31 09 E6 04 8D EE 82 64 51 BF 96.

[0132] 1.3. Send the message sendBuffer organized in 1.2.

[0133] 1.4 Periodic transmission

[0134] Sent every 60 seconds ("actionInterval":60).

[0135] 2. Business proactively sends

[0136] 2.1. Locating message identity

[0137] According to business needs, search for the corresponding protocol template based on "protocoltype".

[0138] 2.2. Organizing messages

[0139] Similar to 1.2, no further details are given.

[0140] 3. Receiving module (receive)

[0141] 3.1. Receive messages and put them into queue

[0142] 3.2. Split Message

[0143] Divide the message into a complete packet according to the node (split).

[0144] 3.3. Identifying messages

[0145] A template that confirms the received message based on the message identity field.

[0146] (1). If the received message matches "receive", go to step 4.

[0147] For example, the received message is "A5 5A 05 00 38 36 32 38 31 30 30 34 39 39 39 31 39 3435 30 31 03 A1 6F 01 4C EE 82 64 63 E8 96", and the message identity is identified as "receive" according to the template, and the process goes to step 4.

[0148] (2) If the received message matches the "response" corresponding to "active", go to step 5.

[0149] For example, the received message is "A5 5A 04 00 38 36 32 38 31 30 30 34 39 39 39 31 39 3435 30 31 0A E6 04 4C EE 82 64 AD B1 96", and the message identity is identified as "response" corresponding to "active" according to the template, so go to step 5.

[0150] 4.Receive response message

[0151] 4.1. Take the received message revBuffer="A5 5A 05 00 38 36 32 38 31 30 30 34 39 3939 31 39 34 35 30 31 03 A1 6F 01 4C EE 82 64 63 E8 96" as an example.

[0152] 4.2. Based on identity confirmation

[0153] The message is matched with the "receive" of "Monitoring device time query or setting and response" (identity: 0x03 0xA1).

[0154] 4.3. Parsing the message

[0155] Match the template from front to back, parse the message, and find the fields that interact with the business layer.

[0156] When "itemIndex":7, there is business layer interaction. The data flow direction needs to be determined based on the value of 6. The value of "itemIndex":6 is obtained from the message as 1, so OUTFUC_CurTime needs to be called to implement the time configuration function.

[0157] 4.4. Organizing Response Messages

[0158] Because the template corresponding to revBuffer has "response", the response message is organized according to the template.

[0159] ″itemIndex″:0~“itemIndex”:5 is similar to step 1 and will not be repeated here. sendBuffer is:

[0160] sendBuffer=A5 5A 05 00 38 36 32 38 31 30 30 34 39 39 39 31 39 34 3530 31 04 A1 05.

[0161] When "itemIndex": 6, the content is obtained from the revBuffer process ("&receive_FucRtn[7] = 0? 0xFF: 0x00"). Because the time is set successfully in the revBuffer process and 0 is returned, the expression is 0xFF, so sendBuffer is:

[0162] sendBuffer=A5 5A 05 00 38 36 32 38 31 30 30 34 39 39 39 31 39 34 3530 31 04A1 05 FF.

[0163] When "itemIndex":7, the business layer interface INFUC_CurTime("value_unfixed":"INFUC_CurTime") is called. The current time is 2023-06-09 17:18:04, and the corresponding century second is 1686302, 16 is 0x6482EE4C, little endian, so sendBuffer is:

[0164] sendBuffer=A5 5A 05 00 38 36 32 38 31 30 30 34 39 39 39 31 39 34 3530 31 04 A1 05 FF 4C EE 82 64.

[0165] When "itemIndex": 8, CRC16 checksum is used to calculate the checksum of "05 00 38 36 32 38 31 30 30 34 39 39 3931 39 34 35 30 31 04 A1 05 FF 4C EE 82 64": 0x895B, little endian, so sendBuffer is:

[0166] sendBuffer=A5 5A 05 00 38 36 32 38 31 30 30 34 39 39 39 31 39 34 3530 31 04 A1 05 FF 4C EE 82 64 5B 89.

[0167] When "itemIndex": 9, it is fixed content, so the buffer is:

[0168] sendBuffer=A5 5A 05 00 38 36 32 38 31 30 30 34 39 39 39 31 39 34 3530 31 04 A1 05 FF 4C EE 82 64 5B 89 96.

[0169] 4.5. Message sending

[0170] 5.active response message

[0171] 4.1. Take the received message revBuffer="A5 5A 04 00 38 36 32 38 31 30 30 34 39 3939 31 39 34 35 30 31 0A E6 04 4C EE 82 64 AD B1 96" (heartbeat response message) as an example.

[0172] 5.2. Based on identity confirmation

[0173] The message is matched with the "response" of "Active reporting and response of heartbeat" (identity: 0x0A0xE6).

[0174] 5.3. Parsing the message

[0175] Match the template from front to back, parse the message, and find the fields that interact with the business layer. If not found, no processing is done. For the sake of rigor, the legitimacy of the message can also be judged, such as the legitimacy of the check value.

[0176] Determine whether there is an identity confirmation function ("identityFuc":"OUTFUC_BeatingResponse"), and call OUTFUC_BeatingResponse to notify the business layer that a response to the heartbeat message has been received.

[0177] The above is a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.

Claims

1. A protocol interaction method based on a self-analyzing description language, characterized in that: The method comprises: S10: splitting the protocol into multiple segments of metadata that can be described, understood and parsed, and decomposing the protocol into multiple understandable segments; the metadata includes a data segment of the protocol and self-descriptive information of the data segment; S20: Define a description language and describe the protocol through a protocol self-description configuration file, so that the encoding is separated from the characteristics of the specific protocol; S30: By using a protocol processing unit based on protocol self-description, the protocol metadata is understood according to the protocol self-description configuration file, thereby realizing understanding, parsing and organizing the protocol.

2. The protocol interaction method based on the self-analyzing description language according to claim 1 is characterized in that: The self-description information includes the location, length, type, content, content source and response of the data segment.

3. The protocol interaction method based on the self-analyzing description language according to claim 1 or 2, characterized in that: If you need to access a new protocol later, you only need to add a new protocol self-describing configuration file.

4. The protocol interaction method based on the self-analyzing description language according to claim 3 is characterized in that: The method further comprises: S40: performing scheduled message sending, active message sending, and message receiving and processing through the protocol.

5. The protocol interaction method based on the self-analyzing description language according to claim 4 is characterized in that: The message timing sending includes: S401: Determine whether there is a scheduled message to be sent. If so, traverse each scheduled message to be sent to determine whether the sending time point has been reached; S402: When the sending time point is reached, the message content is organized from top to bottom according to the template, and the message is sent.

6. The protocol interaction method based on the self-analyzing description language according to claim 5 is characterized in that: The message actively sent includes: S403: searching for a corresponding protocol template based on the protocol type according to the business requirements; S404: Organize the message content from top to bottom according to the template, and send the message.

7. The protocol interaction method based on the self-analyzing description language according to claim 6 is characterized in that: The message receiving and processing includes: S405: receiving the message and putting it into a queue, performing message segmentation and message identification; S406: Confirm the template of the received message according to the message identity field. If the received message is a response message, enter the response message processing process; if the received message is a request message, enter the request message processing process.

8. The protocol interaction method based on the self-analyzing description language according to claim 7 is characterized in that: The request message processing process includes: S 407: confirm the message identity, and perform message parsing and information extraction; S408: Determine whether a service needs to be triggered. If so, trigger the corresponding service and execute S409. Otherwise, directly execute S409. S409: Determine whether there is a reply confirmation request, and if so, organize and send the message according to the template and the request message.

9. The protocol interaction method based on the self-analyzing description language according to claim 8, characterized in that: The response message processing process includes: S410: confirm the message identity and perform message analysis; S411: Determine whether there is a service triggering requirement, and if so, trigger the corresponding service.

Images