Method and apparatus for coexistence of multi-version data protocols

Abstract

The application discloses a method and device for coexistence and co-use of multi-version data protocols, and belongs to the field of communication technology.The method comprises the following steps: setting a version node under a root node in a protocol configuration file, the attribute of the version node comprising a protocol version number, and the version node comprising one or more protocol nodes; loading the configuration file when software starts, setting a data storage area of the protocol and a default protocol version based on the version node in the configuration file; when data is sent, encapsulating the data to be sent into a data frame based on the currently used protocol version; when data is received, obtaining the protocol version number of the received data frame by parsing the frame header of the data frame, and selecting a corresponding protocol parser to parse the data in the data frame according to the protocol version number.The method of the application can flexibly switch the protocol version without restarting, and ensures the continuity during the task.

Description

TECHNICAL FIELD

[0001] The present application belongs to the technical field of communication, in particular to a method and device for coexistence and sharing of multi-version data protocols. BACKGROUND

[0002] When real-time monitoring of network data is required, the communication protocols between software usually need to be consistent in version to ensure the accuracy of data reception and transmission. If the protocols between software in the system are inconsistent, it may cause problems such as abnormal data display and abnormal instruction setting, which seriously affects the accuracy of protocol data.

[0003] The traditional solution is to design the software loading protocol in the software design stage into a flexible and configurable manner, for example, by loading different protocol configuration files to support different protocols. However, this method can only support a single version of protocol, and if different versions of protocol need to be switched, the corresponding version of protocol configuration file needs to be replaced. If the software does not have the function of reloading the configuration file, the software needs to be restarted to achieve the effect of protocol update, which affects the continuity during data monitoring. SUMMARY

[0004] The purpose of the present application is to overcome the shortcomings of the prior art and provide a method and device for coexistence and sharing of multi-version data protocols, which can flexibly switch protocol versions without restarting, ensuring the continuity during the task.

[0005] The present application is implemented by the following technical solutions:

[0006] The first aspect of the present application discloses a method for coexistence and sharing of multi-version data protocols, comprising:

[0007] Setting a version node under the root node in the protocol configuration file, the attribute of the version node including a protocol version number, and the version node including one or more protocol nodes;

[0008] Loading the configuration file when the software starts, setting the data storage area and the default protocol version of the protocol based on the version node in the configuration file;

[0009] When sending data, encapsulating the data to be sent into a data frame based on the currently used protocol version;

[0010] When receiving data, parsing the frame header of the received data frame to obtain its protocol version number, and selecting a corresponding protocol parser to parse the data in the data frame according to the protocol version number.

[0011] Further, the protocol names of all protocols under the same version node are different.

[0012] Further, setting the data storage area of the protocol and the default protocol version based on the version node in the configuration file comprises:

[0013] reading the configuration file, and parsing the version node in the configuration file to obtain a protocol version number;

[0014] creating a separate data storage area for each protocol version;

[0015] setting the default protocol version.

[0016] Further, setting the data storage area of the protocol and the default protocol version based on the version node in the configuration file further comprises:

[0017] storing the data storage area in a hash table, wherein the key of the hash table is the protocol version number, and the value of the hash table is the corresponding data storage area.

[0018] Further, setting the default protocol version comprises:

[0019] determining whether a pre-set protocol version number exists in a default version field in the configuration file, if yes, taking the protocol version corresponding to the protocol version number as the default protocol version, and if not, taking the first protocol version in the configuration file as the default version.

[0020] Further, after the software is started, if a user specifies a protocol version, the currently used protocol version is the protocol version newly specified by the user, and if the user does not specify a protocol version, the currently used protocol version is the default protocol version.

[0021] Further, the frame header of the data frame comprises: a frame identification code, a message source identifier, a message destination identifier, a message type, a message sending time, a main version number field, a sub-version number field, a protocol name of a message payload, and a total length of the message.

[0022] Further, the encapsulation process of the data frame comprises:

[0023] creating an empty frame header structure, and filling the frame identification code, the message source identifier, and the message destination identifier;

[0024] setting the main version number and the sub-version number in the frame header according to the currently used protocol version;

[0025] filling a frame header information field in the frame header, the frame header information field comprising the message type and the message sending time;

[0026] adding the protocol name of the message payload and the total length of the message in the frame header;

