System and Method for Operating a Programmable Message Router

Abstract

The present invention relates to a programmable message router system and a method for operating the same, which performs dynamic routing and processing of messages using a lightweight virtual machine that executes routing scripts while performing direct communication between nodes without a central broker. The system comprises a lightweight virtual machine for executing routing scripts, a dynamic routing engine that determines a destination and performs message processing by analyzing the header or payload of a message through the lightweight virtual machine, a sequencing module that assigns a serial number to the message and records the transmission and reception status of the message, a script management module that stores the routing script in version units and switches the active routing script during runtime, and a message delivery unit that transmits the processed message through direct communication between a plurality of router nodes. The dynamic routing engine can track the transmission and reception status even in a brokerless environment by means of a programmable message router system that reflects the active routing script switched by the script management module in real time into the destination determination and message processing logic during runtime. Furthermore, if a missing or lost message occurs at a receiving node, the corresponding message can be extracted from an evidence log and retransmitted based on a notification of the missing serial number or a sequence range request, thereby improving reliability and fault recovery in a high-volume message environment.

Description

Technology Field

[0001] The present invention relates to a message delivery technology in a distributed system, and more specifically, to a programmable message router system and a method for operating the same that performs dynamic routing and processing of messages using a lightweight virtual machine that executes routing scripts while performing direct communication between nodes without a central broker. Background Technology

[0003] In general, modern large-scale distributed systems utilize Message-Oriented Communication (MMC) and push messaging patterns—a unidirectional delivery method—to ensure independence between services and enhance real-time performance. For instance, in environments such as front-end processors (FEPs) in the financial sector or large-scale IoT data transmission, a communication architecture capable of delivering millions of bulk messages per second to destinations without delay is required. In such environments, a messaging infrastructure is essential that allows the sender and receiver to operate independently while reliably distributing messages to multiple destinations.

[0004] Meanwhile, conventional messaging systems generally adopt a structure that relays messages centered around a centralized broker. For example, some publicly available messaging platforms are designed to perform message queuing, routing, and consumer group management through the broker. However, a structure where message flow is concentrated on a central broker inevitably entails a Single Point of Failure (SPOF) problem, posing a risk that message delivery throughout the entire system may be delayed or interrupted in the event of a broker failure.

[0005] In environments involving high-volume message transmission, the load is concentrated on the broker, leading to performance bottlenecks and making horizontal scaling or partitioning designs to resolve these issues complex. As message routing becomes more complex, brokers are sometimes configured hierarchically; however, such a hierarchical broker structure can increase the hop count on the message delivery path, thereby exacerbating end-to-end latency. Particularly in environments where real-time performance is critical, such as financial quote transmission or low-latency IoT control, an increase in hops on the delivery path becomes a major factor degrading system quality.

[0006] On the other hand, while the brokerless approach, which eliminates brokers and enables direct communication between nodes, can be advantageous in that it alleviates central bottlenecks and reduces delivery delays, it is difficult to implement mechanisms for tracking and recovering lost messages due to the absence of a central queue or repository. In other words, in the brokerless method, securing resilience—which involves fully auditing the transmission and reception status of bulk messages and retransmitting missing messages or messages from specific points in time—becomes a technically critical challenge. Consequently, there is a continuously increasing demand for advanced sequencing and logging mechanisms in bulk message environments that assign sequence numbers based on message inflow and outflow times, record transmission and reception status, and enable the retransmission of specific message ranges when necessary. The problem to be solved

[0008] The present invention is derived from this technical background and aims to provide a programmable message router system and method that can change routing and message processing logic in real time without interruption of operation, while resolving the single point of failure (SPOF), performance bottleneck, and delay problems caused by increased hop counts that occur in centralized broker methods when supporting message-oriented communication and PUSH messaging environments in large-scale distributed systems. means of solving the problem

[0010] The present invention for achieving the above objectives includes the following configuration.

