A method and system for emulated data communication between multiple clients

Abstract

This invention discloses a simulation data communication method and system for multiple clients, relating to the field of data transmission technology. The method includes the following steps: obtaining the instantaneous arrival density of simulation status feedback messages and identifying message congestion areas based on the instantaneous arrival density; performing feature decomposition on the feedback messages within the message congestion areas and grouping the feedback messages based on the feature decomposition results to obtain several feedback message groups; extracting the arrival distribution characteristics of feedback messages within each feedback message group within a preset time window and evaluating the arrival load status of the feedback messages based on the arrival distribution characteristics; and performing sequential coordination processing on the feedback messages within the message congestion areas according to the evaluation results and updating the corresponding simulation status version. This solves the problem of disordered processing order caused by the concentrated arrival of feedback messages in a short period of time when multiple clients simultaneously provide simulation status feedback.

Description

Technical Field

[0001] This invention relates to the field of data transmission technology, and more specifically, to a method and system for simulated data communication between multiple clients. Background Technology

[0002] In simulation data communication between multiple clients, it usually refers to a distributed or centralized simulation system architecture in which multiple client nodes participate in the same simulation process simultaneously. Each client needs to receive simulation status updates from the simulation core or coordination node in real time, and will also continuously send back simulation status feedback, confirmation information or control commands to the system based on its own calculation results, interactive operations or status awareness.

[0003] However, multiple clients may perceive the same change in simulation state within the same time period and simultaneously send their respective state responses or acknowledgments to the central node or other clients. When the number of clients is large and they connect concurrently, these feedback messages arrive in a concentrated manner within a very short time window, forming a so-called instantaneous message flood. In this situation, if the processing order of feedback messages is not effectively controlled, the message processing order may become chaotic. For example, messages arriving earlier may be overwritten by messages arriving later, or dependencies may not be followed correctly, leading to unexpected jumps or inconsistencies in the state updates of simulation objects. This disordered processing order not only increases state synchronization latency but may also trigger simulation logic errors. For instance, the state update of one object may depend on another object completing its state change first, but due to message out-of-order delivery, the dependency relationship is disrupted, resulting in inconsistencies in the overall simulation state.

[0004] To address the above problems, this invention proposes a solution. Summary of the Invention

[0005] To overcome the aforementioned deficiencies of the prior art, embodiments of the present invention provide a simulation data communication method and system for multiple clients. By grouping, load evaluating, and sequentially coordinating the processing of feedback messages arriving in a concentrated manner, the method solves the problem of disordered processing order caused by the concentrated arrival of feedback messages in a short period of time when multiple clients simultaneously provide simulation status feedback.

[0006] To achieve the above objectives, the present invention provides the following technical solution: A simulation data communication method for multiple clients includes the following steps: obtaining the instantaneous arrival density of simulation status feedback messages, and identifying message congestion areas of the simulation status based on the instantaneous arrival density; performing feature decomposition on the feedback messages within the message congestion areas and grouping the feedback messages based on the feature decomposition results to obtain several feedback message groups; extracting the arrival distribution characteristics of the feedback messages within each feedback message group within a preset time window, and evaluating the arrival load status of the feedback messages based on the arrival distribution characteristics; performing sequential coordination processing on the feedback messages within the message congestion areas according to the evaluation results, and updating the corresponding simulation status version.

[0007] In a preferred embodiment, the step of obtaining the instantaneous arrival density of simulation status feedback messages and identifying message congestion areas in the simulation status based on the instantaneous arrival density specifically involves: obtaining simulation status feedback messages sent by each client and counting the number of messages in each time slice; calculating the instantaneous arrival density of simulation status feedback messages based on the number of messages in each time slice, and determining the message arrival transient characteristic type based on the instantaneous arrival density; marking time slice sequences on the time axis where the number of messages continuously exceeds a preset dynamic threshold based on the message arrival transient characteristic type; constructing a client communication graph based on the logical topology relationship between each client in the simulation; and combining the time slice sequence and the client communication graph to identify abnormal client sets and calculate the simulation logical range covered by the communication links corresponding to the abnormal client sets in the client communication graph, thereby obtaining the message congestion area.

[0008] In a preferred technical solution, the step of constructing the client communication graph based on logical topology relationships specifically involves: taking the client as a vertex, if the simulation entity controlled by the first client undergoes a state change and the simulation entity controlled by the second client needs to perform a corresponding state update, then a directed edge is established between the two vertices, pointing from the first client to the second client; historical communication data is acquired, and the frequency and delay of the first client triggering the second client to generate feedback messages are calculated based on the historical communication data; the weight of the directed edge is determined based on the frequency and delay of the feedback messages, thus obtaining the client communication graph.

[0009] In a preferred technical solution, the step of deconstructing the feedback messages within the message congestion area and grouping them based on the deconstruction results to obtain several feedback message groups specifically involves: parsing the message structure of each feedback message within the message congestion area and extracting the simulation object state data field; identifying the simulation object state change type represented by the simulation object state data field and extracting the state change sequence of the same simulation object in multiple feedback messages at consecutive timestamps; analyzing the semantic continuity of the state change sequence and aggregating the feedback messages in conjunction with the simulation object state change type to obtain several message clusters; evaluating the state dependencies of the simulation objects among the several message clusters and merging the several message clusters based on the evaluation results to obtain several feedback message groups.

[0010] In a preferred technical solution, the evaluation of the state dependencies of simulation objects among several message clusters specifically involves: extracting the state transition features of each simulation object based on the state change sequence, and clustering the state transition features to obtain several state transition clusters; mapping the simulation objects in several messages to the state transition clusters to obtain state dependency chains, and calculating the state update time interval of the simulation objects corresponding to the message clusters in each state dependency chain.

