DISTRIBUTED DAY RECONCILIATION
By distributing matching tasks across multiple engines and using a master matching table, the inefficiencies of single-engine tag matching with placeholders are overcome, enhancing computational efficiency and reducing network costs.
Patent Information
- Application Number
- DE102025132182
- Authority / Receiving Office
- DE · DE
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2024-08-27
- Filing Date
- 2025-08-13
- Publication Date
- 2026-03-05
AI Technical Summary
Existing distributed tag matching systems face inefficiencies when placeholders for data sources are used, as they can only be matched by a single matching engine, limiting the efficiency of the distributed approach.
Implement a control circuit that distributes matching tasks across multiple engines, allowing parallel processing of receive orders with placeholders, using a master matching table to track and manage matching tags, and employing asynchronous agents for context-aware tag matching.
Enhances computational efficiency by enabling parallel processing of matching tasks across distributed engines, reducing network costs, and maintaining coherence in tag matching operations.
Smart Images

Figure 00000000_0000_ABST
Abstract
Description
AREA OF REVELATION
[0001] The present disclosure relates generally to computer communication and in particular to the distributed matching of messages to intended recipients, where the message may contain a placeholder designation instead of a source identifier. BACKGROUND
[0002] The Message Passing Interface (MPI) tag matching specification, as well as other application programming interfaces (APIs) with similar semantics, defines a protocol by which a sender can initiate data transmission. The receiver can independently make a receive request. Tag matching rules determine how to couple the two operations to deliver the data to the correct receive address in memory. The tag matching rules require: ordering send operations according to the order in which the sender sends messages; ordering receive operations according to the order in which the receiver makes receive requests; a tag assigned to the sender; a tag assigned to the receiver; and matching the send and receive tags to determine where the data should be delivered, e.g.,Send and receive tags must match; and for an ordered match, e.g., if there is more than one possible match between the sender and receiver, the required match is the one where the earliest sent message is matched with the earliest received message. Of the four parameters involved in MPI tag matching—source, destination, user tag, and communicator—two can be used as placeholders: source and user tag. The use of placeholders for user tags is not relevant here.
[0003] The received request can contain a placeholder for the data source. In this case, the tag matching element containing the placeholder matches this field in one of the sent tags. However, a specific tag pair, i.e., in the message and in the received request, can only be matched once. The order requirements make it difficult to distribute the MPI tag matching between a specific endpoint pair across different matching engines. The root cause of the problem is that a placeholder for a data source can be matched with data from any source and can only be matched once. Therefore, if such tags are distributed across different matching engines, only one matching engine can perform a match.In a previous version of distributed tag matching, the entire tag matching process is shifted to a single matching engine, while tags with placeholders for data sources are available for matching. Once these placeholders have been matched, the distributed tag matching process resumes. This reduces the efficiency of the distributed approach to tag matching. Therefore, there is a need in the field for improved methods and systems for distributed tag matching when tags with placeholders for data sources are present. SUMMARY
[0004] The invention is defined by the claims. To illustrate the invention, aspects and embodiments that may or may not fall within the scope of the claims are described here.
[0005] Embodiments of the present disclosure relate to the distributed tag matching of messages to a designated receiver when the message is processed by a receiver node as a placeholder receive request. More generally, the embodiments described herein deal with distributed tag matching in the presence of matching tags with placeholder receive requests, taking into account parameters that are not associated with the matching tag and that are not known a priori to either the sender or the receiver.
[0006] According to one embodiment, a computing device may include a control circuit that controls the operation of the computing device. The control circuit may cause the computing device to execute an application process that initiates a post-receive job to request the receipt of a message and determines whether the post-receive job should be processed as a wildcard post-receive job. If it is determined not to process the post-receive job as a wildcard post-receive job, the post-receive job can be provided to a target matching engine from a plurality of matching engines, and the target matching engine can perform a matching of the post-receive job with a received message.If it is determined that the receive order is to be processed as a placeholder receive order, the receive order can be distributed to any of the one or more target matching engines from the plurality of matching engines, wherein, if the one or more target matching engines comprise two or more distributed matching engines, each of the two or more matching engines performs a parallel matching of the receive order with a received message.
[0007] Matching a receive order with a received message can involve comparing the receive order with a list of unmatched messages and determining whether the receive order matches a received message in the unmatched list. If it is determined that the receive order does not match a received message in the unmatched list, the receive order can be added to the unmatched list.
[0008] The matching of a receive order with a received message can further include determining, if it is determined that the receive order matches a received message in the list of unmatched messages, whether the receive order is a wildcard receive order. If it is determined that the receive order is not a wildcard receive order, the matching between the receive order and the message in the list of unmatched messages can be processed. If it is determined that the receive order is a wildcard receive order, a matching token can be requested from a token manager.
[0009] Matching the receive request with a received message can further include determining whether the requested matching token has been issued. If it is determined that the requested matching token has been issued, the matching between the receive request and the message in the list of unmatched messages can be processed. If it is determined that the requested matching token has not been issued, the matching message can be removed from the list of unmatched messages, and the token manager can be notified of a failed request.
[0010] The processing of the match between the receive job and the message in the unmatched messages list can include determining whether the current domain is a domain for the matching engine performing the match to process data from the matched message. If it is determined that the current domain is a domain for the matching engine to process data from the matched message, a receive log for the message data can be initiated, and the matched message can be removed from the unmatched messages list.If it is determined that the current domain for the matching engine performing the matching is not the domain for processing data of the matched message, the receive job can be marked as complete in a matching table and the matched message can be removed from the list of unmatched messages.
[0011] According to another embodiment, a distributed computing network can comprise a communication network and a first processing node coupled to the communication network. The first processing node can include a control circuit that controls the operation of the first processing node, wherein the control circuit causes the first processing node to execute an application process that sends messages over the communication network.
[0012] The distributed computing network can further include a second processing node coupled to the communication network. This second processing node can include a control circuit that manages its operation, causing the second processing node to execute an application process. The application process running on the second processing node can include a distributed matching engine from a variety of distributed matching engines, which receives the message from the first processing node and uses the message header to determine whether the message matches a previous receive job. If the message is determined not to match a previous receive job, the application process running on the second processing node can add the message to a list of unexpected messages.
[0013] If it is determined that the message matches a previous receive job, the application process running on the second processing node can decide whether to process the receive job as a wildcard receive job. If it is determined not to process the receive job as a wildcard receive job, the application process running on the second processing node can process the message.
[0014] If it is determined that the receive request should be processed as a wildcard receive request, the application process running on the second processing node can request a matching token from a token manager and determine whether the matching token has been granted. If it is determined that the matching token has been granted, the application process running on the second processing node can process the message. If it is determined that the matching token has not been granted, the application process running on the second processing node can remove a matching receive message from a list of unmatched receive requests and further determine, based on the message header, whether the message matches a previous receive request.
[0015] According to yet another embodiment, a method for data communication in a distributed computing network can include initiating a receive request to request the receipt of a message and determining whether the receive request should be processed as a wildcard receive request. If it is determined not to process the receive request as a wildcard receive request, the receive request can be provided to a target matching engine from a plurality of matching engines to perform a matching of the receive request with a received message.If it is determined that the receive order is to be processed as a placeholder receive order, the receive order can be distributed to each of the one or more target matching engines from the plurality of matching engines to perform the matching of the receive order with a received message, wherein, if the one or more target matching engines comprise two or more distributed matching engines, each of the two or more matching engines performs a parallel matching of the receive order with a received message.
[0016] Matching a receive order with a received message can involve comparing the receive order with a list of unmatched messages and determining whether the receive order matches a received message in the unmatched list. If it is determined that the receive order does not match a received message in the unmatched list, the receive order can be added to the unmatched list.
[0017] If it is determined that the receive request matches a received message in the list of unmatched messages, it can be determined whether the receive request is a wildcard receive request. If it is determined that the receive request is not a wildcard receive request, the matching between the receive request and the message in the list of unmatched messages can be processed.
[0018] If it is determined that the receive request is a placeholder receive request, a matching token is requested from a token manager. It can also be determined whether the requested matching token has been issued. If it is determined that the requested matching token has been issued, the matching between the receive request and the message in the list of unmatched messages can be processed. If it is determined that the requested matching token has not been issued, the matching message can be removed from the list of unmatched messages, and the token manager can be notified of a failed request.
[0019] The processing of the match between the receive job and the message in the unmatched messages list can include determining whether the current domain is a domain for the matching engine performing the match to process data from the matched message. If it is determined that the current domain is a domain for the matching engine to process data from the matched message, a receive log for the message data can be initiated, and the matched message can be removed from the unmatched messages list.If it is determined that the current domain for the matching engine performing the matching is not the domain for processing data of the matched message, the receive job can be marked as complete in a matching table and the matched message can be removed from the list of unmatched messages.
[0020] Any feature of one aspect or embodiment can be applied to other aspects or embodiments in any suitable combination. In particular, any feature of one process aspect or embodiment can be applied to one device aspect or embodiment, and vice versa. Brief description of the different views of the drawings
[0021] The present revelation is described in conjunction with the accompanying figures, which are not necessarily drawn to scale. Fig. Figure 1 is a block diagram illustrating an exemplary environment in which a tag matching can be performed according to an embodiment of the present disclosure. Fig. Figure 2 is a flowchart illustrating an exemplary process for sending data communication in a distributed computing network according to an embodiment of the present disclosure. Fig. Figure 3 is a flowchart illustrating an exemplary process for introducing a receive order into a distributed computing network according to an embodiment of the present disclosure. Fig. Figure 4 is a flowchart illustrating further details of an exemplary distributed matching process according to an embodiment of the present disclosure. Fig. Figure 5 is a flowchart illustrating further details of an exemplary process for processing a reconciliation of a received order according to an embodiment of the present disclosure. Fig. Figure 6 is a flowchart illustrating an exemplary process for receiving a message over a distributed computing network according to another embodiment of the present disclosure. DETAILED DESCRIPTION
[0022] The following description merely provides embodiments and is not intended to limit the scope, applicability, or design of the claims. Rather, the following description is intended to provide guidance to those skilled in the art, enabling the implementation of the described embodiments. It is understood that various modifications to the function and arrangement of the elements can be made without deviating from the spirit and scope of the attached claims.
[0023] From the following description and for reasons of computational efficiency, it becomes clear that the components of the system can be placed at any suitable location within a distributed network of components without affecting the operation of the system.
[0024] Furthermore, the various connections linking the elements together can be wired, conductive, or wireless connections, or any combination thereof, or any other suitable known or subsequently developed element capable of supplying and / or transmitting data to and from the connected elements. Transmission media used as connections can include, for example, any suitable carrier for electrical signals, including coaxial cable, copper wire, and fiber optic cable, electrical conductors on a printed circuit board (PCB), or similar.
[0025] The expressions used here, "at least one," "one or more," "or," and "and / or," are indefinite expressions that can be used both subjunctive and disjunctive. For example, each of the expressions "at least one of A, B, and C," "at least one of A, B, or C," "one or more of A, B, and C," "one or more of A, B, or C," "A, B, and / or C," and "A, B, or C" means A alone, B alone, C alone, A and B together, A and C together, B and C together, or A, B, and C together.
[0026] The term "automatic" as used here, and variations thereof, refers to any suitable process or operation that is carried out without substantial human input when the process or operation is executed. However, a process or operation may be automatic even if its execution uses substantial or insignificant human input, provided that the input is received before the process or operation is carried out. Human input is considered substantial if it affects the execution of the process or operation. Human input that merely consents to the execution of the process or operation is not considered substantial.
[0027] The terms “determine”, “calculate”, “calculate” and variations thereof used here are interchangeable and include any suitable type of methodology, process, operation or technique.
[0028] Various aspects of the present disclosure are described here with reference to drawings that are schematic representations of idealized configurations.
[0029] Unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as generally understood by a person sufficiently knowledgeable in the field to which this disclosure belongs. It is further understood that terms as defined in commonly used dictionaries should be interpreted to have a meaning consistent with their meaning in the context of the relevant prior art and this disclosure.
[0030] The singular forms "ein", "eine", "der", "die", and "das" used here are intended to include the plural forms unless the context clearly indicates otherwise. Furthermore, it is understood that the terms "umfassen", "umfasst", and / or "umfassend", when used in this description, indicate the presence of certain features, integers, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. The term "and / or" includes all combinations of one or more of the points listed.
[0031] With reference to Fig. Sections 1-5 now describe various systems and methods for processing communication in a distributed computing network. The embodiments described here relate to the distributed matching of messages to a designated recipient when the message is processed by a recipient as a placeholder receive request. Furthermore, the embodiments described here take into account parameters that are not assigned to the matching tag.
[0032] Fig. Figure 1 is a block diagram illustrating an exemplary environment in which tag matching can be performed according to an embodiment of the present disclosure. As illustrated in this example, the environment 100 can comprise a number of nodes 105A-105D coupled to a communication network 110. As used here, a node refers to the system unit that is replicated to create a distributed computing system. This can include, for example, CPUs, graphics processing units (GPUs), and multiple network cards. Such units would be connected via a network to form a distributed computing system.
[0033] As illustrated by node 105D, each node can include a control circuit 115 that controls the operation of node 105D. The control circuit 115 can include a central processing unit (CPU), such as one or more microprocessors or similar components known from engineering. The node's control circuit 115 can execute any number of processes 120, which communicate via the communication network 110 with processes running on other nodes 105A-105C or within the memory of a single node 105D, using a message-passing interface (MPI) specification or a similar application programming interface (API) known from engineering. When a parallel job is executed, each of these systems has one or more processes 120 running on each node 105A-105D.When an MPI library is used to manage the data exchange between these processes 120 (on the host or off the host), these processes 120 are referred to as MPI processes, and each of these processes has one or more matching engines 125. Embodiments of the present disclosure relate to distributing the matching within the individual MPI process while simultaneously performing the tag matching according to the MPI specification.
[0034] Data transfers can occur either between processes on different nodes or on the same node. Synchronization for a single MPI process is distributed across several system components. Within a single process, these components can be distributed across multiple threads, network cards, GPUs, and / or other components. In some implementations, two such components may include a host operating system process and a BlueField network card operating system process.
[0035] As described above, embodiments of the present disclosure relate to the matching of messages sent between two endpoints, e.g., a sender process and a receiver process, which are executed within a node 105D or across one or more nodes 105A-105D, taking into account parameters that are not part of the matching criteria. In some cases, the length of the received request may be greater than the length of the data actually sent. In such a case, the receiver cannot accurately predict to which of the matching engines 125 the message will actually be sent by the sender. The sender causes the matching header to be transmitted to all relevant matching engines. The sender knows which matching engine is initiating the data transmission, but the receiver does not know this until it receives the matching header from the sender and determines the actual message length.It should be noted that length is only one parameter that can be used to determine the engine that transmits the data, but other parameters are also possible.
[0036] Ordered tag matching is most efficient when performed in a single matching engine, as all relevant data is readily accessible. A common matching engine is one associated with the process's application memory context, since the operations initiating tag matching (typically injecting the receive operation) occur within that context. However, because this is often the same context in which the non-communications portion of the application runs, such matching is usually synchronous and only occurs when the application is running within the context of a communications library. The network library processing and non-network processing compete for the same computational resources.In cases where an asynchronous agent is present, it is desirable to use it to continue communication and, in this case, to perform tag matching independently, overlapping with other aspects of the application, such as computation. Such an asynchronous agent can comprise a DPU, a CPU, or another processing node. If it is desirable to distribute tag matching across different contexts, using both sender and receiver tags as parameters to determine in which context the tag matching is performed, the challenge lies in maintaining coherence between the contexts during tag matching to ensure that each tag is used only once in a successful match.
[0037] Message size is often used to determine the best method for transmitting point-to-point data across a network, with eager protocols commonly used for sending short data and rendezvous protocols for sending longer data. In an eager protocol, the sender sends the entire message, along with the matching header, to the receiver, who provides sufficient buffer space for incoming messages. A rendezvous protocol uses a handshake model, unlike an eager protocol, which directly copies the data. In a rendezvous protocol, the data is sent when the destination is ready, whereas an eager protocol assumes that the destination can store the data in a temporary location if matching is not possible upon arrival of the header.For performance reasons, it is desirable to perform tag matching for short messages in the memory context of a main process to minimize time or latency overhead, and to perform tag matching for longer messages using an asynchronous agent so that the rendezvous protocol can continue independently of application computations.
[0038] The actual length of the transmitted data is known only on the sender side at the start of the data transmission, although the receiver is able to indicate a maximum buffer length. Therefore, when the matching tag is introduced on the receiver side, the receiver does not know whether the protocol used to transmit the data is an eager or a rendezvous protocol. If the introduced receive request is intended for short data, it knows, according to the MPI specification, that an eager matching will be performed. If it is intended for a large message, the receiver does not know whether an eager or a rendezvous protocol will be used.
[0039] According to one embodiment, a sender process can transmit a matching header to a receiver process, which can be used by a matching engine 125 for the receiver process. The receiver process can also introduce the receive tags to any matching engine 125. Once the receiver process has completed the tag matching, it knows the context in which the data will be transmitted, since each matching engine 125 uses the same logic to determine this. Because the sender process knows in advance the context in which the data associated with the matching will be processed, the protocol-specific data, such as the payload in an eager matching, can be passed to the receiving context that will process the received data. If the data layout is used to determine which matching engine will process the data on the receiver side, which is a possible criterion, the sender does not know which engine will process the incoming data.Only the recipient knows that.
[0040] According to one embodiment, when transmitting data to the receiving process, the matching headers for a specific context that are not used for data transmission need only be sent to that context when a matching tag is issued that is processed by that context. This allows for a reduction in network costs for those matching tags that are used solely to ensure correctly ordered matching.
[0041] According to one embodiment, a master matching table 140 can be used in which all placeholder receive matching tags can be represented and tracked as entries. Each entry in the table 140 can contain a field indicating whether the tag has been matched or not. The "address" for accessing this field can be distributed along with the receive matching tags when they are distributed to the individual matching engines 125. If a particular context can match a particular matching tag, it can request the rights to match this placeholder received tag and, if these rights are granted, initiate the process of transferring the data from the sending process to the receiving process. If this is not the case, this context recognizes this received tag as having been previously matched and does not reuse the received tag.The "Address" field could, for example, be the network address of the field, which can be accessed via an atomic update.
[0042] Once a matching engine 125 matches one of the placeholder-stamped receive matching tags, it can notify the other matching engines 125 of the match. According to one embodiment, the entity that owns the master matching table 140 or is otherwise responsible for its management can remove this entry once all matching engines 125 have notified it of its removal from their matching lists, to ensure that the entry is not reused prematurely.
[0043] In implementations optimized for multiple matching contexts, local host-based tag matching can be performed at host-internal processing speeds, which are typically higher than inter-host speeds. These also do not consume network resources. Inter-host tag matching can be performed using separate cross-host resources. Furthermore, if multiple resources are available between hosts, the matching process can be further distributed.
[0044] Fig. Figure 2 is a flowchart illustrating an exemplary process for sending data communication in a distributed computing network according to an embodiment of the present disclosure. As illustrated in this example, sending data communication in a distributed computing network can begin with a sending process selecting target engines or target matching engines to which the message is to be sent. It can be determined whether the message is to be sent to every matching engine. If it is determined that the message is not to be sent to a particular matching engine, matching metadata can be sent, and if it is determined to send the message to that particular matching engine, the sending protocol can be initiated to send the message.In both cases, it can also be determined whether any further selected matching engines intended as targets exist. If so, the process can repeat the determination (220) of whether the message should be sent to the remaining target matching engines and either the sending (225) of the matching metadata or the initiation (230) of the sending protocol until no more selected matching engines exist.
[0045] Fig. Figure 3 is a flowchart illustrating an exemplary process for introducing a receive job into a distributed computing network according to an embodiment of the present disclosure. As illustrated in this example, the process can begin by initiating a receive job to request the receipt of a message and determining whether the receive job should be processed as a wildcard receive job. Alternatively, for a message received from another processing node, it can be determined from the message header whether the message matches a previous receive job, and if it is determined that the message matches a previous receive job, it can be determined whether the receive job should be processed as a wildcard receive job.
[0046] If it is determined 310 not to process the receive job as a wildcard receive job, the receive job can be provided to a designated matching engine from a plurality of matching engines 315, and the designated matching engine can perform a matching of the receive job with a received message. If it is determined 310 that the receive job is to be processed as a wildcard receive job, the receive job can be distributed to one or more designated matching engines from the plurality of matching engines 320, wherein, if the one or more designated matching engines comprise two or more distributed matching engines, each of the two or more matching engines performs a parallel matching of the receive job with a received message.The distribution 320 to each of the two or more target matching engines from the multitude of matching engines can continue until it is determined 325 that the receiving job has been distributed to all designated matching engines.
[0047] Fig. Figure 4 is a flowchart illustrating further details of an exemplary distributed matching process according to an embodiment of the present disclosure. As illustrated in this example, matching the receive order with a received message may include comparing the receive order with a list of unmatched messages and determining whether the receive order matches a received message in the list of unmatched messages. If it is determined that the receive order does not match a received message in the list of unmatched messages, the receive order may be added to the list of unmatched messages.
[0048] The matching of the receive order with a received message may further include determining, if it is determined (410) that the receive order matches a received message in the list of unmatched messages, whether the receive order is a wildcard receive order. If it is determined (420) that the receive order is not a wildcard receive order, the matching between the receive order and the message in the list of unmatched messages can be processed (435). If it is determined (420) that the receive order is a wildcard receive order, a matching token can be requested from a token manager (425).
[0049] Matching the receive order with a received message can further include determining whether the requested matching token has been issued. If it is determined that the requested matching token has been issued, the matching between the receive order and the message in the list of unmatched messages can be processed. If it is determined that the requested matching token has not been issued, the matching message can be removed from the list of unmatched messages, and the token manager can be notified of a failed request.
[0050] Fig. Figure 5 is a flowchart illustrating further details of an exemplary process for handling a match of an incoming receive job according to an embodiment of the present disclosure. As illustrated in this example, the handling of the match between the receive job and the message in the list of unmatched messages may include determining whether the current domain for the matching engine performing the match is a domain for processing data of the matched message. If it is determined that the current domain for the matching engine performing the match is the domain for processing data of the matched message, a receive log for the message data may be initiated, and the matched message may be removed from the list of unmatched messages.If it is determined (505) that the current domain for the matching engine performing the matching is not the domain for processing data of the matched message, the receive job can be marked as complete in a matching table (520) and the matched message can be removed from the list of unmatched messages (525).
[0051] Fig.Figure 6 is a flowchart illustrating an exemplary process for receiving a message over a distributed computing network according to another embodiment of the present disclosure. As illustrated in this example, the process may include receiving the message from a processing node of the distributed computing network and determining, based on a header of the message, whether the message matches a previous receive request. If it is determined that the message does not match a previous receive request, the message may be added to a list of unexpected messages.
[0052] If it is determined in 610 that the message matches a previous receive order, it can further be determined in 620 whether the receive order should be processed as a wildcard receive order. If it is determined in 620 that the receive order should not be processed as a wildcard receive order, the message can be processed in 625.
[0053] If it is determined (620) that the receive order should be processed as a placeholder receive order, a matching token can be requested from a token manager (630), and it can be determined (635) whether the matching token has been granted. If it is determined (635) that the matching token has been granted, the message can be processed (625). If it is determined (635) that the matching token has not been granted, a matching receive message can be removed from a list of unmatched receive messages (640), and it can be further determined (610) from the message header whether the message matches a previous receive order.
[0054] The present disclosure comprises components, methods, processes, systems, and / or devices in various aspects, embodiments, and / or configurations, as substantially presented and described herein, including various aspects, embodiments, configurations, subcombinations, and / or subgroups thereof. Persons skilled in the art will understand, upon understanding the present disclosure, how to manufacture and use the disclosed aspects, embodiments, and / or configurations.The present disclosure encompasses, in various aspects, embodiments and / or configurations, the provision of devices and processes in the absence of elements not shown and / or described herein or in various aspects, embodiments and / or configurations thereof, including in the absence of such elements that may have been used in previous devices or processes, e.g., to improve performance, achieve simplicity and / or reduce the cost of implementation.
[0055] The foregoing serves for illustration and description. It is not intended to limit the disclosure to the form(s) disclosed herein. For example, the detailed description above summarizes various features of the disclosure in one or more aspects, embodiments, and / or configurations to simplify the disclosure. The features of the aspects, embodiments, and / or configurations of the disclosure may be combined in aspects, embodiments, and / or configurations other than those described above. This type of disclosure is not to be interpreted as requiring the claims to include more features than are expressly stated in the respective claims. Rather, as can be seen in the following claims, inventive aspects are found in fewer than all features of any single aspect, embodiment, and / or configuration disclosed above.Therefore, the following claims are hereby included in this detailed description, each claim being a separate preferred embodiment of the disclosure.
[0056] Even if the description includes a description of one or more aspects, embodiments, and / or configurations, as well as certain variants and modifications, other variants, combinations, and modifications fall within the scope of the disclosure, e.g., those that, according to the understanding of the present disclosure, are within the scope of the expert knowledge and understanding of those skilled in the field. The intention is to obtain rights encompassing alternative aspects, embodiments, and / or configurations, to the extent permitted, including alternative, interchangeable, and / or equivalent structures, functions, areas, or steps to those claimed, regardless of whether such alternative, interchangeable, and / or equivalent structures, functions, areas, or steps are disclosed herein or not, and without the intention of publicly disclosing any patentable material.
[0057] It is understood that the aspects and embodiments described above are purely exemplary and that modifications of details may be made within the scope of protection of the claims.
[0058] Each device, each method and each feature disclosed in the description, and (where applicable) the claims and drawings, may be provided independently or in any suitable combination.
[0059] Reference numerals appearing in the claims are for illustrative purposes only and do not restrict the scope of protection of the claims.
Claims
[1] Computing device comprising the following: a control circuit that controls the operation of the computing device, wherein the control circuit causes the computing device to execute an application process, and wherein the application process: initiated a receive request to request the receipt of a message; determines whether the receive request should be processed as a placeholder receive request; if it is determined not to process the receive order as a placeholder receive order, the receive order is provided to a target matching engine from a plurality of matching engines, wherein the target matching engine performs a matching of the receive order with a received message; and If it is determined that the receive order is to be processed as a placeholder receive order, the receive order is distributed to one or more target matching engines from the plurality of matching engines, wherein, if the one or more target matching engines comprise two or more distributed matching engines, each of the two or more matching engines performs a parallel matching of the receive order with a received message. [2] Computing device according to claim 1, comprising comparing the receive order with a received message: Comparing the receive order with a list of unmatched messages; Determine whether the receive order matches a received message in the list of unmatched messages; and If it is determined that the receive request does not match a received message in the list of unmatched messages, add the receive request to the list of unmatched messages. [3] Computing device according to claim 2, wherein the matching of the receive order with a received message further comprises that, if it is determined that the receive order matches a received message in the list of unmatched messages: is determined whether the receive order is a placeholder receive order; If it is determined that the receive order is not a placeholder receive order, process the matching between the receive order and the message in the list of unmatched messages; and If it is determined that the receive order is a placeholder receive order, request a matching token from a token manager. [4] Computing device according to claim 3, wherein the matching of the receiving order with a received message further comprises: Determine whether the requested matching token has been issued; and If it is determined that the requested matching token has been issued, the matching process between the receive order and the message in the list of unmatched messages is carried out. [5] Computing device according to claim 4, wherein the matching of the receive order with a received message, when it is determined that the requested matching token has not been issued, further comprises: Removing the matching message from the list of unmatched messages; and Notify the token manager of a failed request. [6] Computing device according to claim 4 or 5, wherein processing the comparison between the receive order and the message in the list of unmatched messages comprises: Determine whether a current domain is a domain for the matching engine performing the matching to process data from the matched message; and If it is determined that the current domain for the matching engine performing the matching is the domain for processing data of the matched message, initiate a receive log for the message data and remove the matched message from the list of unmatched messages. [7] Computing device according to claim 6, which, when it is determined that the current domain for the matching engine performing the matching is not the domain for processing data of the matched message, further comprises: Marking the receiving order as completed in a reconciliation table; and Remove the matching message from the list of unmatched messages. [8] Distributed computing network comprising the following: a communication network; a first processing node coupled to the communication network, comprising a control circuit that controls the operation of the first processing node, wherein the control circuit causes the first processing node to execute an application process, and wherein the application process sends messages over the communication network; and a second processing node coupled to the communication network, comprising a control circuit that controls the operation of the second processing node, wherein the control circuit causes the second processing node to execute an application process, and wherein the application process: receives the message from the first processing node; It determines, based on the message header, whether the message matches a previous receive order; and If it is determined that the message matches a previous receive order, it determines whether the receive order should be processed as a placeholder receive order. [9] Distributed computing network device according to claim 8, wherein, when it is determined that the message does not match a previous receive order, the application process running on the second processing node adds the message to a list of unexpected messages. [10] Distributed computing network according to claim 8, wherein, if it is determined not to process the receive order as a placeholder receive order, the application process executed on the second processing node processes the message. [11] Distributed computing network according to claim 8, wherein, when it is determined to process the receive order as a placeholder receive order, the application process executed on the second processing node requests a matching token from a token manager and determines whether the matching token has been issued. [12] Distributed computing network according to claim 11, wherein, when it is determined that the matching token has been issued, the application process executed on the second processing node processes the message. [13] Distributed computing network according to claim 11, wherein, when it is determined that the matching token has not been issued, the application process running on the second processing node removes a matching receive message from a list of unmatched receive requests and further determines, based on a header of the message, whether the message matches a previous receive request. [14] Distributed computing network according to one of claims 8-13, wherein the application process executed on the second processing node comprises a distributed matching engine from a plurality of distributed matching engines. [15] Method for data communication in a distributed computing network, wherein the method comprises: Initiating a receive command to request the receipt of a message by an application process executed by a control circuit of a computing device; Determine whether the receive order should be processed as a placeholder receive order by the application process executed by the control circuit of a computing device; if it is determined not to process the receive order as a placeholder receive order, the application process executed by the control circuit of a computing device provides the receive order to a target matching engine from a plurality of matching engines, wherein the target matching engine performs a matching of the receive order with a received message; and If it is determined that the receive order is to be processed as a placeholder receive order, the application process executed by the control circuit of a computing device distributes the receive order to each of the one or more target matching engines from the plurality of matching engines, wherein, if the one or more target matching engines comprise two or more distributed matching engines, each of the two or more matching engines performs a parallel matching of the receive order with a received message. [16] Method according to claim 15, wherein matching the receiving order with a received message comprises: Comparing the receive order with a list of unmatched messages; Determine whether the receive order matches a received message in the list of unmatched messages; and If it is determined that the receive request does not match a received message in the list of unmatched messages, add the receive request to the list of unmatched messages. [17] Method according to claim 16, wherein matching the receive order with a received message further comprises that, if it is determined that the receive order matches a received message in the list of unmatched messages: is determined whether the receive order is a placeholder receive order; If it is determined that the receive order is not a placeholder receive order, process the matching between the receive order and the message in the list of unmatched messages; and If it is determined that the receive order is a placeholder receive order, request a matching token from a token manager. [18] Method according to claim 17, wherein the matching of the receiving order with a received message further comprises: Determine whether the requested matching token has been issued; and If it is determined that the requested matching token has been issued, the matching process between the receive order and the message in the list of unmatched messages is carried out. [19] The method of claim 18, wherein the matching of the receive order with a received message, when it is determined that the requested matching token has not been issued, further comprises: Removing the matching message from the list of unmatched messages; and Notify the token manager of a failed request. [20] Method according to claim 18, wherein processing the matching between the receive order and the message in the list of unmatched messages comprises: Determine whether a current domain is a domain for processing data of the matched message for the matching engine performing the match; if determined to be the domain for processing data of the matched message for the matching engine, initiate a receive log for the message data and remove the matched message from the list of unmatched messages; and If it is determined that the current domain for the matching engine performing the matching is not the domain for processing data of the matched message, mark the receive job in a matching table as complete and remove the matched message from the list of unmatched messages.