[0011] That is, a programmable message router system according to one embodiment of the present invention comprises a lightweight virtual machine for executing a routing script, a dynamic routing engine that determines a destination and performs message processing by analyzing the header or payload of a message through the lightweight virtual machine, a sequencing module that assigns a serial number to the message and records the transmission and reception status of the message, a script management module that stores the routing script in version units and switches the active routing script during runtime, and a message delivery unit that transmits the processed message through direct communication between a plurality of router nodes, wherein the dynamic routing engine reflects the active routing script switched by the script management module in real time to the destination determination and message processing logic during runtime. Effects of the invention

[0013] According to a programmable message router system and a method for operating the same according to an embodiment of the present invention, message processing is performed asynchronously regardless of the availability of the receiving side, and by assigning a sequence number to the transmitted message and recording evidence logs corresponding to the incoming and outgoing times in full or on a policy basis, the transmission and reception status can be tracked even in a brokerless environment. Accordingly, if a missing or lost message occurs at the receiving node, the message can be extracted from the evidence log and retransmitted based on a notification of the missing sequence number or a sequence range request, thereby improving reliability and fault recovery in a high-volume message environment.

[0014] In addition, by adopting a brokerless architecture that eliminates centralized brokers and performs direct communication between router nodes, bottlenecks and single points of failure concentrated on brokers can be mitigated, and end-to-end latency can be improved by reducing the hop count of the message delivery path. In particular, it is possible to provide a lightweight message processing / dispatch configuration while maintaining high throughput in high-volume message sending environments.

[0015] In addition, by arranging router nodes in a hierarchical structure so that upper-layer routers relay or distribute messages to lower-layer routers, a vertical scalability configuration capable of responding to increased traffic can be provided. In other words, it supports both vertical and horizontal scalability of the message router system and has the effect of flexibly responding to the performance requirements of large-scale distributed systems. Brief explanation of the drawing

[0017] FIG. 1 is a block diagram illustrating the configuration of a programmable message router system according to one embodiment of the present invention. FIG. 2 is a diagram schematically illustrating a vertical hierarchy and horizontal expansion structure in which a programmable message router system according to one embodiment is arranged into multiple nodes to process large volume messages. FIG. 3 is a schematic diagram illustrating the structure in which a message is processed within a message router system according to one embodiment of the present invention. FIG. 4 is a flowchart illustrating a method of operating a programmable message router system according to one embodiment. Specific details for implementing the invention

[0018] Hereinafter, embodiments disclosed in this specification will be described in detail with reference to the attached drawings. Identical or similar components are assigned identical or similar reference numerals, and redundant descriptions thereof will be omitted. The suffixes "module" and "part" used for components in the following description are assigned or used interchangeably solely for the ease of drafting the specification and do not inherently possess distinct meanings or roles. Furthermore, in describing the embodiments disclosed in this specification, if it is determined that a detailed description of related prior art could obscure the essence of the embodiments disclosed in this specification, such detailed description will be omitted. Additionally, the attached drawings are intended only to facilitate understanding of the embodiments disclosed in this specification; the technical concept disclosed in this specification is not limited by the attached drawings, and it should be understood that they include all modifications, equivalents, and substitutions that fall within the concept and technical scope of the embodiments.

[0019] Terms including ordinal numbers, such as first, second, etc., may be used to describe various components, but said components are not limited by said terms. These terms are used solely for the purpose of distinguishing one component from another.

[0020] When it is stated that one component is "connected" or "connected" to another component, it should be understood that while it may be directly connected or connected to that other component, there may also be other components in between. On the other hand, when it is stated that one component is "directly connected" or "directly connected" to another component, it should be understood that there are no other components in between.

[0021] A singular expression includes a plural expression unless the context clearly indicates otherwise.

[0022] In this application, terms such as “comprising” or “having” are intended to specify the existence of the features, numbers, steps, actions, components, parts, or combinations thereof described in the specification, and should be understood as not precluding the existence or addition of one or more other features, numbers, steps, actions, components, parts, or combinations thereof.

[0023] Hereinafter, preferred embodiments according to the present invention will be described in detail with reference to the attached drawings.

[0024] FIG. 1 is a block diagram illustrating the configuration of a programmable message router system according to an embodiment of the present invention. A programmable message router system (10) according to an embodiment supports both static routing of transmitted and received messages and dynamic routing based on content or conditions, and can provide messaging efficiency as a single lightweight architecture in a brokerless manner.