[0011] In a preferred technical solution, the step of extracting the arrival distribution characteristics of feedback messages within each feedback message group within a preset time window and evaluating the arrival load status of feedback messages based on the arrival distribution characteristics specifically involves: setting an observation time window with an adjustable length, ending at the current time, for each feedback message group; statistically analyzing the arrival times of all feedback messages within each feedback message group within the observation time window and plotting a distribution histogram of arrival times; calculating the dispersion of adjacent intervals in the arrival time sequence and combining the skewness and kurtosis of the distribution histogram to quantize the arrival distribution characteristics; obtaining the reference arrival distribution pattern of the simulation object corresponding to each feedback message group under historical normal operation; comparing the quantized arrival distribution characteristics within the current observation time window with the reference arrival distribution pattern in multiple dimensions; and evaluating the arrival load status of the feedback message group based on the comparison results to obtain the load status level of each feedback message group.

[0012] In a preferred embodiment, the step of sequentially coordinating the processing of feedback messages within the message congestion area based on the evaluation results and updating the corresponding simulation state version specifically involves: sorting the feedback messages within each feedback message group according to their load status level to obtain a topology sequence within the group; constructing a coordination processing queue for the message congestion area based on the topology sequence within the group; scheduling computing resources to process the feedback messages sequentially according to the order of the coordination processing queue; updating the state of the simulation object being operated on based on its semantic action after each message is processed; and packaging the latest state of the corresponding simulation object and broadcasting a new simulation state version to all relevant clients when all messages within a feedback message group have been processed.

[0013] In a preferred embodiment, the step of constructing a coordinated processing queue for the message congestion region based on the intra-group topology sequence specifically involves: identifying message pairs with overlapping state update windows based on the state update time interval of the simulated objects in the state dependency chain of each feedback message group; calculating the conditional probability density of the arrival time interval of each message pair within a preset time window based on the arrival time sequence of each message pair; iteratively solving the collision probability estimate of each message pair using a preset maximum likelihood estimation algorithm based on the conditional probability density; and reordering the intra-group topology sequence based on the collision probability estimate to obtain the coordinated processing queue for the message congestion region.

[0014] The technical effects and advantages of the simulation data communication method and system for multiple clients proposed in this invention are as follows: This invention acquires simulation status messages from various clients and calculates their instantaneous arrival density, identifying congestion areas caused by concentrated message arrivals based on this density. Subsequently, it deconstructs the features of feedback messages within these congestion areas and groups messages with similar state change characteristics based on the deconstruction results, forming several feedback message groups. Next, it extracts the arrival distribution features of each feedback message group within a preset time window and evaluates the arrival load status of the current group by comparing it with historical normal distributions. Finally, based on the evaluation results, it coordinates the sequential processing of feedback messages within each group and updates the corresponding simulation object status in real time after each message is processed, ensuring that the processing order strictly follows state dependencies. Simultaneously, it generates and broadcasts a new simulation status version to the relevant clients. Through these steps, it effectively solves the problem of disordered processing caused by the concentrated arrival of feedback messages in a short period when multiple clients simultaneously report simulation status. This not only ensures the orderliness and consistency of simulation object status updates but also reduces state synchronization delays caused by message congestion, improving the overall reliability and real-time performance of simulation communication. Attached Figure Description

[0015] Figure 1This is a flowchart illustrating a simulation data communication method for multiple clients according to the present invention.

[0016] Figure 2 This is a schematic diagram of the structure of a simulation data communication system for multiple clients according to the present invention. Detailed Implementation

[0017] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0018] Example 1, Figure 1 This invention provides a simulation data communication method for multiple clients, comprising the following steps: S1, obtain the instantaneous arrival density of simulation state feedback messages, and identify message congestion areas of the simulation state based on the instantaneous arrival density; In this embodiment, the instantaneous arrival density of simulation state feedback messages is obtained, and message congestion areas of the simulation state are identified based on the instantaneous arrival density, specifically as follows: Obtain the simulation status feedback messages sent by each client and count the number of messages in each time slice; The instantaneous arrival density of simulation state feedback messages is calculated based on the number of messages in each time slice, and the transient characteristic type of message arrival is determined based on the instantaneous arrival density. Based on the transient characteristic type of message arrival, time slice sequences are marked on the time axis where the number of messages continuously exceeds a preset dynamic threshold; Based on the logical topological relationships between each client in the simulation, a client communication graph is constructed. By combining the time-slice sequence and the client communication graph, abnormal client sets are identified and the simulation logic range covered by the corresponding communication links in the client communication graph is calculated to obtain the message congestion area.

[0019] It should be noted that in simulations involving multiple clients, each client typically manages a portion of the simulation entities or interactive roles. When the simulation entity it controls receives an external state update, completes local simulation, or executes a state response, it sends a feedback message back to the unified coordination node. This message indicates that "the simulation entity has sensed a state change and responded accordingly," and is known as the simulation state feedback message. Specifically, the coordination node maintains an independent message receiving channel for each client at the communication entry point. All incoming feedback messages are appended with the source client identifier and arrival timestamp, and written to the message buffer queue in chronological order. Based on this, the continuous timeline is divided into time slices with fixed granularity (e.g., milliseconds or microseconds). At the end of each time slice, the number of feedback messages entering the buffer queue within that time slice is counted, thus obtaining the number of feedback messages generated by all clients within a given time slice. For example, if client A reports 3 simulation entity confirmation messages and client B reports 2 linkage response messages within a 10-millisecond time slice, the total number of messages in that time slice is 5. This statistical result serves as the initial input for subsequent analysis.

[0020] Furthermore, instantaneous arrival density essentially describes the density of feedback message arrivals within an extremely short timescale. It is not an attribute of a single message, but rather a holistic characterization of the intensity of message arrivals over a very short period. In implementation, it doesn't directly use the number of messages in a single time slice. Instead, it includes the current time slice and several adjacent time slices in its observation scope. By comparing the changing trends of message counts within these consecutive time slices, a metric reflecting whether messages are experiencing a concentrated influx at that moment is obtained. For example, if the number of messages remains stable in single digits for several consecutive time slices, but suddenly jumps to dozens in a certain time slice and remains high in subsequent time slices, the instantaneous arrival density for that time slice is considered significantly increased. Conversely, if the number of messages fluctuates but remains dispersed without a clear concentration trend, the corresponding instantaneous arrival density is at a normal level. In this way, instantaneous arrival density is used to characterize whether feedback messages are arriving in a cluster at the current instant.