[0027] encapsulating the frame header and the data to be sent together to form a complete data frame.

[0028] Further, the frame header of the received data frame is parsed to obtain the protocol version number thereof, and a corresponding protocol parser is selected according to the protocol version number to parse the data in the data frame, including:

[0029] Each field in the frame header of the data frame is parsed, and the protocol version number is extracted from the frame header;

[0030] The data in the data frame is stored in a corresponding data storage area according to the protocol version number;

[0031] The data in the data frame is parsed by a corresponding protocol parser according to the protocol version number.

[0032] The second aspect of the application discloses a device for coexistence and sharing of multiple version data protocols, comprising:

[0033] The configuration file setting module is configured to set a version node under a root node in a protocol configuration file, the attribute of the version node including a protocol version number, and the version node including one or more protocol nodes;

[0034] The configuration file loading module is configured to load the configuration file when the software starts, and set the data storage area and the default protocol version of the protocol based on the version node in the configuration file;

[0035] The data sending module is configured to encapsulate the data to be sent into a data frame based on the currently used protocol version when sending data;

[0036] The data receiving module is configured to parse the frame header of the received data frame to obtain the protocol version number thereof, and select a corresponding protocol parser to parse the data in the data frame according to the protocol version number.

[0037] Compared with the prior art, the application has the following advantages and beneficial effects:

[0038] (1) The application proposes a method for coexistence and sharing of multiple version data protocols, which supports the coexistence of multiple version protocol file contents by introducing a version node in a configuration file, the version node containing an attribute representing a protocol version number, and each version node having multiple protocol nodes thereunder, by parsing these configuration files, different versions of protocol files can be loaded and managed, and data transmission and parsing can be performed according to the version specified by the user, thereby realizing the coexistence and use of multiple versions of protocols, seamlessly switching protocol versions without the need for restarting, reducing errors caused by frequent updating of protocol configuration files, improving the continuity and stability of data acquisition, and simplifying the software maintenance process;

[0039] (2) The application can identify the protocol version used by each data packet during data transmission by adding the main version number and sub-version number fields in the custom frame header, thereby ensuring that the receiving end can correctly parse the data according to the version information, and this design enables flexible switching of the protocol version without restarting the software, thereby ensuring the continuity during the task;

[0040] (3) The user can specify the currently effective protocol version through the provided interface in the application, thereby realizing the function of dynamically switching the protocol version during runtime, and this design not only simplifies the management of the protocol version, but also improves the flexibility and reliability of the protocol switching;

[0041] (4) The application allocates independent data storage areas for each version of the protocol, and uses a hash table or other data structure for indexing and management, thereby ensuring that data of different versions will not overlap, so as to dynamically select and use the protocol data of a specific version during runtime, thereby supporting the coexistence and sharing of multiple versions of the protocol;

[0042] (5) In the application, after receiving the data frame, the version number field in the custom frame header is first parsed, then the corresponding data storage area is located according to the version number, and the data is parsed using the corresponding protocol format, thereby ensuring that the data of different versions of the protocol can be correctly processed, and avoiding data parsing errors caused by inconsistent protocol versions;

[0043] (6) The structure of the configuration file in the application enables the data to quickly roll back to the old version when encountering a new version problem, thereby further improving the reliability and fault tolerance of the protocol data parsing. BRIEF DESCRIPTION OF DRAWINGS

[0044] The accompanying drawings, which are included to provide a further understanding of the embodiments of the application and constitute a part of this application, do not constitute a limitation on the embodiments of the application. In the drawings:

[0045] Figure 1 A flowchart of a method for coexistence and sharing of multiple versions of data protocol in the application;

[0046] Figure 2 A structure diagram of a configuration file in the application;

[0047] Figure 3 A flowchart of configuration file loading in the application;

[0048] Figure 4 A flowchart of creating a data storage area in the application;

[0049] Figure 5 A flowchart of processing multiple versions of protocol data in the application;

[0050] Figure 6 A timing diagram for loading configuration files and managing multi-version protocols in the application;

[0051] Figure 7 A flow chart for data frame generation process in the application;

[0052] Figure 8 A data parsing flow chart based on version number in the application;

[0053] Figure 9 A timing diagram for data frame parsing process in the application;