[0025] As illustrated in FIG. 1, a programmable message router system (10) according to one embodiment specifically includes a communication interface (110), a memory (120), an input / output interface (130), and a processor (140).

[0026] The communication interface (110) can provide a function for the programmable message router system (10) to communicate with other devices through a network. For example, the processor (140) of the programmable message router system (10) can transmit requests, commands, data, files, etc., generated according to program code stored in a recording device such as memory (120) to at least one user terminal (20) through a network under the control of the communication interface (110).

[0027] Conversely, signals, commands, data, files, etc. from other devices may be received via a network through the communication interface (110) of the programmable message router system (10). Signals, commands, data, etc. received through the communication interface (110) may be transmitted to a processor (140) or memory (120), and files, etc. may be stored in a storage medium (the permanent storage device described above) that the programmable message router system (10) may further include.

[0028] The network may include any one or more networks such as PAN (personal area network), LAN (local area network), CAN (campus area network), MAN (metropolitan area network), WAN (wide area network), BBN (broadband network), and the Internet. Additionally, the network may include any one or more network topologies such as bus networks, star networks, ring networks, mesh networks, star-bus networks, tree or hierarchical networks, but is not limited thereto.

[0029] The user terminal (20) may be a terminal device for an operator or administrator to configure, control, and monitor the programmable message router system (10). For example, it may perform management and control functions of the message router system (10).

[0030] The user terminal (20) can be implemented, for example, as a desktop computer, laptop, tablet, smartphone, or server-type management console. The user terminal (20) can be connected to the communication interface (110) of the programmable message router system (10) via a wired or wireless network.

[0031] Memory (120) is a computer-readable recording medium and may include RAM (random access memory), ROM (read only memory), and permanent mass storage devices such as disk drives and servers. Here, permanent mass storage devices such as ROM and disk drives may be included in the programmable message router system (10) as separate permanent storage devices distinct from memory (120).

[0032] Additionally, an operating system and at least one program code may be stored in the memory (120). These software components may be loaded into the memory (120) from a computer-readable recording medium separate from the memory (120). This separate computer-readable recording medium may include a floppy drive, disk, tape, DVD / CD-ROM drive, memory card, SSD, USB, etc.

[0033] In another embodiment, software components may be loaded into memory (120) via a communication interface (110) rather than a computer-readable recording medium. For example, software components may be loaded into memory (120) of a programmable message router system (10) based on a computer program installed by files received over a network.

[0034] In one embodiment, the memory (120) may include a log storage (1210) to support the audit and replay / retransmission of message processing. The log storage (1210) can enable tracking and retransmission of message loss even in a brokerless direct communication environment where no central broker exists by storing and managing audit logs generated by an audit logger. The log storage (1210) may hold the processing history of a specific serial number message and information necessary for retransmission together.

[0035] In one embodiment, the log storage (1210) may support a write-ahead storage method that records a log record for the message before the transmission of the message is completed. By ensuring that the serial number and the message body are stored in the log storage before the message delivery unit transmits the message to the destination, data necessary for retransmission can be secured even in the event of a network failure or node failure.

[0036] The input / output interface (130) may be a means for interfacing with an input / output device. For example, the input device of the input / output device may include a device such as an operation button, keyboard, or mouse provided on the front of the device, and the output device may include a device such as a display or speaker. As another example, the input / output interface (130) may be a means for interfacing with a device in which the functions for input and output are integrated into one, such as a touchscreen. The input / output device may be physically configured as a single device with the programmable message router system (10).

[0037] The processor (140) may be configured to process instructions of a computer program by performing basic arithmetic, logic, and input / output operations. Instructions may be provided to the processor (140) via memory (120) or a communication interface (110). For example, the processor (140) may be configured to execute instructions received according to program code stored in a recording device such as memory (120).

[0038] As illustrated in FIG. 1, the processor (140) of a programmable message router system (10) according to one embodiment includes, more specifically, a lightweight virtual machine (1410), a dynamic routing engine (1420), a sequencing module (1430), a script management module (1440), and a message delivery unit (1450).

