A data processing method and device, electronic equipment and storage medium

Abstract

The application relates to the technical field of data processing, and provides a data processing method and device, electronic equipment and a storage medium. The method receives routing data, analyzes the outer message header of the routing data, obtains a logical service number corresponding to the routing data, determines whether the logical service number is a registered logical service number, determines a processing mode corresponding to the routing data based on the logical service number in the case that the logical service number is the registered logical service number, processes the routing data based on the processing mode, analyzes the outer message header of the inbound routing data to obtain the logical service number, and judges whether the logical service number is the registered logical service number as a whitelist access control. In the case that the logical service number is the registered logical service number, the processing mode is determined based on the logical service number and executed. Thus, a unified link of "recognition, judgment and processing" is formed, and accurate and predictable data processing of the routing data is realized.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data processing, and in particular to a data processing method and device, electronic equipment and storage medium. BACKGROUND

[0002] With the increasing number of scenarios of business facing multi-core heterogeneous platforms (CPU / GPU / MCU / co-processor), high-performance data interaction (low latency / high throughput), and remote device communication (edge gateway, terminal device, cloud service), the existing communication methods often use TCP / IP, UDP, or local shared memory / message queue mechanisms on different channels.

[0003] Although these mechanisms have their own advantages in their respective scenarios, due to protocol stack fragmentation, header definition and packet assembly / disassembly boundary inconsistency, lack of unified abstraction for service identification, and error semantics, the message header, service selection method, and error return semantics of different channels are incompatible with each other, which leads to the fact that the data routing node cannot accurately process the routing data in the scenario of coexistence of different channels. SUMMARY

[0004] Therefore, the embodiments of the present application provide a data processing method and device, electronic equipment and storage medium to solve the problem that the data routing node cannot accurately process the routing data in the scenario of coexistence of different channels in the prior art.

[0005] The first aspect of the embodiments of the present application provides a data processing method, which comprises: receiving routing data, analyzing the outer message header of the routing data to obtain the logical service number corresponding to the routing data; determining whether the logical service number is a registered logical service number, and if the logical service number is a registered logical service number, determining the processing method corresponding to the routing data based on the logical service number; and processing the routing data based on the processing method.

[0006] The second aspect of the embodiments of the present application provides a data processing device, which comprises: an analysis module configured to receive routing data, analyze the outer message header of the routing data to obtain the logical service number corresponding to the routing data; a routing module configured to determine whether the logical service number is a registered logical service number, and if the logical service number is a registered logical service number, determine the processing method corresponding to the routing data based on the logical service number; and a processing module configured to process the routing data based on the processing method.

[0007] The third aspect of the embodiments of the present application provides electronic equipment, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the above method when executing the computer program.

[0008] In a fourth aspect, the present application provides a computer readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the above method.

[0009] Compared with the prior art, the application embodiment has the beneficial effects that: according to the technical scheme provided by the application embodiment, the routing data is received, the outer packet header of the routing data is parsed to obtain a logical service number corresponding to the routing data, it is determined whether the logical service number is a registered logical service number, in the case that the logical service number is the registered logical service number, a processing mode corresponding to the routing data is determined based on the logical service number, and the routing data is processed based on the processing mode. The logical service number is obtained by parsing the outer packet header of the inbound routing data, and the logical service number is used as a whitelist access criterion. In the case that the logical service number is the registered logical service number, the processing mode is determined based on the logical service number and executed. Thus, a unified link of “recognition, judgment, and processing” is formed. In a multi-channel coexistence scenario such as TCP / UDP / local communication, the logical service number is used as a general service identifier to accurately and predictably route the routing data, avoiding misrouting and repeated adaptation caused by separate management of each channel. In the case that the logical service number is the registered logical service number, the corresponding processing mode is selected, which can reduce network hop count, reduce latency and bandwidth overhead when processing locally, and maintain a unified processing entry when data needs to be externally transmitted, thereby improving overall performance and availability. The determination of whether the logical service number is the registered logical service number and the determination of the processing mode corresponding to the routing data based on the logical service number are decoupled, the interface is abstract and clear, and the operation and maintenance switch, gray release, expansion, and evolution are facilitated. The risk of inaccurate processing of data routing nodes in a cross-channel scenario and the development and operation cost are significantly reduced, and the problem that data routing nodes cannot accurately process routing data in the prior art in a multi-channel coexistence scenario is avoided. BRIEF DESCRIPTION OF DRAWINGS

[0010] In order to more clearly illustrate the technical solutions in the application embodiments, the following will briefly introduce the drawings needed to be used in the embodiments or the prior art description. Obviously, the drawings in the following description are only some embodiments of the application, and for those skilled in the art, other drawings can be obtained without creative labor based on these drawings.

[0011] Figure 1 is a flow diagram of a data processing method provided by the application embodiment;

[0012] Figure 2 is a basic schematic diagram of a data protocol provided by the application embodiment;

[0013] Figure 3is a flowchart of another data processing method provided by an embodiment of the present application;

[0014] Figure 4 is a flowchart of another data processing method provided by an embodiment of the present application;

[0015] Figure 5 is a flowchart of another data processing method provided by an embodiment of the present application;

[0016] Figure 6 is a flowchart of another data processing method provided by an embodiment of the present application;

[0017] Figure 7 is a flowchart of another data processing method provided by an embodiment of the present application;

[0018] Figure 8 is a structural diagram of a data processing apparatus provided by an embodiment of the present application;

