Cross-node message sending method, device, equipment, medium and program product

Abstract

The invention provides a cross-node message sending method which can be applied to the field of distributed technologies. The method comprises the following steps: in response to a long connection request of any terminal and a server, creating a message processing entity with a globally unique identifier for long connection in a local memory; in response to a sending operation of an uplink service message of any terminal, analyzing to obtain a terminal identifier of an interaction target terminal; the communication authority between any terminal and the interaction target terminal is authenticated, and after the authentication is passed, bidirectional logic connection mapping is written in the distributed key value storage, and the mapping is used for providing a routing voucher for a cross-node message; and sending the uplink service message to a corresponding message processing entity of a server where the interaction target terminal is located in a point-to-point manner through calling of the remote message processing entity based on the routing credential so as to complete cross-node message sending. The invention further provides a cross-node message sending device and equipment, a storage medium and a program product.

Description

Technical Field

[0001] This application relates to the field of distributed technology, specifically to the field of web technology, and more specifically to a method, apparatus, device, medium, and program product for sending messages across nodes. Background Technology

[0002] With the widespread adoption of the WebSocket protocol, servers commonly employ multi-node cluster deployments to support massive long-lived connections. Among related technologies, WebSocket clusters use a message bus broadcast method for cross-node forwarding. However, the message bus broadcast method has the following drawbacks: network traffic increases linearly with the number of nodes, creating a broadcast storm; it requires the deployment of a powerful message middleware, which handles a large number of invalid messages, resulting in high CPU and memory overhead and wasted resources; and message latency is affected by middleware backlog, making it impossible to guarantee low latency. Therefore, a cross-node message sending method is urgently needed to solve these technical problems. Summary of the Invention

[0003] In view of the above problems, this application provides a method, apparatus, device, medium and program product for cross-node message sending with self-synchronization throughout the life cycle, zero broadcast and low latency.

[0004] According to a first aspect of this application, a cross-node message sending method is provided, comprising: responding to a long connection request between any terminal and a server, creating a message processing entity with a globally unique identifier for the long connection in local memory, wherein the globally unique identifier is generated by digest operation of a terminal identifier, a server network address, and a connection timestamp; responding to an uplink service message sending operation of any terminal, parsing to obtain the terminal identifier of the interactive target terminal; authenticating the communication permissions between the any terminal and the interactive target terminal, and after successful authentication, writing a bidirectional logical connection mapping in a distributed key-value store, the mapping including at least: a peer terminal identifier, a peer server network address, and a peer message processing entity identifier, used to provide routing credentials for cross-node messages; and based on the routing credentials, sending the uplink service message point-to-point to the corresponding message processing entity of the server where the interactive target terminal is located through a remote message processing entity call, thereby completing the cross-node message sending.

[0005] According to an embodiment of this application, the method further includes: upon detecting that the first terminal actively exits, the target terminal actively exits, or any corresponding long connection is disconnected, immediately deleting the bidirectional logical connection mapping and asynchronously notifying the peer server to delete its mapping record pointing to the exited terminal.

[0006] According to an embodiment of this application, the method further includes: setting a lifespan for the bidirectional logical connection mapping and starting a periodic heartbeat renewal task, wherein the heartbeat renewal task resets the lifespan each time a heartbeat frame of the long connection is received.

[0007] According to an embodiment of this application, the method further includes: writing the correspondence between the identifier of the message processing entity and the corresponding terminal identifier into a local hash table.

[0008] According to an embodiment of this application, point-to-point message transmission based on the routing credentials includes: when the source server does not find the message processing entity of the target terminal locally, using the peer terminal identifier as the key, reading the peer server network address and peer message processing entity identifier from the distributed key-value store, constructing a remote message processing entity invocation request, and sending it to the target server via a transmission control protocol connection; after receiving the remote message processing entity invocation request, the target server locates the corresponding message processing entity locally according to the peer message processing entity identifier, and pushes the uplink service message to the interactive target terminal through the message processing entity.

[0009] According to an embodiment of this application, the lifecycle of the message processing entity is consistent with that of the long connection, and it is automatically destroyed when the long connection is disconnected.