[0039] A lightweight virtual machine (1410) can provide an execution environment for interpreting or executing routing scripts. The lightweight virtual machine (1410) can be combined with a dynamic routing engine (1420) and a script management module (1440) to switch message processing logic without interrupting operations.

[0040] The lightweight virtual machine (1410) can receive messages transmitted from the dynamic routing engine (1420) as an execution context. The execution context may include, for example, a set of message header fields, a payload byte sequence or structured data, a receiving channel / input interface identifier, a current router node identifier, a list of destination candidates, a sequence number assigned by the sequencing module (1430), etc.

[0041] The lightweight virtual machine (1410) enables the script to perform condition determination and destination calculation based on message content by binding the execution context to the script's global / local variables or making it accessible through API calls.

[0042] A lightweight virtual machine (1410) can support the creation of a script as a combination of rules and actions. For example, a rule is evaluated based on conditions such as specific field values, lengths, prefixes, regular expression matching, value ranges, hash results, or receiving channel identifiers of a message header / payload, and an action is a process executed based on the evaluation result of the rule, which may include destination selection and update, message header modification and addition, payload transformation and filtering, branching to a specific queue / channel, logging triggers, retransmission policy parameter setting, etc.

[0043] Accordingly, the lightweight virtual machine (1410) can perform message processing logic in the flow of condition evaluation → action execution. Accordingly, the dynamic routing engine (1420) can determine the final destination and perform message processing.

[0044] A lightweight virtual machine (1410) can have a sandbox and restrictions on script execution to minimize delay and resource usage in a bulk message environment.

[0045] The lightweight virtual machine (1410) can execute a script directly in an interpreter manner according to an embodiment, or execute the script after converting it into intermediate code (bytecode) according to another embodiment. Additionally, if performance improvement is required, it may optionally support Just-In-Time (JIT) compilation, which converts the script or bytecode into native code at runtime for execution.

[0046] The dynamic routing engine can dynamically determine the destination of a message and perform message processing if necessary. The dynamic routing engine (1420) determines the destination and performs message processing by analyzing the header or payload of the message through a lightweight virtual machine (1410).

[0047] The dynamic routing engine (1420) receives a message received through the communication interface (110). The dynamic routing engine (1420) can parse the header or payload included in the message and convert it into a structured form such as a key-value map, field table, or byte buffer view, and generate metadata necessary for subsequent processing, such as the time of reception, input channel identifier, message length, type / message type, and sending node identifier. Additionally, it can perform checks for message corruption or basic format compliance, such as checksums and length verification, and for error messages, perform exception handling such as dropping, quarantine, or routing to a separate error destination.

[0048] The dynamic routing engine (1420) can create an execution context to be provided to the lightweight virtual machine (1410) for the execution of a routing script. For example, the execution context may include a set of header fields, information on a payload or part of a payload, key field values, input channel identification information, destination candidate information, a serial number assigned by the sequencing module (1430), etc. The dynamic routing engine (1420) can call the lightweight virtual machine (1410) by referencing an active routing script specified by the script management module (1440) and perform message processing logic to execute rules and actions within the script.

[0049] In one aspect, the dynamic routing engine (1420) can reflect the active routing script switched from the script management module (1440) during runtime in real time to the destination determination and message processing logic.

[0050] The dynamic routing engine (1420) can determine the destination based on the result of script execution or an internal policy. The destination can be represented as a single destination node, a destination list consisting of multiple destination nodes, a specific outgoing channel identifier, or at least one of a destination group, a topic, or an endpoint group.

[0051] The dynamic routing engine (1420) may be configured to reference or set a transmission channel identifier field of a message linked to destination information in a rule or action of a routing script, and may be configured to determine at least one of a destination node, a destination address, or a transmission channel based on the value of the transmission channel identifier field. The channel identifier field may be an output channel identifier field for specifying the output channel of a message, and in one embodiment, the output channel identifier field may be implemented as 'ob_chid'.

[0052] The dynamic routing engine (1420) analyzes the header or payload of a message according to rules and actions executed in the lightweight virtual machine (1410), and can determine at least one lower-level router node among a plurality of router nodes arranged in a hierarchical structure as the destination according to the analysis result. For example, a script executed in an upper-level router node selects one of the lower-level router node groups according to the message content or input channel, and the dynamic routing engine (1420) can calculate the selected lower node as the destination.