[0019] Figure 9 is a structural diagram of an electronic device provided by an embodiment of the present application. DETAILED DESCRIPTION

[0020] In the following description, specific details are set forth in order to provide a thorough understanding of embodiments of the present application. However, persons having ordinary skill in the art will readily recognize that embodiments of the present application can be practiced without these specific details. In other instances, well-known structures, devices, circuits, and methods have not been described in detail in order to avoid obscuring the present application.

[0021] A data processing method and apparatus according to an embodiment of the present application will be described in detail below with reference to the accompanying drawings.

[0022] Figure 1 is a flowchart of a data processing method provided by an embodiment of the present application, as shown in Figure 1 the method comprises:

[0023] S101, receiving routing data, and parsing an outer packet header of the routing data to obtain a logical service number corresponding to the routing data;

[0024] S102, determining whether the logical service number is a registered logical service number, and in a case where the logical service number is the registered logical service number, determining a processing manner corresponding to the routing data based on the logical service number;

[0025] S103, processing the routing data based on the processing manner;

[0026] It can be understood that the data processing method provided by the application is applied to a data routing node, such as an access gateway, an edge computing gateway or a micro-service gateway middleware, the data processing method provided by the application is applicable to a Transmission Control Protocol (TCP) based scenario, and is also applicable to a User Datagram Protocol (UDP) oriented datagram and an Inter-Process Communication (IPC) scenario, such as Shared Memory (SHM), a ring buffer, a Message Queue, a Unix Domain Socket (UDS) and the like.

[0027] Specifically, the application defines a data protocol for unified encapsulation and analysis of service messages in a heterogeneous channel. Various devices, client agents or memory communication ends (including but not limited to implementations based on Transmission Control Protocol (TCP), User Datagram Protocol (UDP) or Inter-Process / Inter-Process Memory Communication (IPC / UDS / Shared Memory)) can encapsulate and transmit routing data according to the data protocol specification, so that the routing data conforms to a unified header and field agreement, and can be analyzed and processed by the data processing method of the application.

[0028] Among them, the data protocol adopts a layered structure of "three-layer header + data area", as shown in Figure 2 The data protocol specifies that each data includes an outer message header (Access Control Protocol Header, ACP Header), a service call header (Application-Oriented Envelope, AOE Header) and a service request header (Application-Oriented Envelope Request, AOE Request Header). Each header is defined as follows (unless otherwise specified, all integers use network byte order, structures are aligned by 1 byte, and reserved fields are set to 0).

[0029] For example, the outer packet header has a length of 8 bytes and includes a reserve, a protocol version, a logical service number, and a length. The reserve is 1 byte; the version is 1 byte and is used to describe the version information of the ACP; the port is 2 bytes and is used for primary routing and service selection; and the length is 2 bytes and is the total length of the message body after the ACP Header (i.e., the sum of the AOE Header, the AOE Request Header, and the data).

[0030] For example, the service call header has a length of 13 bytes and includes an error code, an invoked ID, a command ID, a reserve, and a request / response flag. The error code is 4 bytes; the invoked ID is 4 bytes and is used for request-response one-to-one correspondence; the command ID is 2 bytes and is used to indicate a specific action within the current logical service number namespace; the reserve is 2 bytes and is fixed to 0; and the request / response flag is 1 byte, where 0 indicates a request and 1 indicates a response.

[0031] The service request header has a length of 8+n bytes and includes an object group, an object offset, and data. The object group is 4 bytes and is the target object group / namespace; the object offset is 4 bytes and is the offset / index of the object in the group; and the data is n bytes (which can be 0) and is the service data load, the specific structure of which is defined by the action indicated by the command ID.

[0032] The routing data received by the data routing node can be generated by various device ends, client agent, or memory communication end, and transmitted through a transmission control protocol (TCP), a user datagram protocol (UDP), or an inter-process communication (IPC, including a Unix domain socket (UDS) and a shared memory (SHM)) channel; the routing data is encapsulated according to the data protocol defined in the present application and at least includes an outer packet header (ACP Header), a service call header (AOE Header), and a service request header (AOE Request Header).

[0033] In some examples, in order to determine whether the routing data belongs to the case of non-existence / non-enabled, non-routable or security gate pass, the data routing node in this application first parses the outer packet header (Access Control Protocol Header, ACP Header) of the routing data to obtain the logical service number (port); then, based on the logical service number, the state (for example, ACTIVE / ACTIVE-READY, DISABLED, QUARANTINE / UNKNOWN) is queried in the port registry: when the query result is non-existence or DISABLED, it is determined as "non-existence / non-enabled"; when it exists but does not meet the routing strategy of the current node (such as only allowing forwarding to other nodes, the current node is not configured with target mapping, and it is in the quarantine state QUARANTINE), it is determined as "non-routable"; when the state is ACTIVE and the security gate strategy (such as access control list ACL, authentication token verification, rate and concurrent quota, source address whitelist) is passed, it is determined as "security gate pass". In the case of "security gate pass", the data routing node determines the processing mode corresponding to the routing data based on the logical service number, and processes the routing data based on the processing mode.