[0054] Figure 10 A timing diagram for multi-version protocol data parsing in the application;

[0055] Figure 11 A timing diagram for data storage process based on version number in the application. DETAILED DESCRIPTION

[0056] The technical solutions of the application will be further described below in combination with the drawings and through specific embodiments.

[0057] In the drawings, only for exemplary illustration, the representations are only schematic diagrams, not physical diagrams, and cannot be understood as limitations of the application; in order to better illustrate the embodiments of the application, some components in the drawings will be omitted, enlarged or reduced, and do not represent the size of the actual product; for those skilled in the art, it is understandable that some well-known structures and their descriptions in the drawings can be omitted.

[0058] The same or similar reference numerals in the drawings of the embodiments of the application correspond to the same or similar components; in the description of the application, it should be understood that if the terms "upper", "lower", "left", "right", "inner", "outer" and the like indicate the orientation or positional relationship shown in the drawings, only for the convenience of describing the application and simplifying the description, and do not indicate or imply that the devices or elements referred to must have a particular orientation, be constructed and operated in a particular orientation, therefore the terms describing the positional relationship in the drawings are only used for exemplary illustration, and cannot be understood as limitations of the application, for those skilled in the art, the specific meaning of the above terms can be understood according to the specific circumstances.

[0059] In the description of the present application, unless otherwise explicitly specified and limited, if the term "connection" and the like appear to indicate the connection relationship between components, the term should be understood broadly, for example, it can be fixedly connected, or it can be detachably connected, or it can be integrated; it can be mechanically connected, or it can be electrically connected; it can be directly connected, or it can be indirectly connected through an intermediate medium; it can be the internal communication of two components or the interaction relationship between two components. For those skilled in the art, the specific meaning of the above-mentioned terms in the present application can be understood according to the specific circumstances.

[0060] As shown in Figures 1 to 11 , the embodiment discloses a method and device for coexistence and sharing of multi-version data protocols.

[0061] The first aspect of the embodiment discloses a method for coexistence and sharing of multi-version data protocols, as shown in Figure 1 , the method comprises steps S100 to S500.

[0062] Step S100. Set a version node under a root node in a protocol configuration file, the attribute of the version node includes a protocol version number, and the version node includes one or more protocol nodes.

[0063] The version node is one of the top-level nodes in the configuration file, and is used to identify different protocol versions; the protocol node is a child node of the version node, and is used to define specific protocol content.

[0064] The protocol version number includes a major version number and a minor version number. For example, the name of the version node is "version", and the attribute thereof includes a major version number and a minor version number, such as "version="1.0" ".

[0065] In the embodiment, there is one or more protocol nodes under one version node, and the protocol names of all protocols under one version node are different, that is, the same protocol name is not allowed to exist under one version node, and the same protocol name can exist under different version nodes.

[0066] In some embodiments of the embodiment, the configuration file adopts a format such as XML or JSON.

[0067] Figure 2 The structure of the multi-version protocol configuration file is shown, as Figure 2As shown, the configuration file (Config) contains one or more version nodes (Version), each version node contains a version number (Version id), and one or more protocol nodes (Protocol). Each protocol node contains a protocol name (protocol name), and one or more fields (Field), each field contains a field name (field name) and type (type), the structure of the configuration file allows different versions of the protocol to coexist, and can be flexibly managed and used.

[0068] The following is an example configuration file, showing how to organize the content of multi-version protocol:

[0069] xml

[0070] <config>

[0071] <version id="1.0">

[0072] <protocol name="data_transfer">

[0073] <field name="source_id" type="int" / >

[0074] <field name="destination_id" type="int" / >

[0075] <field name="payload" type="string" / >

[0076] < / protocol>

[0077] <protocol name="command_control">

[0078] <field name="command" type="string" / >

[0079] <field name="parameters" type="list" / >

[0080] < / protocol>

[0081] < / version>

[0082] <version id="2.0">

[0083] <protocol name="data_transfer">

[0084] <field name="source_id" type="int" / >

[0085] <field name="destination_id" type="int" / >

[0086] <field name="timestamp" type="long" / >

[0087] <field name="payload" type="string" / >

[0088] < / protocol>

[0089] <protocol name="command_control">

[0090] <field name="command" type="string" / >

[0091] <field name="parameters" type="map" / >