[0021] Furthermore, after obtaining the instantaneous arrival density changes over continuous time slices, different types of message arrival transient characteristics can be identified from a temporal evolution perspective. These types describe the pattern characteristics of message arrival behavior over a short period of time. Specifically, this involves observing the changes in instantaneous arrival density over time, such as whether there is a sudden surge, a rapid decline, periodic fluctuations, or a sustained high-level plateau, and classifying these characteristics accordingly. Common transient characteristic types include: burst type (density rises sharply and then recovers quickly, usually caused by synchronous triggering events), sustained accumulation type (density rises and remains high over multiple time slices, reflecting obstructed feedback processing), oscillating type (density repeatedly switches between high and low, often related to repeated triggering of state dependencies between clients), and stable type (density remains within a normal range). For example, during a simulation scenario switch, all clients almost simultaneously acknowledge the new state, forming a short but dense feedback surge; this type of situation is identified as a burst type transient characteristic.

[0022] Secondly, after identifying different transient feature types of message arrivals, not all high-density time slices are treated the same. Instead, a dynamic threshold that changes over time is set based on the current feature type to determine which time slices truly constitute a congestion process worthy of attention. In specific implementation, different threshold adjustment strategies are first matched to different transient feature types. For example, a higher threshold is used for bursty transients to avoid false positives, while a gradually decreasing threshold is used for persistently accumulating transients to expose risks early. Subsequently, the number of messages in each time slice is compared one by one on the timeline to see if it consistently exceeds the dynamic threshold, and time slices that consecutively meet the condition are connected into a time slice sequence. For example, if the number of messages is higher than the current threshold for five consecutive time slices within a certain period, even if a single time slice does not reach an extreme peak, it will be marked as a potential message congestion time slice sequence for subsequent spatial range identification.

[0023] It's important to note that the logical topology between clients is not the same as network connectivity. Instead, it originates from state dependencies and behavioral triggering relationships at the simulation logic level, describing whether a change in the state of one client will induce responses from other clients. In simulation, if a simulated entity controlled by a client undergoes a state change, and entities controlled by other clients need to perform linked updates, collaborative actions, or consistency confirmations based on that state, then a clear logical dependency exists between these clients. For example, in formation simulation, a change in the pose of the leader client triggers multiple follower clients to adjust their positions; in this case, a directed logical association is formed between the leader client and each follower client. By analyzing these state triggers, response sequences, and historical interaction paths, a client logical topology reflecting the internal operational structure of the simulation can be constructed for subsequent analysis of the root causes of message propagation and feedback aggregation.

[0024] Finally, after obtaining the time-slice sequence with an abnormally concentrated number of messages, the clients that generated feedback messages within these time slices are further mapped to the client communication graph. This allows for the identification of which clients repeatedly and frequently generate feedback during the abnormal time period, thus filtering out the set of clients whose behavior significantly deviates from normal behavior at that stage; this set is the abnormal client set. Subsequently, starting from these abnormal clients, the client communication graph is expanded upstream and downstream along their logical dependency chains to identify other clients directly or indirectly affected by them, and the corresponding communication links are summarized. The simulation entities, interaction relationships, and state propagation paths covered by these links collectively constitute the simulation logic scope affected by the abnormal event. For example, if three clients are found to repeatedly generate dense feedback within the abnormal time slice, and they are all located on the core path of the same simulation subtask in the communication graph, then the simulation logic region corresponding to that subtask is determined to be a message congestion region, thus providing a precise boundary for subsequent sequence coordination and state version updates.

[0025] In this embodiment, a client communication graph is constructed based on logical topology relationships, specifically as follows: With the client as the vertex, if the simulation entity controlled by the first client undergoes a state change and the simulation entity controlled by the second client needs to perform a corresponding state update, then a directed edge is established between the two vertices, pointing from the first client to the second client. Acquire historical communication data, and calculate the frequency and delay of the first client triggering the second client to generate feedback messages based on the historical communication data; The weights of directed edges are determined based on the frequency and delay of feedback messages, thus obtaining the client communication graph.

[0026] It should be noted that during simulation operation, each client is typically responsible for a relatively fixed set of simulation entities for a long period. Therefore, the client can naturally be used as a logical node to carry out the initiation and response relationships of state changes. When the simulation entity controlled by the first client undergoes a state change, if the simulation rules require the simulation entity controlled by the second client to perform synchronous updates, collaborative adjustments, or consistency confirmations based on this change, it indicates that the behavior of the second client logically depends on the state output of the first client. At this point, a directed relationship can be established between the two. In specific implementation, the source and target simulation entities involved in each state update are first marked in the simulation configuration or runtime record. Then, based on the binding relationship between the simulation entity and the client, this dependency is mapped to the client level, forming a directed edge from the source client to the target client. For example, after the simulation entity controlled by client A completes its attitude adjustment, the simulation entity controlled by client B must update its relative position accordingly. In this case, a directed edge from A to B is established in the communication graph to represent the state-driven direction.

[0027] Furthermore, historical communication data primarily originates from feedback message records accumulated during long-term simulation operation. These records typically include the message source client, associated simulation entities, message arrival time, and corresponding triggering context. By tracing these records, a pattern can be identified: at a certain point in time, the first client generates feedback related to a state change, followed by a semantically related response from the second client within a short time window. Long-term statistical analysis of these sequentially related message pairs reveals the frequency at which the first client triggers the second client's feedback. Simultaneously, by comparing the timestamp difference between two consecutive messages, the typical response latency under this triggering relationship can be estimated. For example, in one hour of simulation data, if it is found that after a certain state change by client A, client B responds within tens of milliseconds in 80% of cases, then a high-frequency, low-latency triggering relationship between A and B can be considered. These statistical results will serve as important criteria for subsequent weight evaluation.