[0034] According to the technical scheme provided in the embodiments of the present application, the routing data is received, the outer packet header of the routing data is parsed to obtain a logical service number corresponding to the routing data, it is determined whether the logical service number is a registered logical service number, in the case where the logical service number is the registered logical service number, a processing mode corresponding to the routing data is determined based on the logical service number, and the routing data is processed based on the processing mode. The logical service number is obtained by parsing the outer packet header of the inbound routing data first, and then the judgment of whether the logical service number is the registered logical service number is used as the whitelist access control, and in the case where the logical service number is the registered logical service number, the processing mode is determined based on the logical service number and executed. Thus, a unified link of “recognition, judgment and processing” is formed: in the multi-channel coexistence scene such as TCP / UDP / local communication, the logical service number is used as a general service identifier to realize accurate and predictable routing of the routing data, and to avoid the misrouting and repeated adaptation caused by the separate management of each channel. In the case where the logical service number is the registered logical service number, the corresponding processing mode is selected, which can reduce the number of network hops, reduce the time delay and bandwidth overhead when processing locally, and maintain a unified processing entry when data needs to be sent out, thereby improving the overall performance and availability. The determination of whether the logical service number is the registered logical service number and the determination of the processing mode corresponding to the routing data based on the logical service number are decoupled, the interface is abstracted clearly, and the operation and maintenance switch, gray release, expansion and evolution are facilitated, the risk of inaccurate processing of the data routing node in the cross-channel scene and the development and operation cost are significantly reduced, and the problem that the data routing node cannot accurately process the routing data in the existing technology in the multi-channel coexistence scene is avoided.

[0035] In some examples, as shown in Figure 3 The determination of the processing mode corresponding to the routing data based on the logical service number includes:

[0036] S301, it is determined whether the logical service number is a component service registration.

[0037] S302, in the case where the logical service number is the component service registration, it is determined that the processing mode corresponding to the routing data is a local component processing mode.

[0038] S303, in the case where the logical service number is not the component service registration, it is determined that the processing mode corresponding to the routing data is a forwarding mode.

[0039] Specifically, in some examples, determining whether the logical service port is registered for component service includes: matching the logical service port with a component registry, when the matching succeeds, determining that the logical service port is registered for component service, and when the matching fails, determining that the logical service port is not registered for component service, i.e. querying the component registry for an entry corresponding to the logical service port; when the query hits and the state of the corresponding component is READY (optionally also requiring that the protocol version meets the version_min / version_max constraint or the policy field is PREFER_LOCAL / HYBRID), determining that the logical service port is registered for component service; in the case of not hitting or the component state being non-READY, determining that the logical service port is not registered for component service.

[0040] It can be understood that the component registry can be in the form of a read-only snapshot of a hash table or a bitmap, supporting RCU / double-buffered hot updates, and the query is O(1); the table entry can include: port, handler_id / handler_ptr, status, version_min / version_max, policy, updated_at / revision; for a hit of status=NOT_READY, it can be downgraded to "non-component service registration" according to the policy and enter the forwarding branch or return a service unavailable error code.

[0041] For example, first parse the ACP header to obtain the port; S2: query the port in the component registry; S3: if the hit and status=READY (and the version hits), determine that it is "registered for component service", otherwise determine that it is "non-component service registration".

[0042] In some examples, determining whether the logical service port is registered for component service includes: obtaining the online instance and label metadata (such as zone / role / version) corresponding to the logical service port based on a service discovery / registration center (such as Consul, etcd or ZooKeeper); when there is an online instance that meets the preset label constraint, determining that the logical service port is registered for component service; in the case of no online instance meeting the condition or the subscription timeout being invalid, determining that the logical service port is not registered for component service.

[0043] For example, when starting, subscribe to the key space services / <port>And maintain local instance snapshot and TTL; Receive incremental change events during runtime, update snapshot; Use the last valid snapshot when jittering; Allow filtering by region / role / version, etc. tags to avoid misidentifying cross-region or incompatible version instances as local components.

[0044] For example, S1: parse the ACP header to get the port; S2: query the local sd_snapshot[port]; S3: if there is an online instance that meets the tag constraints, determine it as "component service registration"; otherwise, determine it as "non-component service registration".

[0045] Subsequently, in the case of component service registration for the logical service number, the processing mode corresponding to the routing data is determined as the local component processing mode; in the case of non-component service registration for the logical service number, the processing mode corresponding to the routing data is determined as the forwarding mode.

[0046] According to the technical scheme provided by the embodiments of the present application, it is determined whether the logical service number is a component service registration; in the case of component service registration for the logical service number, the processing mode corresponding to the routing data is determined as the local component processing mode; in the case of non-component service registration for the logical service number, the processing mode corresponding to the routing data is determined as the forwarding mode, through the two-level determination of "determining the processing mode based on the logical service number" (first determining whether it is a registered logical service number, and then determining whether it is a component service registration), the method realizes low-latency, low-overhead and fast shunting in a unified mechanism: for unregistered or disabled ports, intercept and uniformly report errors at the entrance to reduce the attack surface; for registered ports, preferentially go through local component processing to reduce network hops, improve throughput and reduce end-to-end latency; automatically switch to forwarding mode when the component is not ready or the policy is not met, to realize smooth degradation and high availability. At the same time, this mechanism decouples "whether to recognize (register)" and "how to handle (local / forward)", which is convenient for operation and maintenance switching and gray arrangement; relying on the session request queue and callback / timeout management and based on the invokedId, the request-response is uniformly associated to ensure controllable concurrency and observability (error code, latency, hit rate are counted by port); the component registry and the capability matrix can be hot updated, which is convenient for extension and change; and the same determination logic is applicable to heterogeneous channels such as TCP / UDP / IPC, and can be combined with cmdId and version range to realize "read locally and write forward" and other fine-grained policies, to comprehensively improve performance, stability and security.

