Network compatibility optimization configuration method and device, electronic equipment and storage medium

Abstract

The embodiment of the invention discloses a network compatibility optimization configuration method and device, electronic equipment and a storage medium, and belongs to the technical field of Internet. According to the embodiment of the invention, on one hand, the independent version number is bound to each service and / or method, so that fine-grained version management can be realized, and a management basis can be laid for finer network compatibility control; on the other hand, according to the embodiment of the invention, when the structural body is changed, old fields are reserved at the server side and marked as a discarded state, and new fields are numbered in the protocol definition and marked as an optional state; at least the field definition and the data structure in the service table can be ensured not to damage the existing communication protocol between the client and the server. And when the service or the method is updated, the new version can be compatible with the old version, so that the normal operation of the existing client or server side is prevented from being influenced by the updated interface change.

Description

Technical Field

[0001] Embodiments of the present invention relate to the field of Internet technology, and in particular to a network compatibility optimization configuration method, device, electronic device, and storage medium. Background Art

[0002] Currently, compatibility issues caused by improper removal of old services after service information table updates are one of the most common and challenging issues in dynamic updates of in-vehicle networks. This issue not only affects service initiation and access, but can also cause unpredictable system behavior and threaten user safety. This is particularly problematic in complex in-vehicle systems, such as those involving continuous communication between multiple Electronic Control Units (ECUs). Summary of the Invention

[0003] Embodiments of the present invention provide a network compatibility optimization configuration method, device, electronic device, and storage medium to at least resolve compatibility issues existing in existing in-vehicle networks caused by the failure to correctly remove old services after the service information table is updated, thereby improving the compatibility of the in-vehicle network and facilitating the maintenance of stable operation of the in-vehicle system.

[0004] In a first aspect, an embodiment of the present invention provides a network compatibility optimization configuration method, comprising at least:

[0005] Performing version number binding and updating operations on at least each service and method in the service information table and the protocol stack, so that the client and the server can determine end-to-end compatibility based on at least the current version number of the service and / or the method;

[0006] When the structure changes, at least retain the field parameters of the old fields in the data structure of the server and mark the field parameters of the old fields as obsolete, so as to at least ensure that the protocol stack under the new and old versions can parse the same data packet;

[0007] When the structure changes, at least in the protocol definition, each field is assigned a unique and stable new number, and the newly added fields are marked as optional, to at least ensure that the server and old clients do not trigger a mandatory verification error when the field is missing.

[0008] Optionally, it also includes:

[0009] When the data structure of the service interface changes, at least the protocol stack clarifies the field change rules between the new and old versions, selects the field type conversion logic based on the field differences between the new and old versions, and marks the effective version range of the field in the protocol definition, so that the protocol stack can perform data conversion and adaptation between the new and old versions.

[0010] Optionally, it also includes:

[0011] When the service interface changes, an automated tool is used to perform version checking to ensure that the interface definitions of the client and the server remain consistent.

[0012] Optionally, it also includes:

[0013] During the new version deployment process, the new version of the service and / or the method is first deployed to the server to at least achieve dual-version operation of the server, and then the new version is pushed to the client in batches to achieve silent transition upgrade of the client.

[0014] Optionally, performing version number binding and updating operations on at least each service and method in the service information table and the protocol stack, so that the client and the server determine end-to-end compatibility based on at least the current version number of the service and / or the method, includes at least:

[0015] Performing the version number binding and updating operations on at least each service and method in the service information table and the protocol stack;

[0016] At least when the client requests a service and / or method, obtaining, through the server, the version number of the service and / or method currently supported by the client, and comparing the version number of the service and / or method currently supported by the client with the current version numbers and historical compatible version numbers of all services and / or methods stored by the server;

[0017] If the client's major version number is not greater than the server's major version number and the client's minor version number is not greater than the server's minor version number, then the two are considered end-to-end compatible; otherwise, they are considered end-to-end incompatible.

[0018] Optionally, it also includes:

[0019] When the client major version number does not match the server major version number, trigger an alarm or roll back to a version supported by both ends;

[0020] When the client minor version number does not match the server minor version number, at least the server is utilized to automatically filter the newly added fields or convert data types according to the client minor version number.

[0021] In a second aspect, an embodiment of the present invention further provides a network compatibility optimization configuration device, comprising at least:

[0022] a binding and updating module, configured to perform version number binding and updating operations on each service and method in the service information table and the protocol stack, so that the client and the server can determine end-to-end compatibility based on at least the current version number of the service and / or the method;

[0023] A field retention module, configured to retain, when a structure changes, at least the field parameters of the old field in the data structure of the server and mark the field parameters of the old field as obsolete, so as to at least ensure that the protocol stack under the new and old versions can parse the same data packet;

[0024] A field numbering module is used to assign a unique and stable new number to each field in the protocol definition when the structure changes, and mark the newly added fields as optional to at least ensure that the server and old clients do not trigger a forced verification error when the field is missing.

[0025] Optionally, it also includes:

[0026] The conversion and adaptation module is used to, when the data structure of the service interface changes, at least clarify the field change rules between the new and old versions through the protocol stack, select the field type conversion logic based on the field differences between the new and old versions, and mark the effective version range of the field in the protocol definition, so that the protocol stack can perform data conversion and adaptation between the new and old versions.

[0027] In a third aspect, an embodiment of the present invention further provides an electronic device comprising a memory and a processor, wherein the memory stores a computer program that can be run on the processor, and when the processor executes the program, the steps in the network compatibility optimization configuration method described in any one of the first aspects are implemented.

[0028] In a fourth aspect, an embodiment of the present invention further provides a computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, the steps of the network compatibility optimization configuration method described in any one of the first aspects are implemented.

[0029] The technical solution provided by the embodiment of the present invention, first, performs version number binding and update operations on at least each service and method in the service information table and the protocol stack, so that the client and the server can judge the end-to-end compatibility at least based on the current version number of the service and / or method. Further, when the structure changes, at least the field parameters of the old field are retained in the data structure of the server, and the field parameters of the old field are marked as obsolete, so as to at least ensure that the protocol stack under the new and old versions can parse the same data packet. Further, when the structure changes, at least a unique and stable new number is assigned to each field in the protocol definition, and the newly added field is marked as optional, so as to at least ensure that the server and the old version of the client will not trigger a forced verification error when a field is missing.

[0030] In view of this, the embodiment of the present invention can not only realize fine-grained version management by binding an independent version number to each service and / or method, but also lay a solid management foundation for more refined network compatibility control. On the other hand, the embodiment of the present invention also retains the old fields on the server side and marks them as obsolete when the structure changes, and numbers the newly added fields in the protocol definition and marks them as optional, which can at least ensure that the field definitions and data structures in the service table do not destroy the communication protocol between the existing client and the server. When the service or method is updated, the new version can be compatible with the old version to avoid the updated interface changes affecting the normal operation of the existing client or server; in other words, field changes such as new fields and deleted fields in the service table can be correctly handled by the old version system to avoid crashes or data loss caused by incompatibility, and at least ensure the backward compatibility of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] In order to more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the specific embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0032] Figure 1 This is a flow chart of a network compatibility optimization configuration method provided by an embodiment of the present invention;

[0033] Figure 2 is a flow chart of another network compatibility optimization configuration method provided by an embodiment of the present invention;

[0034] Figure 3 This is a schematic diagram of the structure of a network compatibility optimization configuration device provided by an embodiment of the present invention;

[0035] Figure 4 It is a structural diagram of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0036] To make the objectives, technical solutions, and advantages of this application more clear, this application will be further described in detail below with reference to the accompanying drawings. Obviously, the embodiments described are only some of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making any creative efforts are within the scope of protection of this application.

[0037] The terms used in the examples of this application are for the purpose of describing specific embodiments only and are not intended to limit this application. The singular forms "a," "the," and "the" used in the examples of this application and the appended claims are also intended to include plural forms, and unless the context clearly indicates otherwise, "a plurality" generally includes at least two.

[0038] It should be understood that the term "and / or" as used herein simply describes a relationship between associated objects, indicating that three possible relationships exist. For example, "A and / or B" can represent: A exists alone, A and B exist simultaneously, or B exists alone. Furthermore, the character " / " in this document generally indicates that the associated objects are in an "or" relationship.

[0039] It should be understood that although the terms first, second, third, etc. may be used to describe in the embodiments of the present application, these descriptions should not be limited to these terms. These terms are only used to distinguish the descriptions. For example, without departing from the scope of the embodiments of the present application, the first may also be referred to as the second, and similarly, the second may also be referred to as the first.