[0010] A second aspect of this application provides a cross-node message sending apparatus, comprising: a message processing entity creation module, configured to, in response to a long connection request between any terminal and a server, create a message processing entity with a globally unique identifier in local memory for the long connection, wherein the globally unique identifier is generated by digest operation of a terminal identifier, a server network address, and a connection timestamp; a parsing module, configured to, in response to an uplink service message sending operation of any terminal, parse to obtain the terminal identifier of the interactive target terminal; a bidirectional logical connection mapping creation module, configured to, on the server side, authenticate the communication permissions between the any terminal and the interactive target terminal, and after successful authentication, write a bidirectional logical connection mapping in a distributed key-value store, the mapping including at least: a peer terminal identifier, a peer server network address, and a peer message processing entity identifier, used to provide routing credentials for cross-node messages; and a message sending module, configured to, based on the routing credentials, send the uplink service message point-to-point to the corresponding message processing entity of the server where the interactive target terminal is located through a remote message processing entity call, thereby completing the cross-node message sending.

[0011] According to an embodiment of this application, the device further includes a deletion module.

[0012] The deletion module is used to immediately delete the bidirectional logical connection mapping when it detects that the first terminal has actively exited, the target terminal has actively exited, or any corresponding long connection has been disconnected, and asynchronously notify the peer server to delete the mapping record pointing to the exited terminal.

[0013] According to an embodiment of this application, the device further includes a heartbeat monitoring module.

[0014] The heartbeat monitoring module is used to set a lifespan for the bidirectional logical connection mapping and to start a periodic heartbeat renewal task. The heartbeat renewal task resets the lifespan each time a heartbeat frame of the long connection is received.

[0015] According to an embodiment of this application, the apparatus further includes a writing module.

[0016] The writing module is used to write the correspondence between the identifier of the message processing entity and the corresponding terminal identifier into a local hash table.

[0017] According to an embodiment of this application, the message sending module includes a query submodule and a sending submodule.

[0018] The query submodule is used to, when the message processing entity of the target terminal is not found locally on the source server, read the network address of the peer server and the peer message processing entity identifier from the distributed key-value store using the peer terminal identifier as the key, construct a remote message processing entity invocation request, and send it to the target server via a transmission control protocol connection; the sending submodule is used to, after the target server receives the remote message processing entity invocation request, locate the corresponding message processing entity locally according to the peer message processing entity identifier, and push the uplink business message to the interactive target terminal through the message processing entity.

[0019] A third aspect of this application provides an electronic device comprising: one or more processors; and a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the method described above.

[0020] A fourth aspect of this application also provides a computer-readable storage medium having a computer program or instructions stored thereon, which, when executed by a processor, implement the steps of the above-described method.

[0021] The fifth aspect of this application also provides a computer program product, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described method. Attached Figure Description

[0022] The above-mentioned contents, other objects, features and advantages of this application will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0023] Figure 1 The illustration shows an application scenario diagram of the cross-node message sending method, apparatus, device, medium, and program product according to embodiments of this application;

[0024] Figure 2 A flowchart illustrating a cross-node message sending method according to an embodiment of this application is shown schematically.

[0025] Figure 3 A flowchart illustrating a cross-node message sending method according to another embodiment of this application is shown schematically;

[0026] Figure 4 A schematic diagram illustrating a cross-node message sending apparatus according to an embodiment of this application is shown; and

[0027] Figure 5 A block diagram schematically illustrates an electronic device suitable for implementing a cross-node message sending method according to an embodiment of this application. Detailed Implementation

[0028] The embodiments of this application will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of this application. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of this application for ease of explanation. However, it will be apparent that one or more embodiments may be implemented without these specific details. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concepts of this application.

[0029] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The terms “comprising,” “including,” etc., as used herein indicate the presence of the stated features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0030] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0031] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0032] With the widespread adoption of the WebSocket protocol, servers commonly employ multi-node cluster deployments to support massive long-lived connections. Currently, the mainstream cross-node message forwarding solutions mainly fall into two categories:

[0033] (1) Message bus broadcast mode

[0034] All WebSocket nodes in the cluster subscribe to the same message topic. When any node receives an upstream message, it broadcasts the message to all nodes through the message middleware. Each node then determines whether the target terminal holds the message locally; otherwise, it discards it. This approach results in: network traffic increasing linearly with the number of nodes, creating a broadcast storm; the middleware needing to handle a large number of invalid messages, leading to high CPU and memory overhead; and message latency being affected by middleware backlog, making it impossible to guarantee low latency.

[0035] (2) Centralized session registry method