[0047] In some examples, as shown in Figure 4 The processing of the routing data based on the processing mode includes:

[0048] S401、In the case of forwarding mode, parse the service call header in the routing data to obtain the command identifier and the call identifier;

[0049] S402, based on the command identifier and the call identifier, a request object is created and added to the request buffer queue corresponding to the current connection for processing of the request object;

[0050] S403, when receiving response data generated by callback processing of the request object, a response message is constructed, and a sending interface is called to send the response message to the source connection.

[0051] Specifically, as described above, the business call header includes error code (errorCode), call identifier (invokedId), command identifier (cmdId), reserve, request / response flag (flag), therefore, by parsing the business call header in the routing data, the command identifier and the call identifier can be obtained, in some examples, the command identifier is used to select the downstream target and the forwarding strategy; the call identifier is used for one-to-one correspondence of request-response;

[0052] In some examples, based on the command identifier and the call identifier, a request object is created and added to the request buffer queue corresponding to the current connection for processing of the request object. Illustratively, a request object msg_request_t can be created based on cmdId / invokedId, which fields include at least: invokedId, cmdId, original connection context (connCtx), start timestamp, processing status, timeout timer handle (optionally also including downstream routing information, retry count, tracking ID, etc.).

[0053] Wherein, the current connection refers to the connection instance between the data routing node and the upstream client (corresponding to a connection context ConnCtx, providing a send_message(...) sending interface, a receiving and sending buffer, and a sticky / detachable packet state, etc.). The request buffer queue is a request registration structure in the current connection context, used to temporarily store the request object (msg_request_t) that has been accepted but not completed, so as to perform callback association, back pressure and timeout management.

[0054] The application adds the request object to the request buffer queue corresponding to the current connection for processing the request object; when receiving response data generated by callback processing for the request object, an upstream response message is constructed based on the response data: setting the request / response flag to a response flag in the service invocation header (AOE Header), backfilling the invoked identifier (invokedId) and setting the error code (errorCode), carrying the data load as needed; then adding an outer message header (ACP Header), calling the sending interface to send the response message to the current connection (source connection) to realize sending to the request initiator through the current connection (upstream connection, ConnCtx); after sending is completed, the request object is removed from the request buffer queue and the related resources are released.

[0055] According to the technical scheme provided by the embodiment of the application, in the case of the processing mode being a forwarding mode, the service invocation header in the routing data is parsed to obtain the command identifier and the invoked identifier; based on the command identifier and the invoked identifier, a request object is created and added to the request buffer queue corresponding to the current connection for processing the request object; when receiving response data generated by callback processing for the request object, a response message is constructed, and the sending interface is called to send the response message to the source connection. In the case of the processing mode being a forwarding mode, the cmdId / invokedId is obtained by parsing the service invocation header, the request object is created and registered with the invokedId as the key and added to the request buffer queue of the current connection, the accurate association of request-response and the in-transit request management at the connection level are realized; relying on the one-time callback, the unified packet flow is triggered when the downstream response arrives (constructing the AOE response, backfilling the invokedId, setting the errorCode, and adding the ACP header for sending), making the forwarding link asynchronous and non-blocking throughout, effectively isolating the downstream delay jitter, significantly improving the concurrent throughput and end-to-end stability; at the same time, the request buffer queue provides back pressure and timeout management capabilities, which can return an error and release resources in time in the over-limit or timeout scenario, avoiding "orphaned response" and memory leakage, and cooperating with the unified packet template to facilitate observability and fault location (statistical delay, timeout, and error code per connection / port), thereby realizing a high-performance, controllable, and maintainable forwarding processing closed loop without changing the upstream interface.

[0056] In some examples, as shown in Figure 5 The routing data is processed based on the processing mode, including:

[0057] S501, in the case of the processing mode being a local component processing mode, calling the component callback entrance corresponding to the logical service number to create a request object;

[0058] S502, calling the component processor to process the request object, if the component processor completes processing the request object, the component constructs a response message and sends the response message to the current connection.

[0059] In some examples, after calling the component callback entry corresponding to the logical service number and creating the request object (msg_request_t), the data routing node directly calls the component processor CmpHandler.HandleMessage(req) to process the request object, and constructs a response message according to the processing result and sends the response message to the request initiator through the upstream connection (source connection, ConnCtx).

[0060] In some examples, to achieve version control / compatibility, the present application introduces version determination: after calling the component callback entry and creating msg_request_t, the data routing node first reads ACP.version and shunts according to it; wherein when ACP.version ≥ 1, the routing node parses the service layer header before component processing: parses AOE Header to obtain cmdId and invokedId, parses AOE Request Header to obtain idGroup, idOffset, and data, and fills the parsing results into msg_request_t, and then calls CmpHandler.HandleMessage(req), when ACP.version<1, the routing node does not parse AOE / AOE Request at the routing layer, but writes the original message body (raw_body) together with the connection context (ConnCtx) into msg_request_t, and marks it as a compatible processing mode (for example req.parse_mode=LEGACY), and then directly calls CmpHandler.HandleMessage(req), and the component processor completes the parsing and processing of the old version protocol internally; if the component processor determines that it does not support the old version, an error indication is returned, and the routing node constructs an error response message (sets flag=response and errorCode≠0 in AOE, and backfills invokedId when the call identifier can be obtained), and then sends it to the request initiator through the upstream / source connection (ConnCtx).