[0040] As used herein, the words "if" and "if" may be interpreted as "at the time of" or "when" or "in response to determining" or "in response to detecting," depending on the context. Similarly, the phrases "if it is determined" or "if (stated condition or event) is detected" may be interpreted as "when it is determined" or "in response to the determination" or "when detecting (stated condition or event)" or "in response to detecting (stated condition or event)," depending on the context.

[0041] It should also be noted that the terms "include," "comprises," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a product or device comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such product or device. In the absence of further limitations, an element defined by the phrase "comprises a..." does not exclude the presence of other identical elements in the product or device comprising the element.

[0042] It should be noted in particular that any symbols and / or numbers in the specification that are not marked in the accompanying drawings are not drawing marks.

[0043] Figure 1This is a flow chart of a network compatibility optimization configuration method provided by an embodiment of the present invention. This embodiment is at least applicable to the dynamic update scenarios of vehicle networks of various types of vehicles, such as fuel vehicles, hybrid vehicles, plug-in hybrid vehicles, etc. The network compatibility optimization configuration method can be, but is not limited to, executed by the network compatibility optimization configuration device in the embodiment of the present invention as the execution subject, and the execution subject can be implemented in software and / or hardware. Figure 1 As shown, the network compatibility optimization configuration method includes at least the following specific steps:

[0044] S1. Perform version number binding and update operations on at least each service and method in the service information table and protocol stack, so that the client and the server can determine end-to-end compatibility based on at least the current version number of the service and / or method.

[0045] The protocol stack can be, for example, a vehicle-mounted communication protocol stack. Specifically, the vehicle-mounted communication protocol stack refers to the protocol hierarchy that enables data transmission and control between the smart cockpit and the vehicle's onboard systems. It typically involves multiple communication layers, from the physical layer to the application layer, with each layer responsible for different functions. The design of the vehicle-mounted communication protocol stack must consider a variety of communication requirements and technologies, including in-vehicle networks, external communications, real-time performance, security, and efficient data processing. SOME / IP (Scalable Service-Oriented Middleware over IP) is a communication protocol widely used in in-vehicle networks. Especially when used in conjunction with Ethernet, it provides an efficient, reliable, and scalable service communication architecture for various ECUs within the vehicle. The SOME / IP protocol stack can be automatically generated from a service information table using a toolchain typically provided by vendors such as Elektrobit and Vector.

[0046] It is known that the service information table can be defined by developers using dedicated tools or standard description languages ​​(such as XML Schema provided by AUTOSAR). These tools at least allow developers to define services and methods, configure parameters and communication properties, verify data integrity, etc.

[0047] In addition, the tool can parse the service information table and automatically generate client and server proxy code, client proxy, server proxy, and communication protocol configuration. The client and server proxy code is primarily responsible for processing specific service requests and responses, encapsulating calls to the underlying protocol stack; the ClientProxy primarily handles service requests from the client; the ServerSkeleton primarily handles requests received by the server; and the communication protocol configuration includes the service port and protocol type, which are used to initialize the protocol stack at runtime.

[0048] Furthermore, the generated code and configuration files can be integrated into the software architecture of the vehicle system. The integration process includes: compilation and deployment (i.e. compiling the generated code into binary files and deploying them to the client and server ECUs), runtime loading (i.e. the vehicle system loads the service configuration information at startup and initializes the SOME / IP protocol stack), and dynamic discovery and communication (i.e. the service is registered through the Service Discovery mechanism at runtime and starts communicating with other nodes).

[0049] Furthermore, in automotive development, SOME / IP's service information tables are typically based on ARXML (AUTOSAR XML) files from the AUTOSAR Adaptive platform. ARXML is the standard AUTOSAR format for describing various configuration information for vehicle systems. Service interfaces are defined using the AUTOSAR Adaptive toolchain. The runtime environment (RTE) binds these service interfaces to actual communication protocols, such as SOME / IP. Furthermore, SOME / IP's protocol stack generation is highly dependent on the toolchain. For example, Vector DaVinci Developer supports AUTOSAR-based service definition and code generation, while Elektrobit's EB tresos Studio supports SOME / IP protocol configuration and deployment. AUTOSAR Adaptive's generation tools provide comprehensive service information and communication stack generation. Furthermore, the SOME / IP protocol stack supports dynamic loading of services, meaning the service information table can be updated dynamically during runtime without recompiling the entire system. Dynamic service discovery (SD) mechanisms ensure that new services are automatically registered and discovered by clients.