[0092] < / protocol>

[0093] < / version>

[0094] < / config>

[0095] There are two version nodes in the configuration file, corresponding to the "1.0" and "2.0" versions of the protocol respectively. The version node of the "1.0" version has two protocols with the protocol names data_transfer and command_control; the protocol with the protocol name data_transfer contains three fields: source_id, destination_id, and payload, the type of the field source_id is int, the type of the field destination_id is int, and the type of the field payload is string; the protocol named command_control contains two fields: command and parameters, the type of the field command is string, and the type of the field parameters is list. The version node of the "2.0" version has two protocols with the protocol names data_transfer and command_control; the protocol with the protocol name data_transfer contains four fields: source_id, destination_id, timestamp, and payload, the type of the field source_id is int, the type of the field destination_id is int, the type of the field timestamp is long, and the type of the field payload is string; the protocol named command_control contains two fields: command and parameters, the type of the field command is string, and the type of the field parameters is map.

[0096] Step S200. Load the configuration file at software startup, set the data storage area of the protocol based on the version node in the configuration file, and set the default protocol version.

[0097] In some embodiments of the present embodiment, as shown in Figure 3 the process of setting the data storage area of the protocol based on the version node in the configuration file and setting the default protocol version includes steps S210 to S230.

[0098] Step S210. Read the configuration file, and parse the version node in the configuration file to obtain the protocol version number.

[0099] In the present embodiment, the protocol version number is extracted by reading the attribute of each version node, and the extracted protocol version number is stored in a version list. The user can obtain all the protocol version numbers in the configuration file by calling the interface for obtaining the protocol version, so that the user can know all the version numbers supported in the configuration file, thereby specifying a version number as the basis for data parsing.

[0100] Step S220. Create a separate data storage area for each protocol version.

[0101] Specifically, if there is only one protocol version, a single data storage area is created; if there are multiple protocol versions, multiple data storage areas are created, and the protocol version and the data storage area correspond one by one.

[0102] Each data storage area in the present embodiment has a unique identifier (for example, the protocol version number (which is not repeated) is used as the unique identifier of the data storage area), and is stored in a global data structure (for example, the global data structure is a hash table, and the unique identifier of the data storage area is used as the key value of the hash table).

[0103] In some embodiments of the present embodiment, the data storage areas are indexed and managed by a hash table or other data structure according to the area name, so that data of different versions can be correctly processed. When the hash table is used to index and manage the data storage areas, the key of the hash table is the protocol version number, and the value of the hash table is the corresponding data storage area. Figure 4 The process of creating data storage areas of different protocol versions according to the version node in the configuration file is shown: first, the version node in the configuration file is read, and then the version node is parsed to obtain the version information of the protocol; then, a separate data storage area is created for each protocol version, and is stored in a global hash table, wherein the key of the hash table is the version number, and the value of the hash table is the corresponding data storage area.

[0104] For example, it is assumed that there are two versions of the protocol in the configuration file:

[0105] Version 1.0

[0106] Version 2.0

[0107] Two separate data storage areas are created for each protocol version and stored in a hash table with key values of "1.0" and "2.0" respectively.

[0108] In this embodiment, a separate data storage area is allocated in memory for each version of the protocol, ensuring that data from different versions does not overwrite each other.

[0109] For example, there is a configuration file containing the following content:

[0110] xml

[0111] <config>

[0112] <version version_id="1.0">

[0113] <protocol name="ProtocolA" / >

[0114] <protocol name="ProtocolB" / >

[0115] < / version>

[0116] <version version_id="2.0">

[0117] <protocol name="ProtocolA" / >

[0118] <protocol name="ProtocolC" / >

[0119] < / version>

[0120] < / config>

[0121] When loading this configuration file, two data storage areas are created:

[0122] "1.0": Contains `ProtocolA` and `ProtocolB`

[0123] "2.0": Contains `ProtocolA` and `ProtocolC`

[0124] When a protocol message is received, assuming the version number in its custom frame header is "1.0", the data of the message is stored in the data area of version "1.0". If the version number is "2.0", the data of the message is stored in the data area of version "2.0".

[0125] This embodiment effectively manages and isolates protocol data from different versions by creating separate data storage areas for each protocol version, ensuring data accuracy and monitoring stability.