[0061] The component handler CmpHandler.HandleMessage(msg_request_t) is invoked to execute the business logic and obtain a processing result or an error code; when it is determined that the processing has been completed locally and there is no need to initiate a request downstream, a response is constructed and sent: the response message is constructed: the flag is set to "response" in the AOE Header, the invokedId is backfilled, the errorCode is set (0 for success and non-0 for exception); the result load output by the component is carried in the data area (if applicable). The outer header is added and sent: the ACP Header is added (the logical service number port is used as before, and the length is recalculated), the response message is sent to the request initiator through the sending interface of the current connection (ConnCtx). The reporting is cleaned up: the msg_request_t and related resources are released, the processing time and return code are recorded; if the request has entered the request buffer queue of the connection, it is removed from the queue / index.

[0062] According to the technical scheme provided in the embodiments of the present application, in the case of the local component processing mode, the component callback entry corresponding to the logical service number is invoked to create a request object; the component handler is invoked to process the request object; if the component handler completes the processing of the request object, a response message is constructed and sent to the current connection. In the case of the local component processing mode, the data routing node directly invokes the component callback entry bound to the logical service number to create a request object and hand over the processing to the component handler; after the processing is completed, a response message is constructed at the local end and returned through the current connection. This process saves one network forwarding and coding and decoding, significantly reducing the end-to-end delay and bandwidth overhead.

[0063] In some examples, if the component processor fails to process the request object, a downstream request message is constructed, the downstream request message is sent to a target service through a sending interface, the target service is a service corresponding to the downstream request message, a response message is constructed when response data generated by callback processing of the request object is received, and the response message is sent to the current connection by calling the sending interface. In some examples, when the component processor (CmpHandler) fails to process the request object (for example, returns an error code or a processing indication is FORWARD), the data routing node performs the following steps: the component processor returns a processing result result; if result.action == FORWARD or result.errorCode ≠ 0 and forwarding is allowed according to a policy, a forwarding compensation process is entered. Based on fields (cmdId, invokedId, idGroup, idOffset, data, ConnCtx) saved in the request object msg_request_t, an outer message header (ACPHeader), a service call header (AOE Header) and a service request header (AOE Request Header) are assembled in sequence to form a downstream request message; the original invokedId is used in the AOE to maintain one-to-one correspondence between the request and the response; a target service is selected (the target logical service number can be determined according to the cmdId, a routing table or a load balancing strategy); msg_request_t is added to a request buffer queue corresponding to the current connection (an upstream / source connection, ConnCtx), an index is registered in req_map[invokedId], and a one-time callback is registered (a timeout timer is started); and the downstream request message is sent to the target service through a sending interface. When response data generated by callback processing matching the invokedId is received (or a timeout / error event occurs), the original msg_request_t is located in req_map; an upstream response message is constructed: in the AOE, a flag is set to response, the invokedId is backfilled, an error code is written (0 for success and a non-zero value for failure), downstream return data or error information is carried in the data area, an ACP Header is added, and ConnCtx.send_message(...) is called to send to the current connection (i.e., the request initiator). After sending is completed, msg_request_t is removed from the request buffer queue / index, resources are released, and indicators (time consumption, error code, whether forwarding, etc.) are recorded. If a timeout occurs, the response with the timeout error code generated by the callback is also executed to clean up.

[0064] Wherein, when the local component processing fails, it is automatically switched to downstream forwarding, forming a closed loop of "failure is degradation", significantly improving availability without interrupting the connection; Outbound and back packet are driven by one-time callback, the entire link is asynchronous and non-blocking, combined with the request buffer queue maintained by the upstream TCP connection to achieve concurrent load, back pressure and timeout cleaning, resources are controllable and not leaked; InvokedId runs through local and downstream, so that the response can be accurately associated with the original request, avoiding mismatch and "orphan response"; Whether local success, forwarding success or timeout failure, the routing node constructs the response according to the unified AOE / ACP template and sets the standard error code, the client semantics is consistent and the troubleshooting is intuitive; At the same time, the outbound stage is convenient for hanging retry, fuse and load balancing strategies, isolating the influence of downstream jitter on upstream latency, and strengthening observability through port / connId / invokedId index collection, taking into account performance, stability and evolution.

[0065] In some examples, the data processing method further includes: generating an error response message based on the invocation identification, and sending the error response message to the source connection. In some examples, when the logical service number (port) obtained by parsing the ACP Header is a non-registered logical service number, the data routing node performs the following processing: the data routing node parses the ACP Header to obtain the invokedId (optionally, the cmdId is also taken for logging). The response message is generated according to a unified template: the flag= response is set in the AOE Header, the invokedId is backfilled, and the errorCode = ERR_PORT_NOT_REGISTERED (a preset non-zero value) is set; optionally, the cmdId is echoed; the ACP.length is calculated and the ACP Header is added. The error response is sent to the request initiator through the source connection / upstream connection (ConnCtx) call sending interface; audit logs (port, invokedId, cmdId, errorCode, etc.) are recorded.