[0050] It is understandable that the existing technology usually performs global version management on the protocol stack or service table (such as upgrading the overall protocol stack version from v1.0 to v2.0), while this embodiment binds an independent version number to each service (Service) and method (Method) (for example, GetVehicleStatus service v1.2, SetEngineMode method v1.1, etc.). If only the field of the GetVehicleStatus service changes, it is only necessary to upgrade the version number corresponding to the service (such as from v1.0 to v1.1), and other services (such as SetEngineMode) do not need to be changed. Such a configuration as in this embodiment can reduce redundant upgrades. The client and the server are dynamically matched based on the service / method-level version number, rather than relying on the global protocol version. It can accurately adapt to the change requirements of different services, which is conducive to achieving more refined compatibility control.

[0051] In a specific embodiment, optionally, the aforementioned step S1 at least includes:

[0052] (1-1) Perform version number binding and update operations on at least each service and method in the service information table and protocol stack.

[0053] (1-2) At least when the client requests a service and / or method, obtain the version number of the service and / or method currently supported by the client through the server, and compare the version number of the service and / or method currently supported by the client with the current version number and historical compatible version number of all services and / or methods stored on the server.

[0054] (1-3) If the client's major version number is not greater than the server's major version number and the client's minor version number is not greater than the server's minor version number, then the two systems are considered end-to-end compatible; otherwise, they are considered end-to-end incompatible.

[0055] Among them, when requesting services and / or methods, the client can carry the version numbers of the services and / or methods it supports (such as GetVehicleStatus service v1.2); the server can store the current version numbers of all services / methods and a list of historical compatible version numbers. Specifically, when performing version matching, if the client's major version number ≤ the server's major version number and the client's minor version number ≤ the server's minor version number, the client and server are compatible. For example, assuming that the client requests v1.2 and the server supports v1.3, it can be determined that the end-to-end is compatible, and the minor version upgrade only requires adding new fields; if the client requests v1.2 and the server only supports v2.0, it can be determined that the end-to-end is incompatible, and the major version change requires a client upgrade.

[0056] Based on this, in another specific embodiment, after comparing the version numbers of the services and / or methods currently supported by the client with the current version numbers and historical compatible version numbers of all services and / or methods stored on the server, the network compatibility optimization configuration method optionally further includes:

[0057] (7-1) When the client minor version number does not match the server minor version number, at least use the server to automatically filter new fields or convert data types based on the client minor version number.

[0058] (7-2) When the client's major version number does not match the server's major version number, an alarm is triggered or the server rolls back to a version supported by both ends.

[0059] Among them, when the version is rolled back, the client and server versions can usually be distinguished according to the version identifier; when encountering version compatibility issues, this embodiment can roll back to the previous stable version in time to ensure that the stable operation of the system is not affected.

[0060] S2. When the structure changes, at least retain the field parameters of the old field in the data structure on the server side and mark the field parameters of the old field as obsolete, so as to at least ensure that the protocol stack under the new and old versions can parse the same data packet.

[0061] During the data construction phase, if a request is received from an old client (e.g., version v1.0), all reserved fields (such as fuelLevel below) are populated, and newly added fields (such as batteryStatus below) are left blank or assigned default values. If a request is received from a new client (e.g., version v2.0), all fields (including the newly added fields below) are populated. Furthermore, during the serialization phase, the client version number is used to determine whether to serialize deprecated fields (i.e., fields marked as deprecated). If the client is an old client, all reserved fields are serialized (even if their values ​​are empty). If the client is a new client, the version number is used to determine and skip deprecated fields.

[0062] In another specific implementation, during the data construction phase, if a request is received from an older client, deprecated fields (such as fuelLevel described below) are still populated, but the values ​​can be fixed (e.g., 0 or a default value). If a request is received from a newer client, deprecated fields are skipped and only valid fields are returned. During the serialization phase, whether to serialize deprecated fields can be determined based on the client version. During the deserialization phase, if the client is an older client, deprecated fields are parsed normally (still relying on tag=2). If the client is a newer client, deprecated fields are automatically skipped (a Protobuf feature) or the deprecation flag is actively checked.

[0063] S3. When the structure changes, assign a unique and stable new number to each field in the protocol definition, and mark the newly added fields as optional to at least ensure that the server and old clients do not trigger a mandatory validation error when the field is missing.