[0036] The database records "terminal → node" mappings. The message sender first queries the mapping and then pushes the message to the target node via a remote procedure call channel. While this method reduces broadcasting, it still has drawbacks: the mapping records lack an automatic expiration mechanism, leading to ghost routes and message loss when the terminal disconnects abnormally; the mapping only provides the node IP, requiring the receiver to maintain a secondary index locally to locate the specific connection, adding another hash calculation and lock contention; and the lack of binding between the "connection-entity" lifecycle means that mapping and entity recycling are out of sync when a node fails, requiring manual intervention for cleanup.

[0037] To address the aforementioned technical issues, embodiments of this application provide a cross-node message sending method, comprising: responding to a long connection request between any terminal and a server, creating a message processing entity with a globally unique identifier for the long connection in local memory, wherein the globally unique identifier is generated by digesting a terminal identifier, a server network address, and a connection timestamp; responding to an uplink service message sending operation from any terminal, parsing to obtain the terminal identifier of the target terminal; authenticating the communication permissions between the terminal and the target terminal, and upon successful authentication, writing a bidirectional logical connection mapping in a distributed key-value store, wherein the mapping includes at least: a peer terminal identifier, a peer server network address, and a peer message processing entity identifier, used to provide routing credentials for cross-node messages; and based on the routing credentials, sending the uplink service message point-to-point to the corresponding message processing entity of the server where the target terminal is located via a remote message processing entity call, thereby completing the cross-node message sending.

[0038] The cross-node message sending method provided in the embodiments of this application takes the "local message processing entity with strong coupling between lifecycle and long connection" as the anchor point. Through a three-step closed loop of "generating a globally unique entity identifier with a single digest → solidifying bidirectional logical connection mapping with distributed key-value storage → remote entity invocation based on mapping", it achieves zero broadcasting and O(1) precise delivery of WebSocket cross-node messages, and ensures that routing credentials and connection status are automatically synchronized and expired, thereby solving the three major defects of broadcast storm, ghost routing and secondary index delay in related technologies at the same time.

[0039] Figure 1 The illustration schematically depicts an application scenario of a cross-node message sending method, apparatus, device, medium, and program product according to embodiments of this application.

[0040] like Figure 1 As shown, application scenario 100 according to this embodiment may include a terminal interaction scenario. Network 104 serves as a medium for providing a communication link between the first terminal device 101, the second terminal device 102, the third terminal device 103, and the server 105. Network 104 may include various connection types, such as wired or wireless communication links or fiber optic cables, etc.

[0041] Users can use the first terminal device 101, the second terminal device 102, and the third terminal device 103 to interact with the server 105 via the network 104 to receive or send messages, etc. Various communication client applications can be installed on the first terminal device 101, the second terminal device 102, and the third terminal device 103, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (for example only).

[0042] The first terminal device 101, the second terminal device 102, and the third terminal device 103 can be various electronic devices with displays and support web browsing, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0043] Server 105 can be a server that provides various services, such as a backend management server that supports websites browsed by users using the first terminal device 101, the second terminal device 102, and the third terminal device 103 (this is just an example). The backend management server can analyze and process data such as received user requests, and feed back the processing results (such as web pages, information, or data obtained or generated according to user requests) to the terminal devices.

[0044] It should be noted that the cross-node message sending method provided in this application embodiment can generally be executed by server 105. Correspondingly, the cross-node message sending device provided in this application embodiment can generally be located in server 105. The cross-node message sending method provided in this application embodiment can also be executed by a server or server cluster that is different from server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or server 105. Correspondingly, the cross-node message sending device provided in this application embodiment can also be located in a server or server cluster that is different from server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or server 105.

[0045] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0046] The following will be based on Figure 1 The described scene, through Figures 2-5 A cross-node message sending method according to embodiments of this application will be described in detail.

[0047] Figure 2 A flowchart illustrating a cross-node message sending method according to an embodiment of this application is shown schematically.

[0048] like Figure 2 As shown, the cross-node message sending method of this embodiment includes operations S210 to S240, which can be executed by a server or other computing device.

[0049] In operation S210, in response to any long connection request between a terminal and the server, a message processing entity with a globally unique identifier is created in local memory for the long connection, wherein the globally unique identifier is generated by digest operation of terminal identifier, server network address and connection timestamp.