[0066] In some examples, in order to ensure data integrity, incomplete data is not parsed to avoid invalid overhead. The data routing node uses the following integrity gating for inbound routing data. Specifically, the outer packet header of the routing data is parsed, including: determining whether the routing data contains an outer packet header, a service invocation header, and a service request header; in the case where the routing data contains an outer packet header, a service invocation header, and a service request header, the outer packet header of the routing data is parsed.

[0067] In order to better understand the present application, a more specific example is provided in the embodiments to illustrate the present application, such as Figure 6 As shown, the application provides a flowchart example of an application data processing method, which includes the following steps:

[0068] S601 Initialize libacp_init, wherein library initialization and environment preparation (load configuration, initialize network / memory, etc. resources) are completed by calling libacp_init().

[0069] S602 Create an AcpDeviceAddr libacp_makeAcpDeviceAddr(), wherein AcpDeviceAddr is constructed by calling libacp_makeAcpDeviceAddr(), and the network parameters / identification information of the PLC are filled in to obtain a target address that can be used for link establishment.

[0070] S603 Create a communication instance libacp_createInstanceEx(), wherein a communication instance handle inst is created based on AcpDeviceAddr by calling libacp_createInstanceEx(), and a session environment to the gateway (data routing node) / PLC is established.

[0071] S604 Determine whether to initiate a read / write request, and implement entering a business cycle to determine whether a read / write request needs to be initiated to the PLC variable:

[0072] If needed, perform S605-S611;

[0073] If not needed, go to S612 to determine whether to exit.

[0074] S605 Send a synchronous request libacp_sync_send(), wherein a synchronous read / write request is sent by calling libacp_sync_send(inst, req), wherein req includes variable identification, read / write type, and write value (when writing).

[0075] S606 Wait to receive server response data libacp_sync_recv, wherein libacp_sync_recv(inst, &resp) is called to block and wait for server response data (with timeout). resp carries the read variable value or write confirmation information.

[0076] S607 Error, determine whether the interaction is incorrect according to the return state / verification result of libacp_sync_recv:

[0077] No error: go to S611;

[0078] Error: execute S608-S610.

[0079] S608 Get the latest error code libacp_get_errno, get the latest error code ec (such as timeout, network exception, protocol error, etc.) by calling libacp_get_errno().

[0080] S609 Get the corresponding error information according to the error code libacp_strerror, map the error code to readable error information errmsg by calling libacp_strerror(ec), which is used for logging and prompting.

[0081] S610 Error handling, handle according to the strategy: record log, alarm, retry or backoff; then return to S104, continue the business loop to read / write.

[0082] S611 Loop to read variables, parse variable values (read operation) or confirm results (write operation) for error-free response resp, update local state; then return to S604, continue the next read / write request.

[0083] S612 Exit, when the business side judges that there is no need to continue to send requests, enter the exit judgment:

[0084] Yes: execute S613-S614;

[0085] No: return to S604 to maintain idle / standby.

[0086] S613 Release instance libacp_releaseInstance(), call libacp_releaseInstance(inst) to close the session and release resources related to the instance.

[0087] S614 Release ACP initialization resources libacp_destory(), call libacp_destory() to release global resources occupied by libacp_init(), and the process ends.

[0088] In order to better understand the present application, a more specific example is provided in the present embodiment to illustrate, as shown in the present application, another flowchart example of the application data processing method is provided, which includes the following steps: Figure 7

[0089] S701 Initialization libacp_init(), complete library initialization and environment preparation (load configuration, initialize network / timer / memory pool, etc.) by calling libacp_init().​

[0090] S702 Create an AcpDeviceAddr libacp_makeAcpDeviceAddr(), generate AcpDeviceAddr by calling libacp_makeAcpDeviceAddr(), and write the connection parameters (IP, port, device identifier, etc.) of the PLC / gateway (data routing node).

[0091] S703 Create a communication instance libacp_createInstanceEx(), create a communication instance handle inst based on AcpDeviceAddr by calling libacp_createInstanceEx(), and establish a communication context to the server.

[0092] S704 Register a routing event libacp__registerRouterEvent, register a routing event callback by calling libacp__registerRouterEvent(inst, onRouterEvent, userData). The callback onRouterEvent(inst, msg, userData) is used to receive server notification messages (variable changes, heartbeats, errors, etc.).

[0093] S705 Send a subscription variable request libacp_sync_send, synchronously send a variable subscription request (or other required initial read-write request) by calling libacp_sync_send(inst, subscribeReq). After successful return, it indicates that the subscription has been established.

[0094] S706 Start the event loop libacp_loop_start(), call libacp_loop_start(inst) to start the event loop thread / cycle body, and enter the callback-driven mode.

[0095] S707 Whether to exit the loop (decision point) Enter the application main loop, determine whether to exit the event loop according to the business conditions:

[0096] No, then go to S708-S710 (continuously wait and process callbacks); Yes, go to S711.

[0097] S708 Callback waiting for server notification, blocking waiting or asynchronous listening for server notification messages in the event loop; once a message arrives, it is distributed to the onRouterEvent(...) callback.

[0098] S709 judging the message type (executed in callback) In onRouterEvent, the message header / command code is parsed, and the message type is distinguished, such as variable value change / subscription confirmation / heartbeat / error code, etc.

[0099] S710 service processing (executed in callback) According to the message type, corresponding processing is performed: updating variable cache, triggering business logic, recording log / alarm, and generating response if necessary. After processing, return to the event loop and go back to S707 to continue to determine whether to exit.