[0053] Additionally, the dynamic routing engine (1420) may extract a key value from a key field included in the header or payload of a received message and select at least one of a plurality of parallel-arranged sub-router nodes as a destination based on the result of a hash operation on the key value. For example, the destination selection may be performed through a mod operation of the hash result, weight-based distribution, or consistent hashing.

[0054] The dynamic routing engine (1420) can perform message processing such as adding, deleting, or modifying header fields, or converting payloads, splitting, merging, or sampling messages.

[0055] The sequencing module (1430) assigns a serial number to the message and records the transmission and reception status of the message.

[0056] The sequencing module (1430) generates and stores an audit log in a write-ahead format containing a serial number corresponding to the time of inflow and outflow of a message, and when a notification or sequence range request regarding a missing serial number is received from a receiving node, the message delivery unit (1450) may be configured to refer to the audit log to extract a message corresponding to the missing serial number and retransmit it to the receiving node.

[0057] The sequencing module (1430) records the sequence number assigned to the received message and the processing progress and transmission / reception status of the message, and generates and stores an audit log in a write-ahead manner corresponding to the time of message inflow and outflow, thereby enabling tracking and recovery of message loss even in a brokerless direct communication environment. When a message is received through the communication interface (110), the sequencing module (1430) can generate and assign a unique sequence number to the message. The sequence number serves as identification information for tracking the message flow and can be generated, for example, as a monotonically increasing integer, a combination of a time-based value and an increment value, or a combination of a node identifier and a counter. In one embodiment, the sequencing module (1430) may maintain an independent sequence space per router node (e.g., node ID) and / or per input channel, and in another embodiment, serial numbers may be assigned using an atomic increment operation or a lock-free data structure to prevent race conditions between multiple threads / processing pipelines within the router system (10).

[0058] The sequencing module (1430) can record status information at each stage of message processing. For example, the status information may include completion of reception, completion of routing decision, completion of message processing, completion of transmission request, completion of transmission, and whether an acknowledgment of reception (ACK) has been received.

[0059] The sequencing module (1430) manages this status information by mapping it to a serial number, thereby enabling tracking of at which stage a specific serial number message was delayed or failed.

[0060] The sequencing module (1430) can generate and store an audit log containing a serial number corresponding to the time of inflow and outflow of the message, respectively.

[0061] In one embodiment, the sequencing module (1430) writes the message and related metadata ahead of the message transmission, so that information necessary for retransmission can be obtained even if a transmission failure or system failure occurs.

[0062] The evidence log may be stored in a log storage (1210), and the log storage (1210) may be implemented as a non-volatile storage area (e.g., SSD, NVRAM) within memory (120) or as an external log server. In one embodiment, the evidence log may include a serial number, a message body (header and / or payload) or reference information for a message, an incoming time and / or outgoing time, a destination identifier or a destination list.

[0063] In one aspect, the sequencing module (1430) processes a notification or request received through the communication interface (110) and can identify a missing sequence range or a missing set of serial numbers. Additionally, the sequencing module (1430) can provide search conditions to the message delivery unit (1450) so that log items corresponding to missing messages can be extracted.

[0064] In a brokerless direct communication environment, a receiving node may miss messages due to various causes such as network failure, buffer overflow, or node restart. Accordingly, the receiving node may request a notification regarding the sequence number of the missing message or a specific range of sequences. When a notification regarding the missing sequence number or a request for a sequence range is received from the receiving node, the sequencing module (1430) can support the retransmission processing of the message delivery unit (1450) by providing retransmission-related metadata, such as the sequence number of the message to be retransmitted, the destination, the original transmission time, and the number of retransmissions.

[0065] The script management module (1440) stores routing scripts in version units and switches active routing scripts during runtime. The script management module (1440) works in conjunction with the lightweight virtual machine (1410) and the dynamic routing engine (1420) to change the destination determination and message processing logic of messages without interrupting operations, thereby providing operational flexibility.