[0050] In one example, during the startup phase of server node M, a concurrent framework is initialized. Once terminal A completes the three-way handshake of the Transmission Control Protocol (TCP) and the WebSocket protocol upgrade is successful, the framework callback interface is triggered. Node M instantiates a message processing entity in its local heap memory. This entity can be implemented using the Actor model, and its globally unique identifier is generated as follows: The user's unique code for terminal A, the IPv4 address of node M, and the current nanosecond-level timestamp are concatenated into a raw string. A SHA-256 digest operation is performed on this string, and the first 32 bytes of the hexadecimal result are used as the entity name. This entity is registered in node M's entity container, which holds an entity pointer and establishes a one-to-one mapping with the file descriptor of the TCP channel. Since the identifier generation algorithm includes the server network address and timestamp, different entity names can still be generated when the same terminal reconnects multiple times within milliseconds or reconnects across nodes, thus avoiding naming conflicts within the cluster. The fixed length of the digest operation result allows the entity container to adopt an array index + hash mixed sorting strategy, and the entity lookup time complexity is stable at O(1), providing deterministic delay for subsequent high-concurrency message delivery.

[0051] According to an embodiment of this application, the lifecycle of the message processing entity is consistent with that of the long connection, and it is automatically destroyed when the long connection is disconnected.

[0052] In one example, after the message processing entity is created, node M binds the entity's lifecycle to the file descriptor of the TCP connection: when the kernel notifies of a connection readable event and returns a length of 0, it is determined that the other end has sent the finish bit (FIN). Node M immediately calls the entity's destructor to release the heap memory occupied by the entity, unregister timers, and erase the corresponding entry in the entity container. If the connection is abnormally reset, the framework's exception callback will also trigger the above destruction process. The entity and connection state are strongly coupled, ensuring that memory resources are reclaimed the moment the connection disappears, eliminating the risk of entity leakage; at the same time, since the destruction action is completed within the same thread of the event loop, thread safety can be guaranteed without locking, reducing the additional overhead caused by lock contention.

[0053] In operation S220, in response to the uplink service message sending operation of any terminal, the terminal identifier of the target terminal is parsed and obtained.

[0054] In operation S230, the communication permissions between any terminal and the target interactive terminal are authenticated. After successful authentication, a bidirectional logical connection mapping is written into the distributed key-value store. The mapping includes at least: peer terminal identifier, peer server network address and peer message processing entity identifier, which are used to provide routing credentials for cross-node messages.

[0055] According to an embodiment of this application, a lifespan is set for the bidirectional logical connection mapping, and a periodic heartbeat renewal task is started. The heartbeat renewal task resets the lifespan each time a heartbeat frame of the long connection is received.

[0056] In one example, terminal A sends a business message via an established WebSocket connection. The message frame payload is serialized using a structured binary encoding scheme to ensure compact data, cross-platform compatibility, and efficient parsing. It contains the field `target_id=0x0B7F`. The decoding module of server node M performs deserialization within its event loop thread, extracting the `target_id` value as the terminal identifier for the target terminal B, and encapsulating this identifier as an input parameter for the subsequent authentication process. Node M calls the authentication microservice interface, with a request message containing `{caller=A_UID, callee=B_UID, cmd=chat}`. The authentication service checks whether terminal A and terminal B are in the same tenant space; confirms the bidirectional membership; and returns an `ALLOW` result. After receiving the ALLOW, node M writes a bidirectional logical connection mapping to the distributed key-value store through the built-in atomic transaction script on the server side. The key is ws:link:A, and the fields include peer=B, srv=192.168.x.xx:25520, entity=ent_B, and sets the time to live (TTL), which can be, for example, 3600 seconds.

[0057] In one example, after the mapping is written, node M starts a scheduled task with a 25-second cycle. The task logic is implemented using a timer mechanism. Each time a heartbeat frame (Ping control frame) is received from terminal A, the scheduled task resets the TTL of the mapping key to 3600 seconds. If no heartbeat is received three times consecutively, the TTL expires naturally, and the mapping record is automatically deleted by the distributed key-value store. The heartbeat renewal mechanism ensures that the mapping of active terminals remains valid, and the mapping of offline terminals can be automatically cleared within seconds without manual intervention. Compared with timed polling, automatic TTL deletion reduces deletion operation traffic by about 90%, significantly reducing the backend load.

[0058] In operation S240, based on the routing credentials, the uplink service message is sent point-to-point to the corresponding message processing entity of the server where the interactive target terminal is located through a remote message processing entity call, so as to complete the cross-node message sending.