[0028] Finally, after obtaining the triggering frequency and response latency between clients, weights can be assigned to directed edges to characterize the strength of the dependency in the simulation. The weighting approach is not based on a single metric, but rather considers both the frequency of triggering and the tightness of responses: higher triggering frequency and shorter response latency indicate a stronger dependency of the client on the state, resulting in a larger weight for the corresponding directed edge; conversely, if triggering is sporadic and responses are loose, the weight is relatively low. By assigning weights to the directed edges between all clients, the resulting client communication graph is a logical graph reflecting the state propagation path within the simulation. Vertices represent the participating clients, directed edges represent the state-driven directions, and edge weights reflect the tightness of state influence. For example, in a collaborative simulation, edges from the lead client to multiple subordinate clients typically have higher weights, while edges between subordinate clients have lower weights. This communication graph visually reflects which clients are the core nodes of state propagation and provides a structural basis for subsequent congestion identification and range definition.

[0029] S2, perform feature decomposition on the feedback messages in the message congestion area and group the feedback messages based on the feature decomposition results to obtain several feedback message groups; In this embodiment, the feedback messages within the message congestion area are deconstructed by features, and the feedback messages are grouped based on the feature deconstruction results to obtain several feedback message groups, specifically: The message structure of each feedback message within the message congestion area is analyzed, and the state data fields of the simulation object are extracted. Identify the state change type of the simulation object represented by the state data field of the simulation object, and extract the state change sequence of the same simulation object in multiple feedback messages under consecutive timestamps; The semantic continuity of the state change sequence is analyzed and the feedback messages are aggregated in combination with the state change type of the simulation object to obtain several message clusters; The state dependencies of simulation objects among several message clusters are evaluated, and the message clusters are merged based on the evaluation results to obtain several feedback message groups.

[0030] It's important to note that within the defined message congestion area, each feedback message is encapsulated in a predefined message format, typically consisting of a message header, an object identifier field, a status data field, and auxiliary marker fields. During parsing, the entire message is first structurally broken down based on the type identifier and length information in the message header. Then, based on field offsets or tag indices, the core data area carrying the simulation object's status is directly located. This area usually contains the simulation object's unique identifier, the current status value, and the context flag that triggered the status change. For example, in a feedback message from a client, the beginning of the message indicates the source and timestamp, while the middle field records "Object ID=U23, current location changed from A to B, speed parameters adjusted." This middle field is extracted as the simulation object's status data field, and all subsequent feature deconstruction and grouping revolve around this field.

[0031] Secondly, after extracting the state data fields of the simulation object, it is necessary to further determine which type of state change the field describes. This is usually done by comparing the changes in the state items within the field. Specifically, the current state data is compared with the state of the simulation object at the previous moment to identify which state dimensions have changed, thereby determining the corresponding change type. Common types of simulation object state changes include: position or attitude changes (e.g., coordinate or angle updates), behavior phase changes (e.g., switching from "waiting" to "executing"), attribute parameter changes (e.g., energy value or velocity threshold adjustments), and relationship state changes (e.g., establishing or disassociating with other objects). For example, if the state field only reflects continuous coordinate movement, it is identified as a continuous spatial change; if a behavior flag change also occurs, it is identified as a phase transition change. This type distinction provides a semantic basis for subsequent aggregation.

[0032] Furthermore, within message congestion zones, the same simulated object often receives multiple feedbacks within a short period. Therefore, it is necessary to use the object as the main thread to string these discrete messages into an ordered sequence. Specifically, all feedback messages are first categorized according to the simulated object's identifier, and then sorted within each category based on timestamps, thus obtaining the object's state change trajectory over a continuous period. For example, during a certain congestion period, object U23 might generate three feedback messages: "position fine-tuning," "speed correction," and "behavior switching." These three messages are closely adjacent on the timeline. Arranging them in chronological order forms U23's state change sequence, which fully reflects the object's evolution during that period.

[0033] Secondly, the semantic continuity of the state change sequence is used to determine whether these continuous changes belong to the same logical process, rather than independent random updates. During analysis, the focus is on examining the consistency of adjacent state changes in type, direction, and objective. For example, whether they progressively advance around the same behavioral goal, whether they represent gradual parameter adjustments, or whether there are abrupt jumps. For instance, if an object's state sequence is "minor position adjustment -> synchronous speed correction -> posture refinement," then these changes can be considered highly semantically continuous, belonging to a complete action process. Conversely, if "position update -> behavior interruption -> relationship unbinding" occurs within a short period, and there is a lack of logical connection between the changes, then the semantic continuity is weak, and it is more likely to be processed in stages.

[0034] After extracting the state change sequence and performing semantic continuity analysis, feedback messages with high semantic relevance can be aggregated to form message clusters. Aggregation requires that the messages act on the same simulation object or the same set of objects, and that their state change types are semantically interconnected, such as belonging to the same continuous position update or the same behavioral phase progression. Specifically, when multiple feedback messages are in adjacent time periods, identified as belonging to the same type or strongly related state change type, and their state change sequences exhibit a continuous progression relationship, they can be merged into a message cluster. For example, if object U23 continuously generates 5 position fine-tuning messages within 20 milliseconds, these 5 messages are no longer considered independent events but are aggregated into a continuous displacement adjustment message cluster to reduce the granularity of subsequent processing.

[0035] Finally, after obtaining multiple message clusters, it is necessary to evaluate whether state dependencies exist between them from a cross-object and cross-cluster perspective. During the evaluation, the focus is on whether state changes of simulation objects involved in one message cluster become preconditions for changes in objects in another message cluster. For example, does a position change trigger behavioral adjustments in collaborating objects, or does an attribute change trigger a chain reaction? If two or more message clusters are found to highly overlap in time, and there is a clear state triggering relationship between their corresponding objects, then these message clusters are considered to have strong state dependencies and should be further merged. For example, one message cluster describes the path adjustment of a navigation object, and another message cluster describes the formation correction of multiple subordinate objects. Although they originate from different objects, they are tightly coupled in simulation logic and therefore will be merged into the same feedback message group.

[0036] In this embodiment, the state dependencies of simulated objects among several message clusters are evaluated, specifically as follows: State transition features of each simulation object are extracted based on the state change sequence, and the state transition features are clustered to obtain several state transition clusters; Several message clusters of simulation objects are mapped to state transition clusters to obtain state dependency chains, and the state update time interval of the simulation objects corresponding to the message clusters in each state dependency chain is calculated.