[0066] In one embodiment, the routing script may include a combination of rules and actions and may define logic for performing destination determination or message processing based on the header and / or payload of the message. In one embodiment, the script management module (1440) may store a version identifier, creation time, coverage, dependency information, and rollback target version information together for each version of the script. The script may be stored in memory (120) or loaded from an external storage and cached in memory (120). The script management module (1440) may designate one of the multiple versions of the routing script as the active routing script and switch the active script to another version during runtime.

[0067] In one embodiment, the transition may be triggered by operator input, a command from a policy server, or an automated rule (e.g., a specific time period, a traffic spike, or a failure detection). The script management module (1440) may set a cutover policy, such as applying the new script to messages received after the transition point, or applying it in stages only to specific message types / channels.

[0068] The dynamic routing engine (1420) can reflect active routing scripts switched from the script management module (1440) in real time to destination determination and message processing logic during runtime. To do this, the script management module (1440) provides a reference to the switched active script to the dynamic routing engine (1420) or the lightweight virtual machine (1410), and can update the reference so that it is reflected immediately.

[0069] In one embodiment, the script management module (1440) can atomically replace active script references so that script switching is consistently applied even in an environment where messages are processed simultaneously by multiple threads.

[0070] The message delivery unit (1450) can deliver the processed message through direct communication between multiple router nodes. By performing brokerless direct communication between multiple router nodes without a central broker in conjunction with the communication interface (110), the message delivery unit (1450) can reduce delivery delay in a large-volume message environment and improve the scalability of the system.

[0071] The message delivery unit (1450) receives a processed message or processing command, a destination or destination list, and transmission policy parameters such as a transmission method, priority, and whether retransmission is allowed from the dynamic routing engine (1420). The destination may be a lower router node arranged in a hierarchical structure, a router node arranged in parallel, or an external consumer node, and if a destination list is provided, the message delivery unit (1450) may deliver the message using a broadcast, multicast, duplicate transmission, or selective transmission method.

[0072] Additionally, the message delivery unit (1450) may include channel / session management functions for creating, maintaining, and releasing communication channels for each destination. For example, the message delivery unit (1450) may reuse connections corresponding to destination addresses or maintain connection pools for each destination group to reduce connection setup overhead when sending bulk messages. Additionally, the message delivery unit (1450) may perform a retry, exponential backoff, or failover to an alternative destination if the destination node is temporarily unavailable.

[0074] FIG. 2 is a schematic diagram illustrating a vertical hierarchy and horizontal expansion structure in which a programmable message router system according to one embodiment is arranged with multiple nodes to process large volume messages.

[0075] Referring to FIG. 2, an upper layer message router system (10A) can receive messages entering through a plurality of input protocols (e.g., UDP and TCP). The upper layer message router system (10A) can be configured to determine the destination of the received message by the dynamic routing engine and lightweight virtual machine described with reference to FIG. 1, and then relay or distribute the message to at least one of the lower layer message router systems (10B, 10C, 10D) arranged in a hierarchical structure.

[0076] In one embodiment, an upper-layer message router system (10A) can select a destination among lower-layer message router systems (10B, 10C, 10D) based on a key field, a channel identifier field (e.g., outgoing channel identifier), a message type, or a routing policy included in the header and / or payload of a message, and can distribute the message processing load by delivering the message to the selected destination.

[0077] Additionally, FIG. 2 illustrates an example in which an additional router node (10E) is added in correspondence with a lower-layer message router system (10D). That is, when traffic increase or throughput expansion is required, a new message router node (10E) can be added even during system operation, and the upper-layer message router system (10A) or the existing lower-layer message router system (10D) can change the destination selection logic in real time to include the new node (10E) according to the switching of the routing script. Accordingly, the present invention can support both vertical expansion according to the hierarchical structure and horizontal expansion according to the addition of parallel nodes.

[0078] Meanwhile, each message router system (10A~10E) can communicate directly with each other through a communication interface and a message delivery unit without passing through a central broker to deliver messages. Accordingly, it is possible to mitigate the single point of failure problem caused by broker failure and suppress unnecessary hop increases, thereby providing the effect of reducing delay.