[0059] In one example, server node M, unable to find the entity record for terminal B in its local cache, initiates a hash read from the distributed key-value store using B's terminal identifier as the key, obtaining routing credentials {peer=B, srv=192.168.x.xx:25520, entity=ent_B}. Based on the srv field and the pre-established TCP connection with target node N, node M constructs a remote procedure call (RPC) frame: the frame header carries the entity name ent_B, and the frame body encapsulates the uplink business message encoded in structured binary. This frame is written to the Transmission Control Protocol (TCP) connection via an asynchronous network channel, enters the network interface card (NIC) via a kernel system call, and reaches node N. Upon receiving the RPC frame, node N's protocol decoder extracts the entity name ent_B and, within its local Actor-based concurrent system, completes the lookup and message delivery of the target message processing entity using an entity location mechanism. Subsequently, node N places the deserialized business message into the entity's mailbox queue. The entity retrieves the message in an independent scheduling thread, writes it to the kernel's send buffer via a WebSocket frame, and finally pushes it to terminal B. After message delivery is complete, node N returns an acknowledgment frame to node M. Upon receiving the acknowledgment frame, node M updates its sliding window and releases its sending buffer. If node M does not receive an acknowledgment frame within 500 ms, it retryes the remote call, up to three times. After three failures, node M marks the mapping as suspicious and triggers an asynchronous probe task to prevent erroneous teardown due to momentary network jitter.

[0060] The cross-node message sending method provided by the embodiments of this application generates a globally unique message processing entity for each long connection in local memory on the spot, and forms an entity name by digesting the terminal identifier, server network address and connection timestamp; it provides a definite and unique addressing reference for subsequent routing, avoids naming conflicts within the cluster, and lays the foundation for lock-free concurrency; it writes a bidirectional logical connection mapping containing the peer terminal identifier, server network address and message processing entity identifier at once through distributed key-value storage, and solidifies the parsing result into a persistent routing credential, realizing "one-hash, instant location", while the automatic expiration feature of distributed storage ensures that the mapping life cycle is synchronized with the connection state, eliminating ghost routes; based on the routing credential, the source node directly initiates a remote call to the message processing entity of the target node through the established transmission control protocol connection; through the precise address provided by the preceding mapping, it skips broadcast or centralized queues and completes sub-millisecond point-to-point delivery, reducing the cross-node message path from O(n) to O(1). Each step does not require global locks or secondary indexes, thus maintaining linear bandwidth growth, constant low latency, and high throughput even as the cluster size expands, completely solving the problems of broadcast storms, routing delays, and inconsistent lifecycles in existing technologies.

[0061] According to an embodiment of this application, after operation S210, the method further includes: writing the correspondence between the identifier of the message processing entity and the corresponding terminal identifier into a local hash table.

[0062] In one example, after the message processing entity is successfully created, node M inserts the key-value pair "UserIdentifier (UID) → Entity Name of Terminal A" into the local cache. The insertion operation is completed synchronously within the entity registration callback. When node M receives an upstream message, it first queries the hash table by UID: if a match is found, the entity reference is directly obtained and the message delivery is completed in the current thread; if a match is not found, the distributed key-value store is queried to determine whether cross-node forwarding is required. The local hash table transforms hotspot routing into a memory-level O(1) lookup, saving one remote query. The hash table only stores online records, and memory usage is linearly related to the number of connections. There is no redundant data, and read / write operations in the same thread avoid lock contention. A single node can support millions of connections, improving throughput.

[0063] According to an embodiment of this application, the method further includes: upon detecting that the first terminal actively exits, the target terminal actively exits, or any corresponding long connection is disconnected, immediately deleting the bidirectional logical connection mapping and asynchronously notifying the peer server to delete its mapping record pointing to the exited terminal.

[0064] In one example, after receiving a connection termination message from terminal A, the transport layer of node M immediately triggers a connection close callback. This callback executes a server-side built-in atomic transaction script, deleting the key and its corresponding field pointing to terminal B from the distributed key-value store in one go. Then, it asynchronously sends a mapping cleanup request message to node N via a one-way remote call; the message body contains only the terminal identifier A to be cleared. Upon receiving this message, node N removes the entity reference to A from its local cache and returns an acknowledgment frame to complete the cleanup. The entire process is completed within a very short time (5 ms), ensuring that the mapping record is consistent with the TCP connection state in real time. The atomic script avoids data races caused by concurrent deletions, prevents ghost routing, and reduces message misdelivery rate.