[0037] It's important to note that state transition features are not a single instantaneous state itself, but rather a behavioral pattern used to characterize how a simulated object's state evolves from one stage to the next over a period of time. Specifically, the extraction is based on the state change sequence of the same simulated object, focusing on the direction, rhythm, and span of change between adjacent states—for example, whether it's a gradual, progressive change, a repetitive back-and-forth change, or a one-time jump. In implementation, each adjacent state change in the state change sequence is marked, and descriptive features such as "from which type of state to which type of state," "whether there is an intermediate buffer stage," and "whether there are frequent switches in a short period" are extracted. For example, if an object exhibits "low speed -> medium speed -> high speed" over consecutive timestamps, it indicates that its state transition has a unidirectional increasing characteristic; while if it exhibits "execution -> pause -> execution," it reflects a clear back-and-forth switching characteristic. These summarized change patterns constitute the object's state transition features.

[0038] After obtaining the state transition characteristics of multiple simulation objects, objects with similar transition patterns can be further grouped together to form state transition clusters. Clustering does not focus on the specific identity of an object, but rather on whether its state evolution is similar. For example, whether they all exhibit smooth, continuous adjustments, whether they all have obvious stage jumps, or whether they are accompanied by frequent rollbacks and retries. Specifically, the state transition characteristics of each object are compared as a whole behavioral description, and objects with highly similar transition rhythms, change directions, and stage structures are grouped into the same cluster. For instance, in a certain simulation, a group of objects all exhibit "multiple fine-tunings in a short period before entering a stable state" and will be grouped into the same state transition cluster; while another group of objects frequently exhibits "trigger-rollback-re-trigger" behavior and will be classified into different clusters, thus distinguishing different types of dynamic behavior at a higher level.

[0039] Furthermore, for a single simulation object, the extraction of the state change sequence is based on timestamps. In practice, firstly, a set of messages matching the object's identifier is selected from all feedback messages. Then, these messages are sorted according to their timestamps, thus connecting the originally discrete feedback messages into an ordered sequence. Each node in this sequence corresponds to a specific state change, while adjacent nodes reflect the evolutionary relationship of the object's state. For example, during a congested period, object A might generate three consecutive feedback messages—"position correction," "velocity adjustment," and "attitude stabilization"—within 20 milliseconds. Arranging these three messages in chronological order constitutes the state change sequence of object A during that period, providing complete material for subsequent transition feature extraction.

[0040] Secondly, based on the established state transition clusters, each simulation object in the feedback message can be mapped to its respective state transition cluster, thereby establishing evolutionary relationships between objects at the message level. Specifically, the simulation objects involved in each message cluster are first identified, then the corresponding state transition cluster identifiers are queried, and finally, objects in different clusters are connected according to the message triggering order to form a state dependency chain. This dependency chain reflects the relationship that "after one type of state transition behavior occurs, another type of state transition behavior is triggered." For example, if a set of messages first contains a "path adjustment" state transition cluster, followed by a "formation correction" state transition cluster, a state dependency chain from path adjustment to formation correction can be formed to characterize the linkage relationship across objects and across behavior stages.

[0041] Finally, after constructing the state dependency chain, it is necessary to further evaluate the temporal tightness between state changes in the chain, i.e., the state update time interval. Specifically, the timestamp of the most recent state update of the corresponding simulation object is extracted from adjacent message clusters in the state dependency chain, and these timestamps are compared to obtain the time interval between state changes. For example, in a state dependency chain, if the object corresponding to the preceding message cluster completes a state update at a certain moment, and the object in the following message cluster responds with an update a few milliseconds later, it indicates that the state update time interval between the two is small, and the dependency is tight; if the time interval is long, it indicates that the dependency is relatively loose. By statistically analyzing these intervals, a basis can be provided for subsequently determining whether message clusters need to be further merged.

[0042] S3, extract the arrival distribution characteristics of feedback messages in each feedback message group within a preset time window, and evaluate the arrival load status of feedback messages based on the arrival distribution characteristics; In this embodiment, the arrival distribution characteristics of feedback messages within each feedback message group are extracted within a preset time window, and the arrival load status of feedback messages is evaluated based on the arrival distribution characteristics. Specifically: Set an adjustable observation time window for each feedback message group, with the current time as the endpoint; Calculate the arrival times of all feedback messages within each feedback message group within the observation time window, and plot a histogram of the arrival times distribution; Calculate the dispersion of adjacent time intervals in the arrival time sequence, and combine the skewness and kurtosis of the distribution histogram to quantify the arrival distribution characteristics; Obtain the reference arrival distribution pattern of the simulation object corresponding to each feedback message group under historical normal operation; The quantitative arrival distribution characteristics within the current observation time window are compared with the reference arrival distribution pattern in multiple dimensions. Based on the comparison results, the arrival load status of the feedback messages in the feedback message group is evaluated, and the load status level of each feedback message group is obtained.

[0043] It's important to note that when load-assessing feedback message groups, the core purpose of the observation time window is to capture the actual arrival process of messages over a period prior to the current moment. Therefore, the window uniformly uses the current processing time as the endpoint for backward look-back. Specifically, an independent time observation range is maintained for each feedback message group, and the window length is dynamically adjusted based on the recent arrival activity of that group: when a group of messages arrives sparsely, the window extends further forward to obtain sufficient samples; when arrivals are dense, the window shortens to highlight instantaneous changes. For example, if a feedback message group has received messages continuously in the last few tens of milliseconds, the observation window can be set to "back 50 milliseconds from the current moment"; while if the arrival of messages in that group is sporadic, the window can be extended to hundreds of milliseconds to ensure the stability of the analysis. In this way, the observation time window is both anchored to the current situation and adaptive.

[0044] After determining the observation time window, firstly, all feedback messages whose arrival times fall within the window range are selected from the feedback message group, and their arrival time records are extracted. Then, the entire observation time window is divided into several consecutive smaller time intervals, each representing a statistical bucket. The arrival time of each feedback message is then assigned to its corresponding time interval, and the number of messages within each interval is counted. The resulting histogram can be considered a distribution histogram of arrival times, where the horizontal axis represents the chronological order of the time intervals, and the vertical axis represents the concentration of messages within that interval. For example, if a 50-millisecond window is divided into 10 intervals, and the first two intervals have very few messages while the middle intervals suddenly have a high concentration of messages, the histogram will show a clear central spike, providing an intuitive basis for subsequent distribution characteristic analysis.