[0126] Step S230. Set the default protocol version.

[0127] In some embodiments of this embodiment, setting the default protocol version includes: judging whether there is a pre-set protocol version number in the default version field ("default_version" field) in the configuration file, if yes, taking the protocol version corresponding to the protocol version number as the default protocol version, otherwise taking the first protocol version in the configuration file as the default version.

[0128] The user can set the protocol version number to be applied through a pre-created effective version interface, store the set protocol version number to a "default_version" field in the configuration file, and read the field as the default version next time the software is started. If the user does not set the protocol version number, the first protocol version in the configuration file is determined as the default version.

[0129] Step S300. When sending data, the data to be sent is encapsulated into a data frame based on the currently used protocol version.

[0130] After the software is started, if the user specifies a protocol version, the currently used protocol version is the protocol version newly specified by the user, and if the user does not specify a protocol version, the currently used protocol version is the default protocol version.

[0131] The user specifies the protocol version in the following manner: the user obtains all the protocol versions in the current configuration file, if the user required protocol version exists in all the protocol versions, the user inputs the specified protocol version number by calling a specified protocol version interface, and the software receives the protocol version number and modifies the attribute value of the "default_version" field to the specified protocol version.

[0132] In the embodiment, the user can specify the currently used protocol version, which ensures dynamic switching of the protocol version at runtime and improves the flexibility and reliability of data transmission.

[0133] Figure 5 and Figure 6 The multi-version protocol data processing flow is shown: first, a configuration file is loaded, a version node in the configuration file is parsed, a protocol version number is extracted, and version information is stored; if the user specifies a protocol version, the specified protocol version is used for data encapsulation and transmission, otherwise, the default protocol version is used for data encapsulation and transmission.

[0134] In the embodiment, a main version number field and a sub-version number field are set in the frame header of the data frame, and the main version number field and the sub-version number field are respectively used to indicate the main version and the sub-version of the protocol. For example, the main version number can indicate the main update of the protocol, and the sub-version number can indicate the sub-update or patch.

[0135] In some embodiments of the embodiment, the frame header of the data frame includes: a frame identification code (2 bytes), a message source identification (32 bytes), a message destination identification (32 bytes), a message type (1 byte), a message sending time (16 bytes), a main version number field (1 byte), a sub-version number field (1 byte), a protocol name of a message load (32 bytes), and a total length of the message (4 bytes).

[0136] In some embodiments of the present embodiment, as shown in Figure 7 the encapsulation process of the data frame includes steps S310 to S350.

[0137] Step S310. Initialize the frame header: create an empty frame header structure and fill in basic information such as frame identification, message source identification, message destination identification, etc.

[0138] Step S320. Set the version number: set the version number in the frame header according to the currently used protocol version, i.e. set the main version number and sub-version number fields in the frame header.

[0139] Step S330. Fill in other fields: fill in the frame header information field in the frame header, which includes message type and message sending time fields, etc.

[0140] Step S340. Add protocol name and message length: add the protocol name of the message payload and the total length of the message in the frame header.

[0141] Step S350. Encapsulate data: encapsulate the frame header with the data to be sent together to form a complete data frame.

[0142] Step S400. When receiving data, parse the frame header of the received data frame to obtain its protocol version number, and select the corresponding protocol parser to parse the data in the data frame according to the protocol version number.

[0143] As shown in Figure 8 , Figure 9 and Figure 10 When a protocol message is received, first parse each field in the frame header of the data frame, extract the main version number and sub-version number fields from the frame header to determine the protocol version used in the data frame, then store the data in the data frame into the data storage area of the corresponding protocol version according to the protocol version, and then select the corresponding protocol parser to parse the data, extract the useful information, and give the parsed data to the corresponding module for further processing.

[0144] Each protocol version has a corresponding protocol parser, and the protocol parser is stored in the memory.

[0145] For example, the data frame with version number 1.2 has a main version number of 1 and a sub-version number of 2.

[0146] For example, there are two versions of the protocol: V1.0 and V2.0. The major version number of V1.0 is 1 and the minor version number is 0; the major version number of V2.0 is 2 and the minor version number is 0. When the sender sends data using the V1.0 protocol, the major version number field in the frame header is set to 1 and the minor version number field is set to 0; after the receiver receives the data frame, it parses the major version number and the minor version number in the frame header and finds that it is 1.0, so it uses the V1.0 parser to parse. If the sender switches to the V2.0 protocol, the major version number field in the frame header is set to 2 and the minor version number field is set to 0; after the receiver receives the data frame, it parses the major version number and the minor version number in the frame header and finds that it is 2.0, so it uses the V2.0 parser to parse.