[0065] In one example, terminal B initiates an "exit room" control frame. After parsing it, node N first sets B's status to "left" and then calls the aforementioned atomic transaction script to delete ws:link:B. After successful deletion, node N sends a clear frame to node M through the same TCP long connection. After receiving the frame, node M clears the entry for B→ent_B in its local hash table and releases the relevant memory.

[0066] In one example, under network anomaly scenario, if node M fails to receive heartbeat pings from node A three times consecutively, it determines that the connection has failed. At this point, node M starts a "suspicious mapping" timer. If the connection is not restored within 500 ms, it forcibly deletes ws:link:A and asynchronously notifies the peer. The notification message carries a failure reason code, which node N uses to record the failure metric for subsequent load balancing decisions. ws:link:A / B are keys used in the distributed key-value store to store bidirectional logical connection mappings. ws:link:B stores peer information from the perspective of terminal B, while ws:link:A stores peer information from the perspective of terminal A. These two records together constitute bidirectional routing credentials, supporting precise cross-node delivery in both A→B and B→A directions. They are deleted by their respective nodes when the connection is broken or terminated, ensuring eventual consistency of the cluster mapping data.

[0067] Figure 3 A flowchart illustrating a cross-node message sending method according to another embodiment of this application is shown schematically. Figure 3 As shown, operation S240 includes operation S241 and operation S242.

[0068] In operation S241, if the message processing entity of the target terminal is not found locally on the source server, the network address of the peer server and the identifier of the peer message processing entity are read from the distributed key-value store using the peer terminal identifier as the key, a remote message processing entity invocation request is constructed and sent to the target server via the transmission control protocol connection.

[0069] In operation S242, after the target server receives the remote message processing entity call request, it locates the corresponding message processing entity locally according to the peer message processing entity identifier, and pushes the uplink business message to the interactive target terminal through the message processing entity.

[0070] In one example, if the source server node M does not find the entity record for the target terminal B in its local hash table, it initiates a hash read from the distributed key-value store using B's terminal identifier as the key to obtain routing credentials {peer terminal identifier = B, peer server network address = 192.168.x.xx:25520, peer message processing entity identifier = ent_B}. Node M reuses the long-lived Transmission Control Protocol (TCP) connection pre-established with node N to construct a Remote Invocation Protocol (RIMPAC) frame: the frame header carries the entity identifier ent_B, and the frame body serializes the uplink business message using a structured binary encoding format, sending it to node N through the kernel send buffer. After receiving the frame, node N's protocol decoder extracts the entity identifier ent_B, performs a lookup within its local Actor-based concurrent system using an entity location mechanism, and places the deserialized business message into the entity's mailbox queue. The entity retrieves the message in an independent scheduling thread, pushes it to terminal B via a WebSocket frame, and then sends back an acknowledgment frame. After receiving the acknowledgment frame, node M releases its send buffer, completing reliable delivery. By leveraging existing long-lived connection channels to eliminate TCP handshake overhead, a single hash lookup can locate the target entity, reducing message delivery latency; the entity mailbox mechanism decouples processing threads from network I / O, avoiding lock contention, and a single node can support millions of concurrent entities; the combination of acknowledgment frames and retry mechanisms greatly reduces message loss rate and significantly improves system availability.

[0071] Based on the above-described cross-node message sending method, this application also provides a cross-node message sending apparatus. The following will be combined with... Figure 4 The device is described in detail.

[0072] Figure 4 A schematic block diagram of a cross-node message sending apparatus according to an embodiment of this application is shown.

[0073] like Figure 4 As shown, the cross-node message sending device 400 of this embodiment includes a message processing entity creation module 410, a parsing module 420, a bidirectional logical connection mapping creation module 430, and a message sending module 440.

[0074] The message processing entity creation module 410 is used to respond to any long connection request between a terminal and a server by creating a message processing entity with a globally unique identifier in local memory for the long connection. This globally unique identifier is generated by digesting the terminal identifier, the server network address, and the connection timestamp. In one embodiment, the message processing entity creation module 410 can be used to perform the operation S210 described above, which will not be repeated here.

[0075] The parsing module 420 is used to parse the terminal identifier of the target terminal in response to the uplink service message sending operation of any terminal. In one embodiment, the parsing module 420 can be used to perform the operation S220 described above, which will not be repeated here.

[0076] The bidirectional logical connection mapping creation module 430 is used to authenticate the communication permissions between any terminal and the target interactive terminal on the server side. After successful authentication, a bidirectional logical connection mapping is written into the distributed key-value store. The mapping includes at least: the peer terminal identifier, the peer server network address, and the peer message processing entity identifier, which are used to provide routing credentials for cross-node messages. In one embodiment, the bidirectional logical connection mapping creation module 430 can be used to perform the operation S230 described above, which will not be repeated here.