[0100] S711 stop event loop condition libacp_loop_stop, when the condition is met, call libacp_loop_stop(inst) to stop the event loop smoothly.

[0101] S712 release instance libacp_releaseInstance(inst), call libacp_releaseInstance(inst) to release the communication instance and its binding resources (session, buffer, timer, etc.).

[0102] S713 release ACP initialization resources, call libacp_destory() to release the global resources applied in libacp_init(), and the process ends.

[0103] All the above optional technical solutions can be combined to form optional embodiments of the present application, which will not be repeated here.

[0104] The following is an apparatus embodiment of the present application, which can be used to execute the method embodiments of the present application. For details not disclosed in the apparatus embodiments of the present application, please refer to the method embodiments of the present application.

[0105] The embodiment also provides a data processing apparatus, as shown in Figure 8 The apparatus comprises:

[0106] The parsing module 801 is configured to receive routing data, parse the outer packet header of the routing data, and obtain the logical service number corresponding to the routing data.

[0107] The routing module 802 is configured to determine whether the logical service number is a registered logical service number, and determine the processing mode corresponding to the routing data based on the logical service number in the case where the logical service number is a registered logical service number.

[0108] The processing module 803 is configured to process the routing data based on the processing mode.

[0109] In some embodiments, the routing module 802 is further configured to determine whether the logical service number is a component service registration; in the case that the logical service number is a component service registration, determine that the processing manner corresponding to the routing data is a local component processing manner; in the case that the logical service number is not a component service registration, determine that the processing manner corresponding to the routing data is a forwarding manner.

[0110] In some embodiments, the processing module 803 is further configured to, in the case that the processing manner is a forwarding manner, parse the service call header in the routing data to obtain a command identifier and a call identifier; based on the command identifier and the call identifier, create a request object and add the request object to a request buffer queue corresponding to the current connection to process the request object; when receiving response data generated by callback processing on the request object, construct a response message and call a sending interface to send the response message to the source connection.

[0111] In some embodiments, the processing module 803 is further configured to, in the case that the processing manner is a local component processing manner, call a component callback entry corresponding to the logical service number to create a request object; call a component processor to process the request object, and if the component processor completes processing of the request object, construct a response message and send the response message to the current connection.

[0112] In some embodiments, the processing module 803 is further configured to, in the case that the component processor fails to process the request object, construct a downstream request message; send the downstream request message to a target service through a sending interface, the target service being a service corresponding to the downstream request message; when receiving response data generated by callback processing on the request object, construct a response message and call a sending interface to send the response message to the source connection.

[0113] In some embodiments, the routing module 802 is further configured to, in the case that the logical service number is not a registered logical service number, parse the service call header in the routing data to obtain a call identifier corresponding to the routing data; generate an error response message based on the call identifier and send the error response message to the source connection.

[0114] In some embodiments, the parsing module 801 is further configured to determine whether the routing data contains an outer message header, a service call header, and a service request header; in the case that the routing data contains the outer message header, the service call header, and the service request header, parse the outer message header of the routing data.

[0115] According to the technical solution provided in the embodiments of this application, routing data is received, and the outer header of the routing data is parsed to obtain the logical service number corresponding to the routing data; it is determined whether the logical service number is a registered logical service number; if the logical service number is a registered logical service number, the processing method corresponding to the routing data is determined based on the logical service number; the routing data is processed based on the processing method, firstly, the outer header of the inbound routing data is parsed to obtain the logical service number, and then the determination of whether the logical service number is a registered logical service number is used as a whitelist access control; if the logical service number is a registered logical service number, the processing method is determined based on the logical service number and executed. This forms a unified "identification, judgment, and processing" chain: In scenarios with multiple channels coexisting, such as TCP / UDP / local communication, the logical service number is used as a universal service identifier to achieve accurate and predictable routing of routing data, avoiding misrouting and redundant adaptation caused by each channel acting independently; and when the logical service number is a registered logical service number, the corresponding processing method is selected, which can reduce network hops, latency, and bandwidth overhead when local processing is possible, and maintain a unified processing entry point when external transmission is required, improving overall performance and availability; the "determining whether the logical service number is a registered logical service number" and the "determining the corresponding processing method for routing data based on the logical service number" are decoupled, the interface is clearly abstracted, and it is easy to switch on / off, canary deployment, and expansion evolution, significantly reducing the risk of data routing nodes not being able to accurately process data in cross-channel scenarios and reducing development and maintenance costs, avoiding the problem in existing technologies where data routing nodes cannot accurately process routing data in scenarios with different channels coexisting.

[0116] Figure 9 This is a schematic diagram of the electronic device 9 provided in an embodiment of this application. Figure 9 As shown, the electronic device 9 of this embodiment includes a processor 901, a memory 902, and a computer program 903 stored in the memory 902 and executable on the processor 901. When the processor 901 executes the computer program 903, it implements the steps in the various method embodiments described above. Alternatively, when the processor 901 executes the computer program 903, it implements the functions of each module / unit in the various device embodiments described above.

[0117] Electronic device 9 can be a desktop computer, laptop, handheld computer, cloud server, or other electronic device. Electronic device 9 may include, but is not limited to, processor 901 and memory 902. Those skilled in the art will understand that... Figure 9 This is merely an example of electronic device 9 and does not constitute a limitation on electronic device 9. It may include more or fewer components than shown, or different components.

[0118] The processor 901 can be a central processing unit (CPU), other general purpose processors, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or the like.