[0147] The embodiment designs the structures of the configuration file and the data frame, selects the corresponding protocol parser based on the protocol version of the data to parse the data, can flexibly switch the protocol version without restarting the software, and ensures the accuracy of data transmission and the continuity of data.

[0148] Figure 11 The process of storing data into the data storage area of the corresponding version according to the version number information in the custom frame header after receiving the protocol message is described: first, read and parse the version number information in the custom frame header, then store the data into the corresponding data storage area according to the version number, and the data storage area returns the confirmation information of successful storage.

[0149] In the embodiment, once the data storage area is determined, the data is parsed using the protocol format of the version. For example, there is a version 1.0 protocol, and its data format is as follows:

[0150] Message type (1 byte)

[0151] Message length (4 bytes)

[0152] Message content (variable length)

[0153] For the version 1.1 protocol, its data format may be slightly different:

[0154] Message type (1 byte)

[0155] Message length (4 bytes)

[0156] Timestamp (8 bytes)

[0157] Message content (variable length)

[0158] The method of this embodiment selects the correct protocol parser according to the version number, and then parses the data using the protocol parser. For example, if a version 1.0 data frame is received, the timestamp field is ignored and the message type and message content are directly parsed; if it is a version 1.1 data frame, all fields, including the timestamp, are parsed.

[0159] For example, there is a data frame with the version number field in the custom frame header as 1.1. After receiving this data frame, the following steps are performed: parsing the version number field in the frame header to obtain the major version number as 1 and the minor version number as 1; finding the data storage area of version 1.1 from the global data structure; parsing the data using the protocol format of version 1.1 to extract the message type, message length, timestamp, and message content. In this way, different versions of data frames can be flexibly processed, ensuring correct data parsing and stable software operation.

[0160] The method of this embodiment is described below with an example. For example, a typical configuration file structure is as follows:

[0161] xml

[0162] <config>

[0163] <version id="1.0">

[0164] <protocol name="A" / >

[0165] <protocol name="B" / >

[0166] < / version>

[0167] <version id="2.0">

[0168] <protocol name="A" / >

[0169] <protocol name="C" / >

[0170] < / version>

[0171] < / config>

[0172] When parsing this configuration file, all version nodes are traversed, and the protocol information (including protocol version number and protocol name) in each version node is stored in an internal data structure, such as a hash table.

[0173] Once the configuration file is successfully parsed, a version list is generated, which contains all identified protocol versions. Users can obtain this list by calling the `getAvailableVersions()` method. For example, assuming that the above configuration file is parsed, the generated version list may be as follows: 1.0

[0175] 2.0.

[0176] The method for setting the default protocol version is `setDefaultVersion(String versionId)`. Users can call this method to specify the protocol version they want to use. For example, if the user wants to use version 2.0 as the default version, the following code can be executed:

[0177] java

[0178] virtualBus.setDefaultVersion("2.0")。

[0179] The set default protocol version is saved in the default_version field in the configuration file, so that the version is automatically used next time the software is started.

[0180] In addition to setting the default version, the method of the embodiment also allows the user to dynamically specify the protocol version when sending or receiving data. Thus, even if a default version has been set, the user can still select a different version for a particular operation. For example, when sending a message, the user can choose to use version 1.0 instead of the default 2.0:

[0181] java

[0182] Message message = new Message();

[0183] message.setProtocolVersion("1.0");

[0184] virtualBus.sendMessage(message).

[0185] Similarly, when receiving data, the method of the embodiment determines which version of the protocol to use for parsing based on the version information in the received message.

[0186] A second aspect of the embodiment discloses an apparatus for coexistence and sharing of multiple versions of a data protocol, comprising a configuration file setting module, a configuration file loading module, a data sending module and a data receiving module.

[0187] The configuration file setting module is configured to set a version node under a root node in a protocol configuration file, the attribute of the version node including a protocol version number, and the version node including one or more protocol nodes.