[0079] FIG. 3 is a schematic diagram illustrating the structure in which a message is processed within a message router system according to one embodiment of the present invention.

[0080] Referring to FIG. 3, a message router system according to one embodiment receives a message from the outside, and for the received message, analyzes the header or payload of the message in the routing / processing step to determine the destination, and if necessary, performs message processing, and then distributes and transmits the message to the determined destination.

[0081] A series of processing steps as illustrated in FIG. 3 can be performed by the dynamic routing engine (1420), lightweight virtual machine (1410), sequencing module (1430), and message delivery unit (1450) of FIG. 1. In one embodiment, the message router system (10) may include a thread pool-based asynchronous processing structure for high-volume message processing efficiency. For example, messages received during the reception stage are registered in an internal queue or as a task unit, and throughput can be improved by multiple threads within the thread pool performing routing / processing and distribution processing in parallel. At this time, the sequencing module (1430) may assign a serial number at the time of message inflow, record the transmission and reception status, and generate and store an audit log in a write-ahead manner before the message is transmitted.

[0082] The log storage (1210) may be implemented as a non-volatile storage area within memory (120), and in other embodiments, it may be implemented as an external log server or a distributed storage. The sequencing module (1430) may be configured to generate a log entry including a sequence number and a message body (header and / or payload) or its reference information, destination information, etc., corresponding to the time of inflow and outflow of a message, and to store it in the log storage (1210).

[0083] Additionally, as illustrated in FIG. 3, if a specific message is missing due to causes such as network failure, buffer overflow, or node restart at the receiving node side, the receiving node may transmit a notification or sequence range request regarding the missing sequence number. At this time, when the message router system receives the notification or request, the message delivery unit (1450) may be configured to refer to the log storage (1210) to extract a message corresponding to the missing sequence number and retransmit the extracted message to the receiving node. Accordingly, tracking and recovery of message loss may be possible even in a brokerless structure without a central queue or central storage.

[0084] In addition, the routing logic applied during the routing / processing stage can be executed according to routing scripts managed in version units by the script management module (1440), and when an active routing script is switched during operation, the dynamic routing engine (1420) can reflect the switched script in real time in the destination determination and message processing logic. Therefore, the message router node can change the routing policy without interruption while simultaneously providing reliable message delivery based on evidence logs and sequencing.

[0085] FIG. 4 is a flowchart illustrating a method of operating a programmable message router system according to one embodiment.

[0086] A method for operating a programmable message router system according to one embodiment first receives a message from the outside through a communication interface (S200). In one embodiment, the message may be received via a transmission protocol such as UDP or TCP, and the message router system according to one embodiment may obtain a data unit including a header and / or payload of the received message. Additionally, the message router system may obtain or generate metadata such as the time of reception, input channel identification information, and message length.

[0087] Subsequently, the sequencing module of the message router system assigns a sequence number to the received message and records the transmission and reception status of the message (S210). In one embodiment, the sequencing module may generate a monotonically increasing sequence value corresponding to the time of message inflow and map it to the message for storage. Additionally, by recording the message processing status in conjunction with the sequence number, the sequencing module can perform message tracking and recovery in a brokerless environment.

[0088] Additionally, the sequencing module may be implemented to generate a write-ahead audit log containing a sequence number corresponding to the time of message inflow and / or outflow, and store it in a log repository.

[0089] Subsequently, the script management module manages routing scripts in version units and switches active routing scripts during runtime if necessary (S220). In one embodiment, the switch may be triggered by conditions such as an operator request, a control command from a policy server, a change in traffic, or the detection of a failure. The script management module may atomically update the reference information of the active script so that the switched active script can be immediately referenced by a lightweight virtual machine or a dynamic routing engine.

[0090] Switching active routing scripts is not limited to being performed for every message. It may be configured to be performed only at regular intervals or upon the occurrence of an event, with the results applied to subsequent message processing.