[0045] After obtaining the arrival time sequence of feedback messages, these times are first arranged chronologically, and the time interval between adjacent messages is calculated one by one, thus obtaining a set of interval time series. The calculation of dispersion does not rely on a specific formula, but rather on observing the degree of fluctuation of these interval values ​​relative to their typical level: first, the concentrated interval intervals are determined, and then the deviation of each interval from these concentrated intervals is measured. If most intervals are close while a few intervals are significantly larger or smaller, the dispersion is high; conversely, if the intervals are evenly distributed, the dispersion is low. Based on this, the distribution characteristics are further quantified by combining the histogram shape: skewness is judged by observing whether the distribution is significantly tilted to one side, for example, a large number of messages concentrated in the first half of the window indicates left skewness; then, kurtosis is assessed by judging whether the messages are highly concentrated in a few intervals, for example, most messages are piled up in one or two intervals, indicating high kurtosis. Finally, dispersion, skewness, and concentration are used together as the characteristics describing the arrival distribution of this feedback message group.

[0046] Furthermore, the reference arrival distribution pattern is used to characterize how such feedback messages typically arrive under conditions of no congestion and no anomalies. This is achieved by tracing back through historical operation records to time periods marked as stable and anomaly-free, filtering out historical feedback messages that match the simulation objects and state types involved in the current feedback message group, and then statistically analyzing their arrival time distribution, interval rhythm, and concentration pattern in the same manner as the current analysis. By summarizing multiple historical samples, a representative normal arrival distribution pattern can be formed. For example, a certain type of object typically exhibits "uniform intervals, no obvious peaks, and a flat histogram" during normal operation; this pattern serves as the reference baseline for that feedback message group for subsequent comparison and judgment.

[0047] Secondly, multi-dimensional comparison is not a single-indicator comparison, but rather an assessment from multiple perspectives of whether the current distribution deviates from the norm. Specifically, the dispersion level, distribution skew direction, and concentration obtained within the current observation window are compared one by one with the corresponding features in the reference arrival distribution pattern to determine the magnitude and direction of the deviation. For example, if the current dispersion is significantly higher than the historical norm, it indicates that the message arrival rhythm has become unstable; if the current distribution shows a significant skewness, while the historical distribution is basically symmetrical, it indicates that messages are concentrated in a certain period; if the current kurtosis is significantly increased, it indicates that messages have accumulated in a short period.

[0048] Finally, after completing the multi-dimensional comparison, the deviations in each dimension are combined to classify and assess the arrival load status of the feedback message group. Specifically, if the current distribution in dispersion, skewness, and kurtosis is highly close to the reference pattern, the message group is determined to be under normal load; if there is a slight deviation in one dimension, but the overall load is still acceptable, it is determined to be a slight increase in load; if there are significant deviations in multiple dimensions simultaneously, such as high dispersion combined with high kurtosis, it indicates that a large number of messages have flooded in within a short period of time, putting pressure on the processing flow, and can be determined to be a high load state. Ultimately, each feedback message group is assigned a clear load status level, providing a direct basis for subsequent sequence coordination and processing strategy selection.

[0049] S4. Based on the evaluation results, perform sequential coordination processing on the feedback messages within the message congestion area and update the corresponding simulation state version.

[0050] In this embodiment, feedback messages within the message congestion area are processed sequentially and coordinated according to the evaluation results, and the corresponding simulation state version is updated. Specifically: Based on the load status level of each feedback message group, the feedback messages within the feedback message group are sorted topologically to obtain the topological sequence within the group; A coordinated processing queue for message congestion regions is constructed based on the group's topology sequence. The scheduling computing resources process feedback messages sequentially according to the order of the coordination processing queue. After each message is processed, the state of the simulation object being operated on is updated according to its semantic action. When all messages in a feedback message group have been processed, the latest state of the corresponding simulation object is packaged, generated, and a new simulation state version is broadcast to all relevant clients.

[0051] It's important to note that after obtaining the load status level of each feedback message group, the first step is to determine whether there are sequential dependencies between the feedback messages within that group. For example, a message might only be semantically valid after another message has been processed. Specifically, each feedback message in the group is treated as a node. Based on the previously identified state dependency chain, if the state of the simulation object operated on by one message is a prerequisite for another message, a directed relationship is established between them. On this basis, the sorting strategy is adjusted according to the load status level. For example, under high load, strict dependency satisfaction is prioritized, while under low load, more flexible sorting is allowed. The topology sorting process involves finding a processing order that does not violate any dependency direction under these directed relationship constraints: first, select nodes that do not depend on other messages as the starting point, gradually remove sorted nodes and release the processing conditions of subsequent nodes until all messages in the group are sorted. The final group topology sequence is an ordered message sequence that clearly defines "which feedback message is processed first, and which is processed later," such as "path update -> location synchronization -> behavior confirmation." This sequence provides a stable execution order for subsequent coordinated processing.

[0052] Furthermore, after constructing the coordination processing queue for the good news congestion area, the scheduling process strictly follows the order of the queue to retrieve and process feedback messages one by one. Each time a feedback message is retrieved, the semantic action described within it is first parsed, such as a position adjustment, attribute update, or behavior phase switch. Then, this semantic action is applied to the current state of the corresponding simulation object, completing a clear state update. The processing follows the principle of "process one, update one," ensuring that each state change is based on the previous change, thereby avoiding state overwriting or semantic conflicts caused by concurrent processing. For example, in the coordination processing queue, if the first message indicates "object A path correction," the latest path of object A is confirmed after processing; subsequently, the second message indicates "object B performs formation adjustment based on object A's path." At this point, the state that object B relies on is the updated state of object A, thus ensuring the logical consistency and traceability of the entire processing process.