[0064] In protocol definitions (such as Protobuf and SOME / IP), each field is assigned a unique and stable tag. New fields must use unused tags, and reusing old tags is prohibited. Furthermore, fields are marked as optional, meaning all new fields must be declared as optional. This ensures that legacy clients and servers will not trigger mandatory validation errors when fields are missing.

[0065] In another specific implementation, tag-based serialization (such as Protobuf) can be used during the protocol design phase. New fields are assigned new tags, and older clients automatically skip unknown fields. All new fields are set as optional, allowing for missing fields. During server processing, the client version is checked. If the client is an older version, the new fields are not returned; if the client is a newer version, the complete data is returned. Default values ​​(such as 0 or null) are provided for missing fields. During client processing, the version is checked. If the client is an older version, unknown tags are automatically ignored, and only known fields are parsed. If the client is a newer version, the existence of the fields is checked, and if not, the process is downgraded.

[0066] Furthermore, when a major version upgrade occurs (an incompatible change), the version tag assignment rule can be that new tags must start from the new range (e.g., if the old version used 1-100, the new version will use 101-200) to avoid conflicts with the old version. When a minor version upgrade occurs (a compatible change), the version tag assignment rule can be that new tags must be assigned in ascending order within the original range (e.g., if the old version used 1-10, the new field will use 11).

[0067] In another specific embodiment, consider a service interface, GetVehicleStatus, that returns a structure, VehicleStatus, containing fields, speed (int type) and fuelLevel (float type). After a version update, the new service interface changes the data type, with the fuelLevel field becoming a double and adding a new field, batteryStatus (string type) for battery status. However, the old client version still uses an int to represent vehicle speed, while the new server returns a double. In this case, if the client still uses the old structure (speed of type int), the server can handle this mismatch and return the correct data, avoiding missing or incorrectly parsed fields. Meanwhile, when the client receives the new fuelLevel field (double type), it can choose to ignore the new field type change (if it only supports int types) and maintain existing logic, or upgrade the client to support the new data structure. Through this versioning and interface management, this embodiment ensures that the client and server can maintain normal communication even after interface changes.

[0068] In summary, the technical solution provided by this embodiment, first, performs version number binding and update operations on at least each service and method in the service information table and the protocol stack, so that the client and the server can at least judge the end-to-end compatibility based on the current version number of the service and / or method. Furthermore, when the structure changes, at least the field parameters of the old fields are retained in the data structure of the server, and the field parameters of the old fields are marked as obsolete, so as to at least ensure that the protocol stack under the new and old versions can parse the same data packet. Furthermore, when the structure changes, at least a unique and stable new number is assigned to each field in the protocol definition, and the newly added fields are marked as optional, so as to at least ensure that the server and the old version of the client will not trigger a forced verification error when a field is missing.

[0069] In view of this, this embodiment, on the one hand, can not only achieve fine-grained version management by binding an independent version number to each service and / or method, but also lay a solid management foundation for more refined network compatibility control. On the other hand, this embodiment also retains the old fields on the server side and marks them as obsolete when the structure changes, and numbers the newly added fields in the protocol definition and marks them as optional, which can at least ensure that the field definitions and data structures in the service table do not destroy the communication protocol between the existing client and the server. When a service or method is updated, the new version can be compatible with the old version to avoid the updated interface changes affecting the normal operation of the existing client or server; in other words, field changes such as new fields and deleted fields in the service table can be correctly handled by the old version of the system to avoid crashes or data loss caused by incompatibility, and at least ensure the backward compatibility of the system.

[0070] Based on the above embodiments or implementation methods, Figure 2 is a flow chart of another network compatibility optimization configuration method provided by an embodiment of the present invention, such as Figure 2 As shown, the network compatibility optimization configuration method includes the following specific steps:

[0071] S1. Perform version number binding and update operations on at least each service and method in the service information table and protocol stack, so that the client and the server can determine end-to-end compatibility based on at least the current version number of the service and / or method.

[0072] S2. When the structure changes, at least retain the field parameters of the old field in the data structure on the server side and mark the field parameters of the old field as obsolete, so as to at least ensure that the protocol stack under the new and old versions can parse the same data packet.

[0073] S3. When the structure changes, assign a unique and stable new number to each field in the protocol definition, and mark the newly added fields as optional to at least ensure that the server and old clients do not trigger a mandatory validation error when the field is missing.