[0188] The configuration file loading module is configured to load the configuration file when the software is started, and set a data storage area of the protocol and a default protocol version based on the version node in the configuration file.

[0189] The data sending module is configured to, when sending data, encapsulate the data to be sent into a data frame based on the currently used protocol version.

[0190] The data receiving module is configured to, when receiving data, parse the frame header of the received data frame to obtain the protocol version number thereof, and select a corresponding protocol parser to parse the data in the data frame according to the protocol version number.

[0191] The above detailed description of the specific embodiments of the present application has been given to understand the purpose, technical solutions and beneficial effects of the present application. It should be understood that the above description is only a specific embodiment of the present application and is not used to limit the protection scope of the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A method for multi-version data protocol coexistence coexistence, characterized in that, The application comprises the following steps: A version node is set under a root node in a protocol configuration file, the attribute of the version node comprises a protocol version number, and the version node comprises one or more protocol nodes; A configuration file is loaded when software starts, a data storage area of a protocol and a default protocol version are set based on the version node in the configuration file; When data is sent, the data to be sent is encapsulated into a data frame based on a currently used protocol version; When data is received, a frame header of the received data frame is parsed to obtain a protocol version number thereof, and a corresponding protocol parser is selected according to the protocol version number to parse the data in the data frame.

2. The method of claim 1, wherein, The protocol names of all protocols under the same version node are different.

3. The method of claim 1, wherein, The data storage area of the protocol and the default protocol version are set based on the version node in the configuration file, which comprises the following steps: A configuration file is read, and a protocol version number is obtained by parsing the version node in the configuration file; An independent data storage area is respectively created for each protocol version; The default protocol version is set.

4. The method of claim 3, wherein, The data storage area of the protocol and the default protocol version are set based on the version node in the configuration file, which further comprises the following steps: The data storage area is stored in a hash table, wherein the key of the hash table is the protocol version number, and the value of the hash table is the corresponding data storage area.

5. The method of claim 3, wherein, The default protocol version is set, which comprises the following steps: It is judged whether a pre-set protocol version number exists in a default version field in the configuration file, if yes, the protocol version corresponding to the protocol version number is taken as the default protocol version, and if not, the first protocol version in the configuration file is taken as the default version.

6. The method of claim 1, wherein, After the software starts, if a protocol version is specified by a user, the currently used protocol version is the latest protocol version specified by the user, and if no protocol version is specified by the user, the currently used protocol version is the default protocol version.

7. The method of claim 1, wherein, The frame header of the data frame comprises a frame identification code, a message source identifier, a message destination identifier, a message type, a message sending time, a main version number field, a sub-version number field, a protocol name of a message payload and a total length of the message.

8. The method of claim 1, wherein, The encapsulation process of the data frame comprises the following steps: An empty frame header structure is created, and the frame identification code, the message source identifier and the message destination identifier are filled in; The main version number and the sub-version number are set in the frame header according to the currently used protocol version; The frame header information field is filled in the frame header, the frame header information field comprises the message type and the message sending time; The protocol name of the message payload and the total length of the message are added in the frame header; The frame header and the data to be sent are encapsulated together to form a complete data frame.

9. The method of claim 1, wherein, The frame header of the received data frame is parsed to obtain the protocol version number thereof, and a corresponding protocol parser is selected according to the protocol version number to parse the data in the data frame, which comprises the following steps: Each field in the frame header of the data frame is parsed, and the protocol version number is extracted from the frame header; The data in the data frame is stored in the corresponding data storage area according to the protocol version number; The corresponding protocol parser is selected according to the protocol version number to parse the data in the data frame.

10. An apparatus for multi-version data protocol coexistence coexistence, the apparatus comprising: The application comprises the following steps: A configuration file setting module is configured to set a version node under a root node in a protocol configuration file, the attribute of the version node comprises a protocol version number, and the version node comprises one or more protocol nodes; The configuration file loading module is configured to load a configuration file when the software starts, set a data storage area of a protocol and a default protocol version based on a version node in the configuration file; The data sending module is configured to encapsulate data to be sent into a data frame based on a currently used protocol version when sending data. The data receiving module is configured to parse a frame header of a received data frame to obtain a protocol version number thereof, and select a corresponding protocol parser to parse data in the data frame according to the protocol version number.

Images