[0053] Finally, once all feedback messages within a given feedback message group have been processed according to the topological sequence, it indicates that the overall state of the simulation objects involved in that message group has stabilized. At this point, the latest state of these simulation objects can be uniformly encapsulated. Specifically, this involves summarizing the current state snapshots of all manipulated simulation objects in the message group to form a complete and self-consistent set of states, and assigning this set a new version identifier to distinguish it from previous state results. Subsequently, this new simulation state version is sent to all clients logically associated with these simulation objects, enabling each client to continue subsequent simulation interactions under the same state baseline. For example, in a cooperative movement scenario, after completing a set of message processing, a new formation state version is generated and simultaneously notified to all clients participating in that formation, thus preventing the accumulation of deviations caused by different clients continuing to extrapolate based on different intermediate states.

[0054] In this embodiment, a coordinated processing queue for message congestion regions is constructed based on the intra-group topology sequence, specifically as follows: Based on the state update time interval of the simulation object in the state dependency chain of the feedback message within each feedback message group, identify message pairs with overlapping state update windows; Based on the arrival time sequence of each message pair, calculate the conditional probability density of the arrival time interval of each message pair within a preset time window; Based on the conditional probability density, a preset maximum likelihood estimation algorithm is used to iteratively solve for the collision probability estimate of each message pair; The topology sequence within the group is reordered based on the estimated conflict probability to obtain the coordinated processing queue for the message congestion area.

[0055] It should be noted that within the feedback message group, there are already simulation object state update time intervals obtained based on state dependency chains. These intervals reflect the order and closeness of state changes of different objects on the time axis. Specifically, during identification, the state update time corresponding to each feedback message is taken as the center, and a time range matching the typical update time of that object is extended both forward and backward, forming the state update window for that message. Then, the state update windows of any two feedback messages within the group are compared. If the two windows overlap on the time axis, it indicates that these two messages may compete for state consistency resources within the same time period during actual processing. Such two messages are identified as "message pairs with overlapping state update windows." For example, if the object corresponding to message A updates its state around 100 milliseconds, and the update effect lasts until 120 milliseconds; message B triggers an update at 110 milliseconds, and its effect lasts until 130 milliseconds, then there is window overlap between these two messages from 110 to 120 milliseconds, indicating a potential risk of conflict in their processing order.

[0056] After identifying message pairs with overlapping state update windows, it is necessary to further determine the probability of them clashing in time. Specifically, this involves retrospectively analyzing the arrival times of the message pair in historical records, extracting the arrival times of each message at each occurrence, and calculating their arrival interval distribution within a preset time window. Then, given that one message arrives at a certain time, the frequency of the other message's occurrence in different time intervals is statistically analyzed, thus forming a probability distribution of the two messages arriving at a certain time interval under given conditions. For example, in past simulations, if it was found that message B has a high probability of appearing within 5 milliseconds after message A, the conditional probability density within the small interval will significantly increase, providing direct evidence for subsequent conflict probability assessment.

[0057] Furthermore, after obtaining the conditional probability distribution of message pairs, the goal of maximum likelihood estimation is to find the most reasonable conflict probability, making the historically observed arrival intervals most "reasonable" under this probability assumption. The specific calculation process can be broken down into several intuitive steps: First, an initial conflict probability value is assumed to represent the likelihood of a processing conflict occurring when two messages overlap in their state update windows. Second, based on this assumed probability, the occurrence of each message pair arrival interval in history is evaluated to determine whether it aligns with the expectation of conflict occurrence; for example, extremely small intervals are more consistent with the conflict assumption, while larger intervals are more consistent with the non-conflict assumption. Then, the consistency of all historical samples is combined to obtain an overall reasonableness evaluation under the current assumption. Next, the conflict probability value is gradually adjusted to continuously improve this reasonableness evaluation. When, after multiple adjustments, the reasonableness no longer significantly improves, the corresponding conflict probability value is considered the estimate that best matches the historical data. For example, if in 100 historical samples, there are 70 instances where message pairs arrive at very short intervals, and during the iteration process it is found that when the collision probability is set to 0.7, the explanation for these 70 cases is the most natural, then this value will be determined as the collision probability estimate for that message pair.

[0058] Finally, after obtaining the estimated collision probability for each pair of messages, this can be used as a basis for fine-tuning the original intra-group topology sequence. Specifically, without disrupting the original state dependencies, the order of message pairs with high collision probabilities is adjusted to maximize the distance between them in the processing queue, or their order is explicitly fixed to reduce overlap risk; while message pairs with low collision probabilities are allowed to maintain a more compact arrangement. The final order formed after reordering the original topology sequence in this way is the coordinated processing queue. This queue is essentially an optimal processing order that comprehensively considers state dependency constraints and collision risk, used to guide the actual processing rhythm of feedback messages within message congestion areas. For example, in a certain feedback message group, two originally adjacent messages are separated due to high collision probability, while another group of low-collision messages is arranged closely together, thereby reducing the uncertainty and rollback risk in the overall state update process.

[0059] Example 2, Figure 2 This invention presents a simulated data communication system for multiple clients, comprising a congestion identification module, a message packetization module, a load assessment module, and a coordination processing module. The congestion identification module is used to obtain the instantaneous arrival density of simulation state feedback messages and identify message congestion areas in the simulation state based on the instantaneous arrival density. The message grouping module is used to deconstruct the features of feedback messages in the message congestion area and group the feedback messages based on the feature deconstruction results to obtain several feedback message groups. The load assessment module is used to extract the arrival distribution characteristics of feedback messages in each feedback message group within a preset time window, and to assess the arrival load status of feedback messages based on the arrival distribution characteristics. The coordination and processing module is used to coordinate and process feedback messages in the message congestion area in sequence according to the evaluation results, and update the corresponding simulation state version.

[0060] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, in the form of a computer program product.

[0061] Those skilled in the art will recognize that the modules and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0062] In addition, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0063] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0064] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for emulated data communication between multiple clients, characterized by, Includes the following steps: Obtain the instantaneous arrival density of simulation status feedback messages, and identify message congestion areas in the simulation status based on the instantaneous arrival density; The feedback messages within the message congestion area are deconstructed by features, and the feedback messages are grouped based on the feature deconstruction results to obtain several feedback message groups; Extract the arrival distribution characteristics of feedback messages within each feedback message group within a preset time window, and evaluate the arrival load status of feedback messages based on the arrival distribution characteristics; Based on the evaluation results, feedback messages within the message congestion area are processed sequentially and coordinated, and the corresponding simulation state version is updated.