[0074] S4. When the data structure of the service interface changes, at least the protocol stack shall clarify the field change rules between the new and old versions, select the field type conversion logic based on the field differences between the new and old versions, and mark the effective version range of the field in the protocol definition, so that the protocol stack can perform data conversion and adaptation between the new and old versions.

[0075] Specifically, the version mapping table can be used to clarify the field change rules between different versions (such as deletion, addition, type modification, etc.); the dynamic converter can be used to automatically select the adaptation logic based on the version difference (such as float→double conversion); the effective version range of the field can be marked in the protocol definition in the form of metadata tags (such as v2+).

[0076] On the server side, it can detect the client version and trigger data conversion as needed (e.g., v1 to v2), removing deprecated fields and adapting to new ones. On the client side, it can receive the adapted data without any notice: older versions automatically ignore unknown fields, while newer versions process the complete set of fields. Finally, the toolchain automatically generates conversion code, eliminating the need to manually maintain compatibility logic.

[0077] S5. When the service interface changes, use automated tools to perform version checks to ensure that the interface definitions on the client and server remain consistent.

[0078] Among them, the automation tool can be, for example, a scoring tool, or an automated scoring program can be compiled through Python.

[0079] S6. During the new version deployment process, the new version of the service and / or method is first deployed to the server to at least achieve dual-version operation on the server, and then the new version is pushed to the client in batches to achieve silent transition upgrade of the client.

[0080] Among them, the dual-version operation of the server can distribute requests by version through routing strategies (that is, v1 clients correspond to v1 service logic; v2 clients correspond to v2 service logic); specifically, API gateways or Service Mesh (such as Istio) can be used to implement traffic segmentation. For the client upgrade strategy, the new version can be pushed in batches through OTA to ensure silent upgrades without user perception. Before upgrading, the client can request the server / version interface to confirm that v2 is available to perform a version health check. When performing version monitoring and rollback, at least the error rate (such as the 4xx / 5xx ratio of the v2 interface) and performance loss (such as response time increase ≤10%) can be used as monitoring indicators; if the error rate exceeds the threshold, it will automatically switch back to the v1 service node to achieve automatic version rollback.

[0081] Given this, when the data type in a service table is inconsistent with the previous version, the most critical issue is how to manage and ensure backward compatibility and version compatibility of the service interface. This embodiment reduces compatibility issues caused by changes to structures or fields through reasonable version management, backward-compatible interface design, and flexible data serialization and deserialization mechanisms. Furthermore, this embodiment establishes clear protocol version management between the client and server to ensure that changes do not cause runtime errors.

[0082] Figure 3This is a schematic diagram of the structure of a network compatibility optimization configuration device provided by an embodiment of the present invention. This embodiment is at least applicable to the dynamic update scenario of the vehicle network of various types of vehicles, such as fuel vehicles, hybrid vehicles, plug-in hybrid vehicles, etc. The network compatibility optimization configuration device can be implemented in software and / or hardware. Figure 3 As shown, the network compatibility optimization configuration device at least includes:

[0083] The binding update module 110 is at least used to perform version number binding and update operations on each service and method in the service information table and the protocol stack, so that the client and the server can determine end-to-end compatibility based on at least the current version number of the service and / or method;

[0084] The field retention module 120 is used to retain the field parameters of the old field in the data structure of the server when the structure changes, and mark the field parameters of the old field as obsolete, so as to at least ensure that the protocol stacks under the new and old versions can parse the same data packet;

[0085] The field numbering module 130 is used to assign a unique and stable new number to each field at least in the protocol definition when the structure changes, and mark the newly added fields as optional to at least ensure that the server and the old version of the client will not trigger a forced verification error when the field is missing.

[0086] Optionally, it also includes:

[0087] The conversion and adaptation module 140 is used to, when the data structure of the service interface changes, at least clarify the field change rules between the new and old versions through the protocol stack, select the field type conversion logic based on the field differences between the new and old versions, and mark the effective version range of the field in the protocol definition, so that the protocol stack can perform data conversion and adaptation between the new and old versions.

[0088] Optionally, it also includes:

[0089] The version check module 150 is used to perform version checking using an automated tool when the service interface changes, so as to ensure that the interface definitions of the client and the server remain consistent.

[0090] Optionally, it also includes:

[0091] The deployment push module 160 is used to first deploy the new version of the service and / or method to the server during the new version deployment process to at least achieve dual-version operation on the server, and then push the new version to the client in batches to achieve silent transition upgrade of the client.