[0091] Then, the dynamic routing engine determines the destination by analyzing the header and / or payload of the message through a lightweight virtual machine and performs message processing if necessary (S230). In one embodiment, the dynamic routing engine can perform destination selection logic by creating an execution context and providing it to the lightweight virtual machine, and by executing rules and actions included in an active routing script. In one embodiment, the destination may be determined as at least one lower-level router node among a plurality of router nodes arranged in a hierarchical structure, a selected node among a plurality of lower nodes arranged in parallel, or at least one of a destination endpoint group. Additionally, message processing may include adding / deleting / modifying header fields, converting / filtering the payload, assigning routing tags, etc.

[0092] Subsequently, the message delivery unit transmits the processed message, whose destination is determined by the dynamic routing engine, to the destination (S240). In one embodiment, the message delivery unit can transmit messages through direct communication between multiple router nodes without a central broker, and can improve delivery efficiency by creating, maintaining, and reusing communication channels for each destination.

[0093] When a notification regarding a missing serial number or a sequence range request is received from a receiving node, the message delivery unit may be configured to extract the missing message by referring to the evidence log stored in the log repository and retransmit it to the corresponding receiving node.

[0094] According to one embodiment, a message router system can provide reliable message delivery in a brokerless environment by changing message processing logic uninterruptedly through runtime script switching, and by using sequencing and evidence log-based tracking and recovery functions.

[0096] The above-described method may be implemented as an application or in the form of program instructions that can be executed through various computer components and recorded on a computer-readable recording medium. The computer-readable recording medium may include program instructions, data files, data structures, etc., either individually or in combination.

[0097] The program instructions recorded on the above-mentioned computer-readable recording medium are those specifically designed and configured for the present invention, but may also be those known and available to those skilled in the art of computer software.

[0098] Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tapes; optical recording media such as CD-ROMs and DVDs; magneto-optical media such as floptical disks; and hardware devices specifically configured to store and execute program instructions such as ROM, RAM, and flash memory.

[0099] Examples of program instructions include machine code, such as that generated by a compiler, as well as high-level language code that can be executed by a computer using an interpreter, etc. The hardware device may be configured to operate as one or more software modules to perform processing according to the present invention, and vice versa.

[0100] Although the embodiments have been described in detail above, the scope of the rights to the embodiments is not limited thereto, and various modifications and improvements by those skilled in the art using the basic concepts of the embodiments defined in the following claims also fall within the scope of the rights to the embodiments.

[0101] Accordingly, the detailed description above should not be interpreted restrictively in all respects but should be considered as an example. The scope of the embodiments should be determined by a reasonable interpretation of the appended claims, and all modifications within the equivalent scope of the embodiments are included within the scope of the embodiments. Explanation of the symbols

[0103] 10: Programmable Message Router System 20 : User terminal 110 : Communication interface 120 : Memory 1210 : Log storage 130: I / O interface 140: Processor 1410: Lightweight Virtual Machine 1420: Dynamic Routing Engine 1430: Sequencing Module 1440: Script Management Module 1450 : Message delivery unit

Claims

Claim 1 A programmable message router system for transmitting messages in a large-scale distributed system, comprising a computer device having one or more processors and a memory for storing one or more programs executed by said one or more processors, wherein the system comprises: a lightweight virtual machine for executing a routing script; a dynamic routing engine that determines a destination and performs message processing by analyzing a header or payload of a message through said lightweight virtual machine; a sequencing module that assigns a serial number to said message and records the transmission and reception status of said message; and a script management module that stores said routing scripts in version units and switches active routing scripts during runtime. A programmable message router system comprising a message delivery unit that transmits the processed message through direct communication between multiple router nodes, wherein the dynamic routing engine reflects the active routing script converted from the script management module during runtime in real time to the destination determination and message processing logic, the sequencing module generates and stores an audit log in a write-ahead format containing a serial number corresponding to the inflow and outflow times of the message, and when a notification regarding a missing serial number or a sequence range request is received from a receiving node, the message delivery unit is configured to refer to the audit log to extract a message corresponding to the missing serial number and retransmit it to the receiving node. Claim 2 A programmable message router system according to claim 1, wherein the dynamic routing engine analyzes the header or payload of a message according to rules and actions executed in the lightweight virtual machine, and determines at least one lower-level router node among a plurality of router nodes arranged in a hierarchical structure as the destination according to the analysis result. Claim 3 delete

Images