2. The method for emulated data communication between multiple clients as claimed in claim 1 wherein, The acquisition of the instantaneous arrival density of simulation state feedback messages, and the identification of message congestion areas in the simulation state based on the instantaneous arrival density, specifically involves: Obtain the simulation status feedback messages sent by each client and count the number of messages in each time slice; The instantaneous arrival density of simulation state feedback messages is calculated based on the number of messages in each time slice, and the transient characteristic type of message arrival is determined based on the instantaneous arrival density. Based on the transient characteristic type of message arrival, time slice sequences are marked on the time axis where the number of messages continuously exceeds a preset dynamic threshold; Based on the logical topological relationships between each client in the simulation, a client communication graph is constructed. By combining the time-slice sequence and the client communication graph, abnormal client sets are identified and the simulation logic range covered by the corresponding communication links in the client communication graph is calculated to obtain the message congestion area.

3. The method for emulated data communication between multiple clients as claimed in claim 2 wherein, The construction of the client communication graph based on logical topology relationships is specifically as follows: With the client as the vertex, if the simulation entity controlled by the first client undergoes a state change and the simulation entity controlled by the second client needs to perform a corresponding state update, then a directed edge is established between the two vertices, pointing from the first client to the second client. Acquire historical communication data, and calculate the frequency and delay of the first client triggering the second client to generate feedback messages based on the historical communication data; The weights of directed edges are determined based on the frequency and delay of feedback messages, thus obtaining the client communication graph.

4. The method for emulated data communication between multiple clients as claimed in claim 3 wherein, The process of deconstructing the feedback messages within the message congestion area and grouping them based on the deconstruction results to obtain several feedback message groups is as follows: The message structure of each feedback message within the message congestion area is analyzed, and the state data fields of the simulation object are extracted. Identify the state change type of the simulation object represented by the state data field of the simulation object, and extract the state change sequence of the same simulation object in multiple feedback messages under consecutive timestamps; The semantic continuity of the state change sequence is analyzed and the feedback messages are aggregated in combination with the state change type of the simulation object to obtain several message clusters; The state dependencies of simulation objects among several message clusters are evaluated, and the message clusters are merged based on the evaluation results to obtain several feedback message groups.

5. The method for emulated data communication between multiple clients as claimed in claim 4 wherein, The evaluation of the state dependencies of simulation objects among several message clusters specifically involves: State transition features of each simulation object are extracted based on the state change sequence, and the state transition features are clustered to obtain several state transition clusters; Several message clusters of simulation objects are mapped to state transition clusters to obtain state dependency chains, and the state update time interval of the simulation objects corresponding to the message clusters in each state dependency chain is calculated.

6. The method for emulated data communication between multiple clients as claimed in claim 5 wherein, The step of extracting the arrival distribution characteristics of feedback messages within each feedback message group within a preset time window, and evaluating the arrival load status of feedback messages based on the arrival distribution characteristics, specifically involves: Set an adjustable observation time window for each feedback message group, with the current time as the endpoint; Calculate the arrival times of all feedback messages within each feedback message group within the observation time window, and plot a histogram of the arrival times distribution; Calculate the dispersion of adjacent time intervals in the arrival time sequence, and combine the skewness and kurtosis of the distribution histogram to quantify the arrival distribution characteristics; Obtain the reference arrival distribution pattern of the simulation object corresponding to each feedback message group under historical normal operation; The quantitative arrival distribution characteristics within the current observation time window are compared with the reference arrival distribution pattern in multiple dimensions. Based on the comparison results, the arrival load status of the feedback messages in the feedback message group is evaluated, and the load status level of each feedback message group is obtained.

7. The method for emulated data communication between multiple clients as claimed in claim 6 wherein, The step of sequentially coordinating feedback messages within the message congestion area based on the evaluation results and updating the corresponding simulation state version specifically involves: Based on the load status level of each feedback message group, the feedback messages within the feedback message group are sorted topologically to obtain the topological sequence within the group; A coordinated processing queue for message congestion regions is constructed based on the group's topology sequence. The scheduling computing resources process feedback messages sequentially according to the order of the coordination processing queue. After each message is processed, the state of the simulation object being operated on is updated according to its semantic action. When all messages in a feedback message group have been processed, the latest state of the corresponding simulation object is packaged, generated, and a new simulation state version is broadcast to all relevant clients.

8. The method for emulated data communication between multiple clients as claimed in claim 7 wherein, The coordinated processing queue for constructing message congestion regions based on intra-group topology sequences is specifically as follows: Based on the state update time interval of the simulation object in the state dependency chain of the feedback message within each feedback message group, identify message pairs with overlapping state update windows; Based on the arrival time sequence of each message pair, calculate the conditional probability density of the arrival time interval of each message pair within a preset time window; Based on the conditional probability density, a preset maximum likelihood estimation algorithm is used to iteratively solve for the collision probability estimate of each message pair; The topology sequence within the group is reordered based on the estimated conflict probability to obtain the coordinated processing queue for the message congestion area.

9. A system for emulating data communication between multiple clients, applied to the method for emulating data communication between multiple clients according to any one of claims 1 to 8, characterized in that, It includes a congestion identification module, a message packetization module, a load assessment module, and a coordination processing module: The congestion identification module is used to obtain the instantaneous arrival density of simulation state feedback messages and identify message congestion areas in the simulation state based on the instantaneous arrival density. The message grouping module is used to deconstruct the features of feedback messages within the message congestion area and group the feedback messages based on the feature deconstruction results to obtain several feedback message groups. The load assessment module is used to extract the arrival distribution characteristics of feedback messages in each feedback message group within a preset time window, and to assess the arrival load status of feedback messages based on the arrival distribution characteristics. The coordination and processing module is used to coordinate and process feedback messages in the message congestion area in sequence according to the evaluation results, and update the corresponding simulation state version.

Images