[0077] The message sending module 440 is used to send the uplink service message point-to-point to the corresponding message processing entity of the server where the interactive target terminal is located, based on the routing credentials, through a remote message processing entity call, thereby completing cross-node message sending. In one embodiment, the message sending module 440 can be used to perform the operation S240 described above, which will not be repeated here.

[0078] According to an embodiment of this application, the device further includes a deletion module.

[0079] The deletion module is used to immediately delete the bidirectional logical connection mapping when it detects that the first terminal has actively exited, the target terminal has actively exited, or any corresponding long connection has been disconnected, and asynchronously notify the peer server to delete the mapping record pointing to the exited terminal.

[0080] According to an embodiment of this application, the device further includes a heartbeat monitoring module.

[0081] The heartbeat monitoring module is used to set a lifespan for the bidirectional logical connection mapping and to start a periodic heartbeat renewal task. The heartbeat renewal task resets the lifespan each time a heartbeat frame of the long connection is received.

[0082] According to an embodiment of this application, the apparatus further includes a writing module.

[0083] The writing module is used to write the correspondence between the identifier of the message processing entity and the corresponding terminal identifier into a local hash table.

[0084] According to an embodiment of this application, the message sending module includes a query submodule and a sending submodule.

[0085] The query submodule is used to, when the message processing entity of the target terminal is not found locally on the source server, read the network address of the peer server and the peer message processing entity identifier from the distributed key-value store using the peer terminal identifier as the key, construct a remote message processing entity invocation request, and send it to the target server via a transmission control protocol connection; the sending submodule is used to, after the target server receives the remote message processing entity invocation request, locate the corresponding message processing entity locally according to the peer message processing entity identifier, and push the uplink business message to the interactive target terminal through the message processing entity.

[0086] According to embodiments of this application, any plurality of modules among the message processing entity creation module 410, parsing module 420, bidirectional logical connection mapping creation module 430, and message sending module 440 can be merged into one module, or any one of these modules can be split into multiple modules. Alternatively, at least part of the functionality of one or more of these modules can be combined with at least part of the functionality of other modules and implemented in one module. According to embodiments of this application, at least one of the message processing entity creation module 410, parsing module 420, bidirectional logical connection mapping creation module 430, and message sending module 440 can be at least partially implemented as hardware circuitry, such as a field-programmable gate array (FPGA), a programmable logic array (PLA), a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit (ASIC), or any other reasonable means of integrating or packaging circuitry, or implemented in hardware or firmware, or in any one of software, hardware, and firmware implementations, or in a suitable combination of any of these. Alternatively, at least one of the message processing entity creation module 410, parsing module 420, bidirectional logical connection mapping creation module 430, and message sending module 440 may be implemented at least partially as a computer program module, which can perform corresponding functions when the computer program module is run.

[0087] Figure 5 A block diagram schematically illustrates an electronic device suitable for implementing a cross-node message sending method according to an embodiment of this application.

[0088] like Figure 5As shown, an electronic device 500 according to an embodiment of this application includes a processor 501, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 502 or a program loaded from a storage portion 508 into a random access memory (RAM) 503. The processor 501 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 501 may also include onboard memory for caching purposes. The processor 501 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of this application.

[0089] RAM 503 stores various programs and data required for the operation of electronic device 500. Processor 501, ROM 502, and RAM 503 are interconnected via bus 504. Processor 501 executes various operations of the method flow according to embodiments of this application by executing programs in ROM 502 and / or RAM 503. It should be noted that the programs may also be stored in one or more memories other than ROM 502 and RAM 503. Processor 501 may also execute various operations of the method flow according to embodiments of this application by executing programs stored in said one or more memories.

[0090] According to embodiments of this application, the electronic device 500 may further include an input / output (I / O) interface 505, which is also connected to a bus 504. The electronic device 500 may also include one or more of the following components connected to the input / output (I / O) interface 505: an input section 506 including a keyboard, mouse, etc.; an output section 507 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 508 including a hard disk, etc.; and a communication section 509 including a network interface card such as a LAN card, modem, etc. The communication section 509 performs communication processing via a network such as the Internet. A drive 510 is also connected to the input / output (I / O) interface 505 as needed. A removable medium 511, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 510 as needed so that computer programs read from it can be installed into the storage section 508 as needed.