[0092] Optionally, the binding update module 110 is specifically configured to at least:

[0093] Perform version number binding and update operations on at least each service and method in the service information table and protocol stack;

[0094] At least when the client requests a service and / or method, obtain the version number of the service and / or method currently supported by the client through the server, and compare the version number of the service and / or method currently supported by the client with the current version number and historical compatible version number of all services and / or methods stored on the server;

[0095] If the client's major version number is not greater than the server's major version number and the client's minor version number is not greater than the server's minor version number, then the two are considered end-to-end compatible; otherwise, they are considered end-to-end incompatible.

[0096] Optionally, it also includes:

[0097] The alarm and fallback module 170 is used to trigger an alarm or fallback to a version supported by both ends when the client major version number does not match the server major version number;

[0098] The filtering and conversion module 180 is used to automatically filter new fields or convert data types based on the client minor version number using at least the server when the client minor version number does not match the server minor version number.

[0099] In summary, the technical solution provided by this embodiment, first, performs version number binding and update operations on at least each service and method in the service information table and the protocol stack through the binding update module, so that the client and the server can at least judge the end-to-end compatibility based on the current version number of the service and / or method. Further, when the structure changes, at least the field retention module retains the field parameters of the old field in the data structure of the server, and marks the field parameters of the old field as obsolete, so as to at least ensure that the protocol stack under the new and old versions can parse the same data packet. Further, when the structure changes, at least the field numbering module assigns a unique and stable new number to each field in the protocol definition, and marks the newly added field as optional, so as to at least ensure that the server and the old version of the client will not trigger a forced verification error when the field is missing.

[0100] In view of this, this embodiment, on the one hand, can not only achieve fine-grained version management by binding an independent version number to each service and / or method, but also lay a solid management foundation for more refined network compatibility control. On the other hand, this embodiment also retains the old fields on the server side and marks them as obsolete when the structure changes, and numbers the newly added fields in the protocol definition and marks them as optional, which can at least ensure that the field definitions and data structures in the service table do not destroy the communication protocol between the existing client and the server. When a service or method is updated, the new version can be compatible with the old version to avoid the updated interface changes affecting the normal operation of the existing client or server; in other words, field changes such as new fields and deleted fields in the service table can be correctly handled by the old version of the system to avoid crashes or data loss caused by incompatibility, and at least ensure the backward compatibility of the system.

[0101] This embodiment provides an electronic device, Figure 4 This is a schematic diagram of the structure of an electronic device provided by an embodiment of the present invention. Figure 4 The electronic device 1000 includes a processor 1001 and a memory 1002. The memory 1002 stores computer-readable instructions. When the computer-readable instructions are executed by the processor 1001, the steps in any one of the above network compatibility optimization configuration methods are executed. Through the above technical solution, the processor 1001 and the memory 1002 are interconnected and communicate with each other through a communication bus and / or other forms of connection mechanisms (not shown), and the memory 1002 stores a computer program executable by the processor. When the electronic device 1000 is running, the processor 1001 executes the computer program to perform the network compatibility optimization configuration method in any optional implementation of the above embodiment, so as to at least achieve the following functions: at least perform version number binding and update operations on each service and method in the service information table and the protocol stack, so that the client and the server can determine end-to-end compatibility based on at least the current version number of the service and / or method; when the structure changes, at least retain the field parameters of the old field in the data structure of the server and mark the field parameters of the old field as obsolete, so as to at least ensure that the protocol stacks under the new and old versions can parse the same data packet; when the structure changes, at least assign a unique and stable new number to each field in the protocol definition, and mark the newly added field as optional, so as to at least ensure that the server and the old version client will not trigger a forced verification error when the field is missing.

[0102] This embodiment provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements a network compatibility optimization configuration method as provided in all the inventive embodiments of this application: at least performing version number binding and update operations on each service and method in the service information table and the protocol stack, so that the client and the server can at least judge the end-to-end compatibility based on the current version number of the service and / or method; when the structure changes, at least retaining the field parameters of the old field in the data structure of the server, and marking the field parameters of the old field as obsolete, so as to at least ensure that the protocol stack under the new and old versions can parse the same data packet; when the structure changes, at least assigning a unique and stable new number to each field in the protocol definition, and marking the newly added field as optional, so as to at least ensure that the server and the old version of the client will not trigger a forced verification error when a field is missing.