[0119] The memory 902 can be an internal storage unit of the electronic device 9, for example, a hard disk or a memory of the electronic device 9. The memory 902 can also be an external storage device of the electronic device 9, for example, a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, or the like equipped on the electronic device 9. The memory 902 can also include both the internal storage unit and the external storage device of the electronic device 9. The memory 902 is used to store computer programs and other programs and data required by the electronic device.

[0120] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the division of the above functional units and modules is taken as an example for illustration, and in actual application, the above functions can be completed by different functional units and modules according to needs, that is, the internal structure of the device is divided into different functional units or modules to complete all or part of the functions described above. Each functional unit and module in the embodiment can be integrated in one processing unit, or each unit can exist physically, or two or more units can be integrated in one unit. The integrated unit can be realized in the form of hardware or in the form of a software functional unit.

[0121] The integrated modules / units, if implemented in the form of software functional units and sold or used as independent products, can be stored in a computer readable storage medium. Based on such understanding, all or part of the processes in the above-mentioned embodiment methods can also be completed by a computer program instructing related hardware, and the computer program can be stored in a computer readable storage medium. The computer program can be executed by a processor to implement the steps of the above-mentioned various method embodiments. The computer program can include computer program code, which can be in the form of source code, object code, executable files, or some intermediate forms. The computer readable medium can include any entity or device capable of carrying the computer program code, recording medium, U disk, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (Read-Only Memory, ROM), random access memory (Random Access Memory, RAM), electric carrier signal, telecommunication signal, and software distribution medium, etc. It should be noted that the content contained in the computer readable medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction, for example, in some jurisdictions, according to legislation and patent practice, the computer readable medium does not include electric carrier signals and telecommunication signals.

[0122] The above embodiments are only used to illustrate the technical solutions of the present application, rather than limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacements for part of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should be included in the protection scope of the present application.< / port>

Claims

1. A data processing method, characterized by, The method comprises: receiving routing data, parsing an outer packet header of the routing data to obtain a logical service number corresponding to the routing data; determining whether the logical service number is a registered logical service number, and in the case where the logical service number is a registered logical service number, determining a processing mode corresponding to the routing data based on the logical service number; processing the routing data based on the processing mode; determining the processing mode corresponding to the routing data based on the logical service number, comprising: judging whether the logical service number is a component service registration; in the case where the logical service number is a component service registration, determining that the processing mode corresponding to the routing data is a local component processing mode; in the case where the logical service number is not a component service registration, determining that the processing mode corresponding to the routing data is a forwarding mode; processing the routing data based on the processing mode, comprising: in the case where the processing mode is a forwarding mode, parsing a service call header in the routing data to obtain a command identifier and a call identifier; based on the command identifier and the call identifier, creating a request object and adding the request object to a request buffer queue corresponding to a current connection to process the request object; when receiving response data generated by callback processing of the request object, constructing a response packet and calling a sending interface to send the response packet to a source connection; processing the routing data based on the processing mode, comprising: in the case where the processing mode is a local component processing mode, calling a component callback entry corresponding to the logical service number to create a request object; calling a component processor to process the request object, and if the component processor completes processing of the request object, constructing a response packet and sending the response packet to a current connection.

2. The method of claim 1, wherein, The method further comprises: if the component processor fails to process the request object, constructing a downstream request packet; sending the downstream request packet to a target service through a sending interface, the target service being a service corresponding to the downstream request packet; when receiving response data generated by callback processing of the request object, constructing a response packet and calling a sending interface to send the response packet to a source connection.

3. The method of claim 1, wherein, The method further comprises: in the case where the logical service number is not a registered logical service number, parsing a service call header in the routing data to obtain a call identifier corresponding to the routing data; generating an error response packet based on the call identifier and sending the error response packet to a source connection.

4. The method of claim 1, wherein, The parsing of the outer packet header of the routing data comprises: determining whether the routing data contains an outer packet header, a service call header and a service request header; in the case where the routing data contains the outer packet header, the service call header and the service request header, parsing the outer packet header of the routing data.

5. A data processing apparatus, characterized by, The device comprises: a parsing module configured to receive routing data, parse an outer packet header of the routing data to obtain a logical service number corresponding to the routing data; The routing module is configured to determine whether the logical service number is a registered logical service number, and determine a processing manner corresponding to the routing data based on the logical service number if the logical service number is a registered logical service number; and the determination of the processing manner corresponding to the routing data based on the logical service number comprises: determining whether the logical service number is a component service registration; determining that the processing manner corresponding to the routing data is a local component processing manner if the logical service number is a component service registration; and determining that the processing manner corresponding to the routing data is a forwarding manner if the logical service number is not a component service registration. The processing module is configured to process the routing data based on the processing manner; and the processing of the routing data based on the processing manner comprises: parsing a service call header in the routing data to obtain a command identifier and a call identifier if the processing manner is a forwarding manner; creating a request object based on the command identifier and the call identifier, and adding the request object to a request buffer queue corresponding to a current connection to process the request object; and constructing a response message and sending the response message to a source connection by calling a sending interface when response data generated by callback processing of the request object is received.

6. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, The processor executes the computer program to implement the steps of the method according to any one of claims 1 to 4.

7. A computer-readable storage medium storing a computer program, wherein the computer program comprises the following steps of: The computer program is executed by the processor to implement the steps of the method according to any one of claims 1 to 4.

Images