[0091] This application also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application.

[0092] According to embodiments of this application, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this application, the computer-readable storage medium may include ROM 502 and / or RAM 503 and / or one or more memories other than ROM 502 and RAM 503 described above.

[0093] Embodiments of this application also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code enables the computer system to implement the cross-node message sending method provided in the embodiments of this application.

[0094] When the computer program is executed by the processor 501, it performs the functions defined in the system / apparatus of this application embodiment. According to the embodiments of this application, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0095] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and may be downloaded and installed via the communication section 509, and / or installed from a removable medium 511. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0096] In such an embodiment, the computer program can be downloaded and installed from a network via communication section 509, and / or installed from removable medium 511. When the computer program is executed by processor 501, it performs the functions defined in the system of this application embodiment. According to embodiments of this application, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0097] According to embodiments of this application, program code for executing the computer programs provided in the embodiments of this application can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, Python, "C", or similar programming languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0098] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0099] Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments of this application can be combined and / or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application.

Claims

1. A method for sending messages across nodes, characterized in that, The method includes: In response to any long connection request between a terminal and a server, a message processing entity with a globally unique identifier is created in local memory for the long connection, wherein the globally unique identifier is generated by digest operation of terminal identifier, server network address and connection timestamp; In response to the sending operation of uplink service messages from any terminal, the terminal identifier of the target terminal is parsed to obtain the terminal identifier of the interactive target terminal; The communication permissions between any terminal and the target terminal are authenticated. Upon successful authentication, a bidirectional logical connection mapping is written to a distributed key-value store. This mapping includes at least: a peer terminal identifier, a peer server network address, and a peer message processing entity identifier, used to provide routing credentials for cross-node messages; and Based on the routing credentials, the upstream business message is sent point-to-point to the corresponding message processing entity of the server where the interactive target terminal is located through a remote message processing entity call, so as to complete the cross-node message sending.

2. The method according to claim 1, characterized in that, The method further includes: Upon detecting that the first terminal actively exits, the target terminal actively exits, or any corresponding long connection is broken, the bidirectional logical connection mapping is immediately deleted, and the peer server is asynchronously notified to delete its mapping record pointing to the exited terminal.

3. The method according to claim 1, characterized in that, The method further includes: A time-to-live (TTL) is set for the bidirectional logical connection mapping, and a periodic heartbeat renewal task is started. The heartbeat renewal task resets the TTL each time a heartbeat frame of the long connection is received.

4. The method according to claim 1, characterized in that, The method further includes: Write the correspondence between the identifier of the message processing entity and the corresponding terminal identifier into a local hash table.

5. The method according to claim 1, characterized in that, Point-to-point message sending based on the routing credentials includes: If the message processing entity of the target terminal is not found on the source server, the network address of the peer server and the identifier of the peer message processing entity are read from the distributed key-value store using the peer terminal identifier as the key, a remote message processing entity invocation request is constructed and sent to the target server via the transmission control protocol connection. After receiving the remote message processing entity call request, the target server locates the corresponding message processing entity locally based on the peer message processing entity identifier, and pushes the uplink business message to the interactive target terminal through the message processing entity.

6. The method according to any one of claims 1 to 5, characterized in that, The lifecycle of the message processing entity is consistent with that of the long connection, and it is automatically destroyed when the long connection is closed.

7. A cross-node message sending device, characterized in that, The device includes: The message processing entity creation module is used to respond to any long connection request between a terminal and a server, and create a message processing entity with a globally unique identifier in local memory for the long connection, wherein the globally unique identifier is generated by digest operation of terminal identifier, server network address and connection timestamp; The parsing module is used to respond to the sending operation of uplink service messages from any terminal and parse the terminal identifier of the target terminal. A bidirectional logical connection mapping creation module is used to authenticate the communication permissions between any terminal and the target interactive terminal on the server side. After successful authentication, a bidirectional logical connection mapping is written into a distributed key-value store. The mapping includes at least: a peer terminal identifier, a peer server network address, and a peer message processing entity identifier, used to provide routing credentials for cross-node messages; and The message sending module is used to send the uplink business message point-to-point to the corresponding message processing entity of the server where the interactive target terminal is located, based on the routing credentials, through a remote message processing entity call, so as to complete the cross-node message sending.

8. An electronic device, comprising: One or more processors; Memory, used to store one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 6.

Images