[0103] Any combination of one or more computer-readable media may be employed. A computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: an electrical connection having one or more conductors, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium may be any tangible medium containing or storing a program that may be used by or in conjunction with an instruction execution system, apparatus, or device.

[0104] A computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, which carries computer-readable program code. Such a propagated data signal may take a variety of forms, including, but not limited to, electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or transport a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0105] Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0106] Computer program code for performing the operations of the present invention may be written in one or more programming languages, or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0107] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A network compatibility optimization configuration method, characterized in that: At least: Performing version number binding and updating operations on at least each service and method in the service information table and the protocol stack, so that the client and the server can determine end-to-end compatibility based on at least the current version number of the service and / or the method; When the structure changes, at least retain the field parameters of the old fields in the data structure of the server and mark the field parameters of the old fields as obsolete, so as to at least ensure that the protocol stack under the new and old versions can parse the same data packet; When the structure changes, at least in the protocol definition, each field is assigned a unique and stable new number, and the newly added fields are marked as optional, to at least ensure that the server and old clients do not trigger a mandatory verification error when the field is missing.

2. The network compatibility optimization configuration method according to claim 1, characterized in that: Also includes: When the data structure of the service interface changes, at least the protocol stack clarifies the field change rules between the new and old versions, selects the field type conversion logic based on the field differences between the new and old versions, and marks the effective version range of the field in the protocol definition, so that the protocol stack can perform data conversion and adaptation between the new and old versions.

3. The network compatibility optimization configuration method according to claim 1, characterized in that: Also includes: When the service interface changes, an automated tool is used to perform version checking to ensure that the interface definitions of the client and the server remain consistent.

4. The network compatibility optimization configuration method according to claim 1, characterized in that: Also includes: During the new version deployment process, the new version of the service and / or the method is first deployed to the server to at least achieve dual-version operation of the server, and then the new version is pushed to the client in batches to achieve silent transition upgrade of the client.

5. The network compatibility optimization configuration method according to claim 1, characterized in that: The performing of version number binding and updating operations on at least each service and method in the service information table and the protocol stack, so that the client and the server determine end-to-end compatibility based on at least the current version number of the service and / or the method, at least includes: Performing the version number binding and updating operations on at least each service and method in the service information table and the protocol stack; At least when the client requests a service and / or method, obtaining, through the server, the version number of the service and / or method currently supported by the client, and comparing the version number of the service and / or method currently supported by the client with the current version numbers and historical compatible version numbers of all services and / or methods stored by the server; If the client's major version number is not greater than the server's major version number and the client's minor version number is not greater than the server's minor version number, then the two are considered end-to-end compatible; otherwise, they are considered end-to-end incompatible.

6. The network compatibility optimization configuration method according to claim 5, characterized in that: Also includes: When the client major version number does not match the server major version number, trigger an alarm or roll back to a version supported by both ends; When the client minor version number does not match the server minor version number, at least the server is utilized to automatically filter the newly added fields or convert data types according to the client minor version number.

7. A network compatibility optimization configuration device, characterized in that: At least: a binding and updating module, configured to perform version number binding and updating operations on each service and method in the service information table and the protocol stack, so that the client and the server can determine end-to-end compatibility based on at least the current version number of the service and / or the method; A field retention module, configured to retain, when a structure changes, at least the field parameters of the old field in the data structure of the server and mark the field parameters of the old field as obsolete, so as to at least ensure that the protocol stack under the new and old versions can parse the same data packet; A field numbering module is used to assign a unique and stable new number to each field in the protocol definition when the structure changes, and mark the newly added fields as optional to at least ensure that the server and old clients do not trigger a forced verification error when the field is missing.

8. The network compatibility optimization configuration device according to claim 7, characterized in that: Also includes: The conversion and adaptation module is used to, when the data structure of the service interface changes, at least clarify the field change rules between the new and old versions through the protocol stack, select the field type conversion logic based on the field differences between the new and old versions, and mark the effective version range of the field in the protocol definition, so that the protocol stack can perform data conversion and adaptation between the new and old versions.

9. An electronic device comprising a memory and a processor, wherein the memory stores a computer program that can be run on the processor, wherein: When the processor executes the program, the steps of the network compatibility optimization configuration method according to any one of claims 1 to 6 are implemented.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the network compatibility optimization configuration method according to any one of claims 1 to 6 are implemented.

Images