A visual route simulation verification platform and a route simulation method

Abstract

A visual routing simulation and verification platform includes: a visual interaction layer, used for graphical display and runtime interaction of network topology based on the Unity editor, Odin serialization framework, and NodeCanvas node graph framework; a centralized management layer, connecting the visual interaction layer and the Burst parallel computing layer, serving as the sole data source, and including a topology management module, a message scheduling module, and a router status management module, used to realize unified registration and global identifier allocation of network nodes, centralized submission and batch delivery scheduling of messages, and centralized storage and computational job coordination of router status data across the entire network; the Burst parallel computing layer, used for multi-threaded parallel acceleration computation of core high-frequency jobs, and writing the computation results back to the centralized management layer. This invention achieves high-performance simulation of large-scale networks, dynamic runtime intervention, and protocol-independent visual debugging.

Description

Technical Field

[0001] This invention relates to the field of network routing technology, and in particular to a visual routing simulation verification platform and routing simulation method. Background Technology

[0002] Network routing is the core mechanism in computer networks that determines the transmission path of data flows from source nodes to destination nodes. The network layer is mainly responsible for end-to-end data transmission and logical addressing. Its core task is to accurately and efficiently transmit data packets across different devices and links to the destination node through routing technology. The routing process involves the exchange of routing information between nodes, the calculation and dynamic updating of routing tables, and the forwarding and scheduling of data packets, which directly determines key performance indicators such as network throughput and latency.

[0003] Network simulation is a technique that uses software computational models to reproduce real network topology and communication behavior. When facing highly dynamic network topologies, such as satellite networks, or novel network architectures employing segmented routing (SRv6), the system state exhibits high complexity. Directly deploying and testing new routing protocols or fault recovery mechanisms in a real physical environment not only faces extremely high hardware construction and maintenance costs but also easily interferes with existing network services or even triggers cascading failures. Therefore, network simulation has become a core means of verifying network technologies without relying on physical hardware. It can digitally construct virtual network nodes (such as routers) and communication links, and accurately simulate the processing, queuing, and forwarding of data packets between these virtual nodes. Through network simulation, researchers can accurately reproduce network problems such as the evolution of dynamic fault domains, high-frequency node failures, and link congestion in a highly controlled and constrained environment. This allows for the evaluation of routing algorithm convergence speed, verification of fault tolerance strategies, and comprehensive testing of network robustness under extreme conditions at extremely low cost.

[0004] Currently, commonly used network routing simulation and testing technologies in this field mainly include discrete event simulators such as NS-3 and software routing protocol stacks such as FRR. However, these existing technologies have significant technical shortcomings in simulating, debugging, and monitoring complex routing logic: traditional simulators typically employ a black-box execution mode, making it difficult for researchers to intuitively intervene in the evolving routing convergence process or modify the topology during runtime. Simultaneously, node status monitoring heavily relies on command-line interfaces or low-level plain text log output, preventing researchers from directly selecting and viewing network status in real time within an intuitive interface. This lack of a unified and highly controllable operating environment makes debugging routing logic and tracking network status extremely cumbersome and inefficient. Summary of the Invention

[0005] To address the problems existing in the prior art, embodiments of this application provide a visual routing simulation verification platform, a routing simulation method, a computing device, a computer storage medium, and a product containing a computer program, which can improve the efficiency of debugging routing logic and tracking network status.

[0006] In a first aspect, embodiments of this application provide a visual routing simulation verification platform, comprising: a visual interaction layer, a centralized management layer, and a Burst parallel computing layer; wherein, the visual interaction layer is used to construct a graphical display and runtime interactive interface for network topology based on the Unity editor, the Odin serialization framework, and the NodeCanvas node graph framework; the centralized management layer connects the visual interaction layer and the Burst parallel computing layer, serving as the sole data source, and includes a topology management module, a message scheduling module, and a router status management module, used to realize unified registration and global identifier allocation of network nodes, centralized submission and batch delivery scheduling of messages, and centralized storage and computational job coordination of router status data across the entire network; the Burst parallel computing layer is used to perform multi-threaded parallel accelerated computation on core high-frequency jobs and write the computation results back to the centralized management layer.

[0007] In some possible implementations, the topology management module is specifically used to: during the simulation preprocessing stage, assign a globally unique integer ID to each network node in a monotonically increasing manner, and establish a bidirectional mapping relationship between the integer ID and the node name and node object; wherein, the ID is assigned according to the node name to ensure that the same network topology generates a consistent ID mapping relationship in different editor sessions.

[0008] In some possible implementations, the message scheduling module is specifically used to: submit messages to be forwarded to the buffer message pool; calculate the number of transmission waiting frames by combining the bandwidth and cost attributes of the link with the data payload of the message through a time consumption fitting mechanism, and generate the arrival frame timestamp of the message; in each simulation frame, trigger the underlying parallel arrival detection job, batch check the timestamps of messages in the buffer pool, and uniformly deliver the arrived messages to the corresponding target nodes.

[0009] In some possible implementations, the router state management module is specifically used to: adopt a data-oriented design to completely flatten the link state database, routing table, and forwarding plane information of all network nodes, and centrally store them in an underlying unmanaged contiguous memory container; wherein, the link state database is stored using integer ID pairs of the nodes at both ends of the link as keys, and the routing table is stored using composite pairs of router ID and target network ID as keys.

[0010] In some possible implementations, the Burst parallel computing layer includes: a parallel arrival detection job, used to concurrently determine the arrival status of packets in the buffer message pool within each simulation frame, and push the index of the arrived packets into the shared index list without locking; a parallel data forwarding job, used to traverse the packets to be forwarded in parallel, look up the next hop in the global routing table based on the integer ID of the target node in the packet, generate a new forwarding packet and submit it to the buffer message pool; and a shortest path first calculation job, used to recalculate the routing table for the affected routers in parallel when the link state database is updated.

[0011] Secondly, embodiments of this application provide a routing simulation method, including: constructing a network topology, creating router nodes and communication links, assigning a globally unique integer ID to each node, and establishing a bidirectional mapping relationship between the integer ID and the node name and node object; completing the construction of the link state database and shortest path first calculation through protocol flooding simulation, generating a network-wide routing table, and centrally storing the link state databases, routing tables, and forwarding plane information of all routers in an underlying unmanaged contiguous memory container; using the Unity frame loop as the simulation clock driver, executing parallel arrival detection, arrival packet delivery, protocol processing, packet sending, and shortest path first calculation scheduling sequentially within each simulation frame; converting link attributes and packet payloads into transmission waiting frame counts through a time consumption fitting mechanism, generating arrival frame timestamps, storing packets in a buffer message pool, and completing multi-hop forwarding through parallel data forwarding jobs; dynamically injecting link failure, link recovery, or algorithm switching events during simulation runtime to trigger link state database updates and shortest path first recalculation; displaying the running status of nodes and links in real time through a visual interface, and receiving externally input test data streams, debugging commands, and mode switching commands.

[0012] In some possible implementations, a globally unique integer ID is assigned to each node, including: collecting the names of all nodes, sorting them lexicographically, and assigning an integer ID to each node in a monotonically increasing manner; establishing a two-way mapping table from integer IDs to node names and from node names to node object references; and flattening the basic attributes of nodes and writing them into an unmanaged contiguous memory container.

[0013] In some possible implementations, before constructing the link-state database through protocol flooding simulation, all nodes in the topology are sorted, and the successive access and neighbor establishment process of each node is simulated according to the sorting results.

[0014] In some possible implementations, parallel arrival detection includes: triggering a multi-threaded parallel computing job within each simulation main frame loop to concurrently check whether the preset arrival frame of all in-transit messages in the buffer message pool is equal to the current global simulation frame; for messages determined to have arrived, using lock-free concurrent writing technology to push their underlying data index into the global shared index list; after the parallel detection job is completed, uniformly reading the global shared index list, instantiating the arriving message into an upper-layer logical message object, and delivering it to the target node.

[0015] In some possible implementations, the shortest path first computation scheduling adopts a frame-based collaborative scheduling mechanism, including: embedding a load counter in the loop logic of the shortest path first computation job, the load counter being used to quantify the logical operation scale of the current algorithm; after the asynchronous computation task is completed, dividing the accumulated total load value by a preset computing power scaling factor to convert the computational complexity into the corresponding number of simulation clock frames; suspending the immediate write-back of the computation results, introducing a virtual waiting period equal to the number of simulation clock frames, and writing the newly calculated routing table into centralized storage and making it effective after the waiting period ends.

[0016] Thirdly, embodiments of this application provide a computer-readable storage medium including computer-readable instructions that, when read and executed by a computer, cause the computer to perform the method as described in any of the first aspects.

[0017] Fourthly, embodiments of this application provide a computing device, including a processor and a memory, wherein the memory stores computer program instructions, which, when executed by the processor, perform the method as described in any of the first aspects.

[0018] Fifthly, embodiments of this application provide a product comprising a computer program that, when the computer program product is run on a processor, causes the processor to perform the method as described in any of the first aspects. Attached Figure Description

[0019] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a schematic diagram of the architecture of a visual routing simulation verification platform provided in an embodiment of this application;

[0021] Figure 2 This is a panoramic schematic diagram of a visual routing simulation verification platform provided in an embodiment of this application;

[0022] Figure 3 This is a flowchart illustrating a routing simulation method provided in an embodiment of this application;

[0023] Figure 4 This is a schematic diagram of a parallel message detection mechanism provided in an embodiment of this application;

[0024] Figure 5 This is a schematic diagram illustrating the visualization and interaction of node information provided in an embodiment of this application;

[0025] Figure 6 This is a visual schematic diagram of link transmission provided in an embodiment of this application;

[0026] Figure 7 This is a schematic diagram of a fault domain algorithm provided in an embodiment of this application. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, 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, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0028] In this article, the term "and / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. The symbol " / " in this article indicates that the related objects are in an "or" relationship; for example, A / B means A or B.

[0029] The terms "first" and "second," etc., used in the specification and claims herein are used to distinguish different objects, not to describe a specific order of objects. For example, "first response message" and "second response message," etc., are used to distinguish different response messages, not to describe a specific order of response messages.

[0030] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0031] In the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more, for example, multiple processing units means two or more processing units, multiple elements means two or more elements, etc.

[0032] To facilitate understanding of the embodiments of this application, the following will provide further explanation and description with reference to the accompanying drawings and specific embodiments. These embodiments do not constitute a limitation on the embodiments of the present invention.

[0033] While traditional network simulation tools such as NS-3 and software routing protocol stacks like FRR are powerful, they suffer from fundamental shortcomings in usability and interactivity. Traditional simulation processes are like black boxes, unable to visually observe how data packets are forwarded step-by-step, nor can they dynamically modify the topology or intervene in the route convergence process. Debugging relies on command lines and text logs, which is highly inefficient. Core data such as routing tables and link-state databases cannot be viewed in a unified graphical interface. Researchers need to manually enter commands or parse log files, making intuitive observation impossible. Simulating large-scale networks usually requires sacrificing visualization, while achieving visualization often lacks support for large-scale concurrent computation.

[0034] In view of this, this application provides a visual routing simulation verification platform based on the Unity engine. It achieves network topology drawing and router simulation by overriding the editor node graph drawing base class provided by the NodeCanvas plugin. This application leverages the powerful real-time visualization capabilities and underlying high-performance computing capabilities of the Unity game engine (through technologies such as Burst, Job System, and Compute Shader) to construct an interactive simulation platform that can both visualize data packet flow and support large-scale network parallel computing.

[0035] Unity is a cross-platform, comprehensive development engine and visual runtime environment widely used for interactive development of complex logic and system-level simulation. Its core architecture employs a component-based architecture. In this system, all basic physical or logical entities are abstracted into generic objects (GameObjects). Developers can flexibly assign specific attributes, states, and behavioral logic to these generic objects by attaching different data or functional components. This highly decoupled design paradigm makes the construction process of complex systems (such as network topologies containing large-scale heterogeneous nodes and complex communication links) highly modular and reusable. In terms of runtime mechanisms, the Unity engine relies on a frame-cycle-based event-driven model and strict script lifecycle management. Its underlying execution engine governs the initialization of all attached components, state updates at fixed frequencies or frame rates, and the triggering and callback of specific events. This mechanism provides a unified and precise timing benchmark for the logical evolution of complex systems, the scheduling of concurrent tasks, and the synchronization of the overall state. Furthermore, the Unity engine includes a highly integrated visual editor environment. Unlike the "compile-run" black-box mode of traditional plain text development tools, this editor maintains a high degree of interactivity even during system runtime. It can parse and display the hierarchical relationships of objects within a unified interface, allowing developers to track object changes in real time, dynamically inject parameters, or intervene in the execution flow during program execution. This WYSIWYG characteristic at the underlying mechanism provides solid system-level support for breaking the closed nature of traditional pure logic simulation and achieving real-time visualization and intuitive viewing of the underlying runtime status.

[0036] In the embodiments of this application, the plugins used include Odin Serializer, NodeCanvas, Burst, and Compute Shader.

[0037] Odin Serializer is an editor extension framework designed for complex data structures. Unity's native data display mechanism has limitations when handling multi-layered nested structures, dictionary sets (such as routing tables), and polymorphic objects, making it difficult to directly present complex underlying runtime data within the editor interface. In network simulation, network topology nodes and links typically involve structured protocol messages, dynamic routing states, and multi-dimensional attribute sets. Odin Serializer extends the underlying data parsing and interface rendering logic, enabling deeply nested network node attributes and link data to be mapped in real-time within the visual editor. This mechanism provides simulation systems with an intuitive runtime monitoring tool, allowing researchers to accurately view and monitor the real-time underlying data status of each node and logical edge during network simulations.

[0038] NodeCanvas is a visual node editing framework based on the Unity engine. Its core module (CanvasCore) provides a general graph operation framework, including basic underlying functions such as canvas rendering, node definition, and connection management. Traditionally, this framework is often used to build pre-defined logical graphs such as behavior trees or state machines. However, in its architectural design, CanvasCore possesses high object-oriented extensibility, allowing developers to completely break away from the aforementioned pre-defined logical models and deeply rewrite the interaction rules of node entities and connections on top of the general node graph framework. By inheriting and overriding its core classes, developers can customize general graph nodes as specific physical or logical network devices (such as routers) and reconstruct the connections between nodes into communication links with specific underlying data structures and transmission mechanisms. This flexibility based on the graph structure makes it possible to directly build, render, and manage highly customized network topology models in the visual editor, providing a fundamental framework for visualizing complex network states, rewriting data transmission logic, and providing intuitive interaction in the simulation process.

[0039] Burst is a low-level optimizing compiler based on the LLVM backend, designed to pre-compile specific intermediate language code into highly optimized native machine instructions. When handling complex system simulations, high-frequency logic operations and massive data flows at the lower levels often generate significant computational overhead. Traditional execution environments are easily limited by computation scheduling overhead and discrete memory access latency when facing intensive computation, leading to decreased system execution efficiency. The Burst compiler can accelerate compilation at the hardware level by applying low-level register-level optimization techniques such as Single Instruction Multiple Data (SIMD) for intensive data operations and loop structures. This low-level compilation mechanism effectively reduces instruction execution latency in large-scale data processing, providing crucial low-level performance support for computationally intensive tasks such as processing massive concurrent data and solving complex logic.

[0040] A Compute Shader is a program that runs directly on a Graphics Processing Unit (GPU) and is specifically designed to perform general-purpose computing tasks (GPGPU) unrelated to graphics rendering. Unlike CPU-based computing architectures, GPUs have hundreds or thousands of highly parallel computing cores, and their architecture is naturally suited for concurrent processing of massive amounts of data. In simulations of complex systems, different computing modules exhibit significant differences in characteristics. For tasks with complex logical branches and deep data dependencies, acceleration is typically achieved by relying on the CPU and its underlying compiler optimization techniques (such as the aforementioned Burst compiler). However, for another type of task with fewer logical judgments but extremely large and independent numerical calculations (such as large-scale matrix operations or single-state synchronization of massive nodes), the total number of CPU physical cores limits the computational bottleneck that can be overcome by simply optimizing the CPU side. Compute Shaders can extract these high-density, low-logical-complexity computing tasks from the CPU's main thread and distribute them to the GPU pipeline for ultra-large-scale concurrent execution. This heterogeneous computing mechanism, which combines CPU and GPU, can fully utilize the maximum computing power of the underlying hardware, providing a more efficient hardware-level acceleration solution than pure CPU compilation and optimization for specific types of time-consuming computing modules in the simulation system.

[0041] Furthermore, since the underlying node graph framework (such as NodeCanvas) natively provides three abstract base classes—Graph, Node, and Connection—it is primarily designed for general directed graph scenarios and does not inherently possess network topology semantics. Therefore, the visual routing simulation verification platform provided in this application first constructs a model that aligns the general capabilities of the underlying node graph framework to the network simulation domain, including: a global topology graph model, an abstract network node model, router node implementations, and a network link model.

[0042] The global topology graph model is an extension of the underlying Graph base class. By overriding the internal node type constraints, it is specifically designed to host network nodes. This model also serves as the central authority for managing globally unique identifiers (IDs). Compared to the native general-purpose Graph, it adds a dynamic registration mechanism for network nodes and an initialization entry point for connecting to the global management system.

[0043] The abstract network node model extends the underlying Node base class, defining common basic capabilities for all network devices, including unlimited incoming and outgoing connections, symmetric connections, and other network characteristics. It also deeply integrates with the Inspector's field rendering pipeline to enable visual configuration of attributes. By overriding the underlying framework's lifecycle callback interfaces, this model standardizes the protocol initialization and memory cleanup logic for specific network nodes during topology operation and shutdown phases.

[0044] The router node implementation, as a concrete instantiation of the abstract network node model, is a proprietary network device implementation of the current platform. At the presentation layer, this node holds its own message buffer queue, Link State Database (LSDB) view, and routing table view. When centralized routing mode is enabled, its actual underlying computational data is centrally stored in a native unmanaged memory container of the global management system; the node itself is only responsible for synchronizing and displaying its status through the Inspector panel at the end of the simulation frame.

[0045] The network link model extends the underlying Connection base class, encapsulating core network attributes such as link cost, bandwidth capacity, and real-time traffic. This model provides control interfaces for fault injection and link recovery; when sending messages between network nodes, it can synchronously submit message animation requests to a visual priority queue.

[0046] For example, Figure 1 This diagram illustrates the architecture of a visual routing simulation verification platform provided in an embodiment of this application. Figure 1 As shown, the platform includes a three-layer decoupled architecture, comprising a visualization and interaction layer, a centralized management layer, and a Burst parallel computing layer.

[0047] The visualization and interaction layer serves as a graphical display and runtime interactive interface for network topology built upon the Unity editor, Odin serialization framework, and NodeCanvas node graph framework.

[0048] Please refer to Figure 1 The visualization and interaction layer includes the NodeCanvas 2D topology canvas, Inspector real-time status fields, a global control panel, and a visual message priority queue. The NodeCanvas 2D topology canvas, based on the NodeCanvas node graph framework, provides a graphical editing and display environment for network topology. Researchers can intuitively create and delete network nodes (routers) and communication links on the 2D canvas, and construct complex network topologies through drag-and-drop, point-and-click, and other interactive methods. The canvas supports color coding and animation rendering of nodes and links; for example, it can dynamically change the connection color based on the real-time load of the link, or present different color schemes based on the fault domain to which a node belongs, making the network operating status immediately clear.

[0049] The Inspector's real-time status fields utilize the Odin Serializer framework and Unity's underlying reflection mechanism to automatically parse and map complex underlying routing state data into a clearly structured, hierarchical, interactive view on the inspector panel. When researchers select any node or link in the topology canvas, the Inspector panel synchronously displays the entity's real-time data frame-by-frame, including the router's Link State Database (LSDB), routing table, message queue status, and link bandwidth, cost, and current traffic. Researchers can directly observe the detailed operational status of the network within the editor interface without needing to consult underlying logs.

[0050] The global control panel is an independently mounted unified control component, serving as a graphical operational hub between the underlying simulation system and researchers. It centralizes lifecycle control and core scheduling methods that were previously scattered across various underlying modules, allowing for hot-switching during runtime. This enables researchers to dynamically switch routing protocol algorithms, modify link costs, and adjust simulation speeds without interrupting the simulation. It also allows for real-time injection of test flows; without pre-writing traffic scripts, source nodes, destination nodes, and packet characteristics can be entered on the panel, instantly injecting test data streams into the network. Furthermore, it supports breakpoint debugging, allowing the simulation engine to be suspended at any time to enter a packet-by-packet micro-debugging mode.

[0051] The visual message priority queue is responsible for the visual animation rendering of network packets. When a node sends a message, the system calculates the number of transmission waiting frames based on the physical attributes of the link (bandwidth, cost) and the data payload of the message, and generates an arrival frame timestamp. Within the time window during which the packet waits to be transmitted, the visual message priority queue schedules corresponding flight animations, displaying color changes as the node's status changes. Simultaneously, this module works in conjunction with the link's real-time traffic tracking function, updating the total amount of data in transit on the link when packets are sent and when they arrive, driving the dynamic changes in link color and providing researchers with intuitive situational awareness.

[0052] The centralized management layer connects the visualization interaction layer and the Burst parallel computing layer. As the sole data source, it includes a topology management module, a message scheduling module, and a router state management module. It is used to achieve unified registration and global identifier allocation for network nodes, centralized message submission and batch delivery scheduling, and centralized storage and computational coordination of router state data across the entire network. Specifically, the centralized management layer, as the core hub for state synchronization, consists of three global management modules. The topology management module is responsible for the unified registration and global unique identifier (ID) allocation of nodes in the network topology; the message scheduling module has a built-in buffer message pool and is responsible for centralized message submission and batch delivery scheduling; the router state management module is responsible for centrally storing the LSDB, routing tables, and forwarding plane information of all routers in the entire network, and coordinating the scheduling of SPF computational jobs. The centralized management layer is the sole data source for the entire simulation platform; all router node state reads and writes are processed uniformly here.

[0053] Please continue to refer to this. Figure 1 The centralized management layer includes a topology management module, a message scheduling module, and a router state management module. The topology management module is responsible for the unified registration and lifecycle management of all nodes in the network topology, internally handling node registration and ID allocation. When the simulation enters the preprocessing stage, all network nodes must initiate a registration request to this module. The module assigns a globally unique integer ID to each node using a monotonically increasing method and internally establishes and maintains a bidirectional mapping table between "integer ID to node name" and "node name to node object reference." All subsequent core management modules and high-frequency computation jobs on the platform uniformly use this integer ID to index nodes, completely abandoning string addressing. Furthermore, ID allocation strictly follows the node name sorting, ensuring that the same network topology generates completely consistent ID mapping relationships in different editor sessions, guaranteeing stable reuse of serialized data across sessions.

[0054] The message scheduling module is responsible for the centralized management and timing scheduling of network packets, including a buffer message pool and batch delivery. All packets awaiting forwarding are first submitted to the buffer message pool. The module combines the physical attributes of the link (bandwidth, cost) with the actual data payload of the message, calculates the theoretical physical latency through a time-consuming fitting mechanism, converts it into a specific number of transmission waiting frames, and adds it to the current global frame to generate the arrival frame timestamp for the packet. In each simulation frame, the message scheduling module triggers a low-level parallel arrival detection job, batch checks the timestamps of all packets in transit in the buffer pool, collects the indexes of arrived packets, instantiates them uniformly into upper-layer logical message objects, and delivers them to the corresponding target nodes. This mechanism achieves efficient decoupling between the timing delivery of messages and the upper-layer protocol processing logic.

[0055] The router state management module stores core operational data for all routers in the network, including the Link State Database (LSDB), routing tables, and forwarding plane information, and coordinates the shortest path first (SPF) computation. This module employs a Data-Oriented Design (DOD) approach, completely flattening the attributes and states of all network nodes and centrally managing them in a contiguous, unmanaged memory container (Native Container). Specifically, the LSDB stores data using integer ID pairs of the nodes at both ends of a link as keys; the routing table stores data using (router ID, destination network ID) pairs as keys; and the forwarding plane maintains the message queue state of each node. When the LSDB is updated, this module schedules SPF computations, triggering a recalculation of the routing tables on the relevant routers. This centralized, flattened storage architecture eliminates the overhead of cross-object access, enabling high-frequency computations at the lower levels to efficiently access data in a lock-free, concurrent manner.

[0056] The Burst parallel computing layer employs the Unity C# Job System and the Burst compiler. It uses unmanaged, contiguous memory containers to store hot path data, accelerating multi-threaded parallel computation of core high-frequency jobs and writing the results back to the centralized management layer. Specifically, the Burst parallel computing layer serves as the underlying layer of the visual routing simulation verification platform, using the Unity C# Job System as its underlying scheduling framework. To ensure high-density network simulation computation efficiency, this layer fully utilizes unmanaged, contiguous memory containers to store all hot path data, avoiding GC allocation within the simulation main frame loop. The platform's core high-frequency jobs (such as parallel arrival detection jobs, parallel data forwarding jobs, and SPF computation job groups) are converted into native SIMD code using Burst compilation technology, executed concurrently on multi-core processors, and finally written back to the management layer through the job scheduling mechanism.

[0057] Please refer to Figure 1 The Burst parallel computing layer includes a parallel arrival detection job, a parallel data forwarding job, and an SPF calculation job. The parallel arrival detection job, triggered by the message scheduling module within each simulation main frame loop, is a multi-threaded parallel computing job. It performs high-concurrency arrival status timing determination for all in-transit network packets stored in the active message pool, i.e., strictly comparing the preset arrival frame of each packet with the current global simulation frame. For messages determined to have arrived, each parallel computing unit uses lock-free concurrent writing technology to efficiently and safely push its underlying data index into a globally shared index list. After the parallel detection job completes execution across multiple cores and synchronizes its status with the main thread, the system's scheduling backbone will uniformly read the shared index list, extract the underlying data structure of the arriving packets, and batch convert them into logical message objects that can be directly manipulated by the visualization interaction layer for subsequent processing.

[0058] The parallel data forwarding job is responsible for handling the forwarding logic of data packets in the network. Utilizing the flat, contiguous memory storage provided by the centralized management layer, this job can traverse all messages that need to be forwarded in parallel, quickly look up the next hop in the global routing table based on the integer ID of the target node in the packet, call the message sending interface to generate a new forwarding packet, and submit it to the buffer message pool.

[0059] SPF computation jobs are used when network topology changes (such as link failures or link recovery) cause LSDB updates. The system schedules a group of SPF computation jobs. These jobs utilize the Burst compiler to process the centrally stored LSDB in parallel, with each job responsible for SPF computation on one or more routers. Since the LSDB views of all routers are stored uniformly in the centralized management module and accessed in read-only mode, these computation jobs can be executed completely in parallel and lock-free. For large-scale matrix operation tasks (such as batch computation of the shortest path tree for the entire network), the platform can also combine ComputeShader technology to strip computation tasks from the CPU main thread and distribute them to the GPU for ultra-large-scale concurrent execution. All SPF computation results (new routing tables) are written back to the router state management module after computation, and their effective timing is controlled by a frame-based collaborative scheduling mechanism to simulate the processing latency caused by topology size and computing power limitations in real network devices.

[0060] The above is an introduction to the visual routing simulation verification platform provided in the embodiments of this application. Figure 1 The platform architecture is illustrated. Figure 2 This displays a panoramic view of the platform. Please refer to it. Figure 2 The main part of the platform's panoramic view, the Canvas, represents the network topology, while the WebGraphOperator on the right is the control panel, allowing real-time modification of various overall network control items, such as generating link messages according to specified start and end points, and changing the simulated algorithm. Based on this visual routing simulation verification platform, this application embodiment also provides a routing simulation method. For example, Figure 3 A flowchart illustrating a routing simulation method provided in an embodiment of this application is shown. Figure 3 As shown, the routing simulation method may include the following steps:

[0061] S31: Construct the network topology, create router nodes and communication links, assign a globally unique integer ID to each node, and establish a two-way mapping relationship between the integer ID and the node name and node object.

[0062] In this embodiment, the network topology is first constructed using the NodeCanvas node graph framework in the Unity editor. Researchers use the NodeCanvas two-dimensional topology canvas and interactive operations such as dragging and clicking to create router nodes and communication links. Each router node, as a concrete instantiation of the abstract network node model, possesses network characteristics such as unlimited incoming and outgoing connections and symmetrical connections. Each communication link, as an instantiation of the network link model, encapsulates core network attributes such as link cost, bandwidth capacity, and real-time traffic, and provides control interfaces for fault injection and link recovery. After all nodes are created, the global topology graph model, as the core component of the topology management module, takes over all created nodes and links and initiates a globally unique identifier allocation mechanism.

[0063] Because the underlying two-dimensional topology graph framework (such as NodeCanvas) natively uses node name strings as identifiers, this mechanism cannot directly meet the fixed-length data addressing requirements of unmanaged memory containers (native containers) in the underlying high-performance parallel jobs (such as Burst Job). Therefore, this application's embodiment superimposes a globally unique integer identifier (ID) allocation mechanism on top of the existing string naming system. Specifically, during the preprocessing stage before the simulation system enters formal operation, all network nodes must uniformly initiate a registration request to the global topology graph model. The global topology graph model assigns an integer ID to each registered node in a monotonically increasing manner and establishes and maintains a bidirectional mapping table within the system, connecting integer IDs to node names and node names to node object references. All subsequent core management modules and high-frequency computing jobs on the platform uniformly use this integer ID to index nodes, completely abandoning string addressing. This converts all key-value pairs of the underlying unmanaged memory containers into fixed-length integers, not only meeting the unmanaged data constraints of the concurrent compilation job but also eliminating the risk of data inconsistency caused by string identifier parsing during cross-system calls. Furthermore, during ID allocation, the system sorts and assigns IDs according to the numerical or lexicographical order of the node names. This ensures that the same network topology generates completely consistent ID mapping relationships across different engine editor sessions, guaranteeing stable reuse of topology state serialization data across sessions. The global topology graph model first collects the name strings of all network nodes, sorts them lexicographically, and then assigns an integer identifier to each sorted node in a monotonically increasing manner. This integer ID serves as the node's unique identity credential in all subsequent computational processes.

[0064] After allocation, the global topology graph model establishes and maintains a three-layer bidirectional mapping relationship within the system: the first layer is a mapping from integer IDs to node names, used to support underlying computation jobs in reversing node identifiers based on IDs; the second layer is a mapping from node names to node object references, used to support the upper-level visual interaction layer in quickly locating the corresponding node object based on user clicks; the third layer is an implicit association between node object references and integer IDs, ensuring that the identification information in the three dimensions remains consistent. After completing the identifier allocation and mapping relationship construction, the system completely flattens all the basic attributes of all nodes, including node integer IDs, node names, node position coordinates in the topology canvas, node in-degree and out-degree information, and connection relationships between nodes, and writes them into the underlying unmanaged contiguous memory containers. These unmanaged containers exist in the form of NativeArray or Native HashMap, and their keys and values ​​all use fixed-length integers, completely abandoning the string addressing mechanism. At the same time, the system establishes and maintains a direct mapping relationship between integer IDs and underlying unmanaged container indexes, enabling all subsequent core management modules and high-frequency computing jobs to directly access the underlying data of the corresponding nodes through integer IDs. This can eliminate the risk of data inconsistency and performance overhead caused by string identifier parsing during cross-system calls.

[0065] S32: Completes the construction of LSDB and SPF calculation through protocol flooding simulation, generates the entire network routing table, and centrally stores the LSDB, routing table and forwarding plane information of all routers in the underlying unmanaged contiguous memory container.

[0066] In this embodiment, the system can be triggered via the quick network setup button on the global control panel. This simulates the protocol flooding process during the initial network topology establishment in advance during the editor stage, without consuming computational resources from the simulation main frame loop. After quick network setup is initiated, the system first simulates the process of each router gradually connecting to the network. Each newly connected router establishes communication connections with its existing neighboring routers and begins batch exchanging Link State Advertisement (LSA) messages. Within the framework of the Link State Routing protocol, each router encapsulates the state information of its directly connected links, including link cost, bandwidth capacity, and peer router identifier, into a LSA message and floods it to all other routers in the network, simulating different network setup behaviors according to different protocols. For example, in BGP-SPF, flooding sequentially establishes RIB-IN, Loc-RIB, RIB-OUT, and LSDB, and performs SPF routing table calculations. This data, calculated at the beginning of network setup, is immediately serialized and permanently stored in the network topology, ready for direct use during algorithm simulation.

[0067] Due to the large number of routers in the network, to fully leverage the advantages of parallel computing, all routers are indexed by ID. This includes the node's basic transmission attributes, a global link-state database with native compatibility and equivalent multipath support, and a global routing table for coordinating shortest path first (SLF) addressing. All of these are uniformly aggregated and stored in a contiguous unmanaged memory container at the underlying level. The routing table's behavior, such as message processing, SLF procedures, and specific algorithm implementations, is also based on this centralized processor. This centralized architecture completely eliminates the overhead of object traversal and cross-domain addressing, enabling the coordinated scheduling of large-scale multi-threaded parallel computing jobs within a single simulation main frame loop. During subsequent algorithm simulations, this LSDB and routing table data, stored in serialized Asset files, is read and loaded into the unmanaged contiguous memory container for direct use by the underlying parallel computing jobs.

[0068] S33: The Unity frame loop is used as the simulation clock driver. Within each simulation frame, parallel arrival detection, arrival message delivery, protocol processing, message sending, and SPF calculation scheduling are executed sequentially.

[0069] In this embodiment, the system uses the native frame loop of the Unity engine as the driving reference for the simulation clock, and uses frame count instead of absolute time as the unit of measurement for simulation time. Since the frame rate of the Unity engine may fluctuate due to scene complexity and computational load, using frame count as the timing basis can avoid simulation timing deviations caused by frame rate changes, and has universal accuracy. The entire simulation main loop progresses in discrete frame steps, with each simulation frame representing a fixed time step unit. Within this frame, the system centrally processes all events that should occur at that moment. At the beginning of each simulation frame, the system first performs parallel arrival detection. For an example, please refer to... Figure 4 The message scheduling module triggers a parallel arrival detection job in the Burst parallel computing layer. This job scans all in-transit network packets stored in the buffer message pool in a multi-threaded parallel manner. Each packet is assigned a preset arrival frame timestamp upon transmission, which is equal to the global frame number at the time of transmission plus the number of transmission waiting frames calculated based on link attributes and packet payload. The core task of the parallel arrival detection job is to rigorously compare the preset arrival frame of each packet with the numerical relationship of the current global simulation frame. This job uses lock-free concurrency technology, with multiple computing cores simultaneously traversing different memory regions and performing independent timing determinations on their respective subsets of packets. When the preset arrival frame of a packet equals the current global frame, the packet is considered to have arrived, and its underlying data index is safely pushed into a globally shared list of arrived packet indexes through atomic operations. Since the arrival determination of all packets is independent and there is no data dependency, the parallel detection process can be completed efficiently with near-linear speedup.

[0070] After the parallel arrival detection job completes execution and synchronizes with the main thread, the system enters the arrival message delivery phase. The system scheduling backbone uniformly reads the aforementioned globally shared index list and traverses each message index stored therein. Based on the index, it extracts the complete structure data of the message from the underlying unmanaged contiguous memory container. This structure is designed with full value types and includes fields such as the sending node integer ID, the receiving node integer ID, the message type, the sequence number, and the payload length. The system instantiates these underlying data structures into upper-layer logical message objects that can be directly manipulated by the visual interaction layer and the protocol state machine, establishing the association between managed objects and unmanaged data. Subsequently, the system calls the unified message receiving entry of the target router to deliver the instantiated message objects to the corresponding target node for further processing. After delivery, the system safely removes the delivered underlying message structure from the active message pool, releasing the unmanaged memory space it occupies.

[0071] After message delivery is complete, the system enters the protocol processing phase. Upon receiving the message object, the target router automatically routes it to the corresponding processing logic based on the message type field. Taking the link-state routing protocol as an example, within the link-state routing protocol framework, message types are mainly divided into three categories: link-state advertisement messages, data messages, and fault notification messages. For link-state advertisement messages, the router first checks the sequence number carried in the message against the sequence number of the entry already stored in its local link-state database. If the sequence number of the new message is larger, the corresponding entry in the link-state database is updated, and the database is marked as changed; if the sequence number is smaller or equal, the message is discarded. For data messages, the router looks up the next-hop address in its local routing table, constructs a new forwarding message, and submits it to the sending queue. For fault notification messages, the router updates the neighbor state information and triggers the corresponding fault handling callback. All protocol processing logic is executed in the router's upper-layer code, completely decoupled from the underlying computational operations. New messages to be forwarded may be generated during the protocol processing phase, and the system subsequently sends these messages.

[0072] When the protocol processing phase causes an update to the link-state database of any router, the system enters the SPF computation scheduling phase after the message sending phase. The router state management module collects all changed link-state database entries and determines the set of affected routers. For each router in this set, the system schedules an SPF computation job to be executed at the Burst parallel computing layer. Unlike the traditional immediate computation mode, this embodiment introduces a frame-based cooperative scheduling mechanism. When the SPF computation job is executed asynchronously at the lower level, given that the underlying pre-compilation acceleration technology can quickly complete the network routing algorithm calculation, directly applying its instantaneously returned results in the simulation main loop would cause a deviation between the simulation timeline and the physical reality. Therefore, a load counter is embedded in the loop logic of the underlying asynchronous computation job. This counter is synchronously accumulated each time the algorithm traverses a topology node or performs a logical iteration to quantify the logical operation scale of the current algorithm. After the asynchronous computation task is completed, the system divides the accumulated total load value by a preset computing power scaling factor to convert the computational complexity into the corresponding number of simulation clock frames. Subsequently, the centralized management layer suspends the immediate write-back of the calculation results and introduces a virtual waiting period equal to the number of frames mentioned above. Only after the waiting period ends is the newly calculated routing table written to centralized storage and made effective. This mechanism, which converts logical iterations into time-series frame delays, visualizes the asynchronous computation process time. Simultaneously, at the simulation logic level, it fits the processing delays of real network devices due to topology scale and computing power limitations, ensuring the validity of the simulation results in the time dimension. In addition to node computation time, the platform also employs a framing mechanism to simulate the transmission latency of network packets on the link. When a node sends a message, the system combines the physical attributes of the current link (such as bandwidth capacity and link cost) with the actual data payload of the message to calculate the theoretical physical latency of the interaction. This latency is then converted into a specific number of transmission waiting frames, superimposed on the current global frame, and generates the arrival frame timestamp of the message. This, combined with the global message management mentioned earlier, simulates the transmission latency effect. During the waiting period before the global frame reaches this timestamp, the presentation layer utilizes this time difference to synchronously render the flight animation of the packet moving along the link topology. For large-scale matrix operation-type SPF computation tasks, the system can also combine Compute Shader technology to further decouple the computation tasks into the ultra-large-scale parallel pipeline of the graphics processor, achieving more efficient hardware-level acceleration than pure CPU compilation optimization.

[0073] S34: The link attributes and message payload are converted into the number of transmission waiting frames through the time consumption fitting mechanism, the arrival frame timestamp is generated, the message is stored in the buffer message pool, and multi-hop forwarding is completed through parallel data forwarding jobs.

[0074] In this embodiment, the system achieves accurate mapping between the simulated time domain and the physical time domain through a time-consumption fitting mechanism, and completes high-throughput forwarding of large-scale packets using parallel computing. When any router node needs to send a packet, the system first enters the time-consumption fitting calculation stage. The message scheduling module reads the physical attributes of the communication link through which the packet passes, including the link's bandwidth capacity and link cost, and also reads the data payload size of the packet itself. The core objective of the time-consumption fitting mechanism is to accurately convert the transmission delay in the real physical network into the frame step size of the simulated clock. Specifically, this mechanism decomposes the transmission delay into two main components. The first component is the serialization delay, which is the time required for the packet to be completely pushed onto the link from the first bit to the last bit. This component is determined by the packet payload size and the link bandwidth capacity. The larger the payload or the smaller the bandwidth, the longer the serialization delay, and the corresponding increase in the number of frames. The second component is propagation delay, which is the time required for a signal to travel from one end of a link to the other on the physical medium. This component is obtained by linearly mapping the link cost. The system pre-establishes a mapping relationship between link cost and frame delay, ensuring that link cost truly affects the transmission timing of packets; the higher the link cost, the longer the propagation delay. Furthermore, for packets that are processed locally by the router before being forwarded, the system also incorporates the router's logical computation into the time consumption fitting process. By embedding a load counter in the loop logic of the underlying asynchronous computation job, the system quantifies the scale of logical operations required by the router to perform routing table lookups, policy filtering, and other operations. The accumulated total load value is divided by a preset computing power scaling factor to convert it into the corresponding processing time frame count. Adding all the delay components together yields the complete transmission waiting frame count.

[0075] After completing the time consumption fitting calculation, the system generates the arrival frame timestamp for the message. The arrival frame timestamp is calculated by adding the aforementioned transmission waiting frame number to the current global simulation frame number. This timestamp identifies the theoretical simulation time when the message, originating from the sending router, passes through the link transmission and intermediate node processing, and finally arrives at the target router receiving end. The system then encapsulates the message into a full-value type structure. This structure is designed to strictly adhere to the storage constraints of unmanaged memory containers; all fields are value types and do not contain any heap memory references. Specifically, the identifiers of the sending and receiving nodes use integers instead of strings, boolean fields are replaced with single-byte integers to avoid memory alignment padding, and the target set for multi-target forwarding is not nested within the structure but allocated as a continuous interval in a globally flattened integer list. The structure only records the starting index and length. The path vector required for AS_PATH loop prevention is also stored in a separate Native list using a flattened storage method. The message structure includes a built-in sequence number field that records the index interval for subsequent version comparison and old message discarding decisions. The encapsulated message structure is stored in the underlying unmanaged contiguous memory container of the buffer message pool. This container exists in the form of a Native Array or a Native Queue, supporting efficient batch read and write operations. Simultaneously with storing the message in the buffer message pool, the system submits a flight animation rendering request to the visualization message priority queue based on the difference between the arrival frame timestamp and the current frame number. The visualization message priority queue is sorted according to message priority and submission time, moving precisely to the target node position at the simulation frame corresponding to the arrival frame timestamp, thus visualizing the message transmission process. Within each simulation frame, the centralized management layer checks all messages stored in the buffer message pool, identifying those that have arrived at the current node but have not yet reached their final destination. The parallel data forwarding job traverses these messages to be forwarded in a multi-threaded, parallel manner. For each message to be forwarded, the job performs a lookup operation in the global routing table based on the target node integer ID carried in the message. The global routing table is stored in an unmanaged contiguous memory container within a centralized management layer. Keys are composite pairs of the source router's integer ID and the destination network's integer ID. Each routing entry is stored contiguously in a compact structure. Because the routing table uses integer IDs as lookup keys and the data is stored in contiguous memory, lookup operations can be completed in O(1) or near-O(1) time complexity, without any string parsing or hash calculations. The found routing entry contains the integer ID of the next-hop router and a reference to the outgoing interface link.

[0076] After determining the next hop, the parallel data forwarding job calls the message sending interface, using the current node as the sender, the found next-hop node as the receiver, and the data payload of the original message as the content, to generate a new forwarding message. The processing flow of this forwarding message is completely consistent with the aforementioned sending flow, including time consumption fitting calculation, arrival frame timestamp generation, and storage in the buffer message pool. After the original message has completed forwarding processing, it is marked as processed and removed from the buffer message pool. The entire process is carried out in unmanaged memory, all data access is directly addressed through integer IDs, and multiple forwarding jobs execute concurrently on different computing cores without interference. Utilizing the underlying optimizations of the Burst compiler, the intermediate language code is pre-compiled into highly optimized native machine instructions, and register-level parallel acceleration is applied using single-instruction multiple-data technology, thereby enabling the simultaneous forwarding of hundreds or thousands of messages within a single simulation frame.

[0077] In scenarios supporting equal-cost multipath routing, the global routing table may store multiple next hops with equal costs. In this case, the parallel data forwarding job selects one of these equal-cost next hops as the actual forwarding path based on the flow identifier carried in the packet header or using a hash-balanced algorithm. If the link corresponding to an equal-cost next hop is in a fault-blocked state, the system automatically removes that link from the candidate set and selects the next available equal-cost path, achieving fast rerouting at the flow level.

[0078] S35: Dynamically inject link failure, link recovery, or algorithm switching events during simulation runtime to trigger LSDB updates and SPF recalculation.

[0079] In this embodiment, the system supports dynamically injecting various network events during simulation to verify the convergence performance and fault recovery capabilities of routing protocols under topology changes. Researchers can trigger events such as link failures, link recovery, or algorithm switching in real time without interrupting or restarting the running simulation process. The system responds to these events and automatically triggers updates to the link state database and recalculations of the shortest path first (SFP) algorithm. When researchers need to inject a link failure event through the global control panel, they first locate the network link model instance corresponding to that link. The link model maintains a fault status flag, which is false under normal conditions, indicating that the link is available. The system sets this flag to true, putting the link into a fault blocking state. During the link's fault blocking state, any packet transmission request passing through that link is directly intercepted by the link model at the underlying layer. The system checks the link's fault status flag at the sending interface; if the flag is true, it immediately returns a transmission failure result and marks the packet as invalid, preventing invalid data from entering the global scheduling queue at the source and avoiding packet black holes and invalid calculations caused by link interruptions.

[0080] After the fault status flag is updated, the system automatically triggers the link state change notification process. The link model sends a link interruption notification message to the router nodes connected to both ends of the link. This message is encapsulated in a standardized link state notification message format, containing information such as the link identifier, the identifiers of both ends of the node, and the timestamp of the fault occurrence. Upon receiving the notification message, the router nodes at both ends enter the protocol processing flow. Each router first checks the sequence number carried in the message against the sequence number of the corresponding entry in its local link state database. Since the notification message triggered by the fault event carries an incremented new sequence number, the router determines that the message is a valid update and then updates its local link state database, changing the validity flag of the link entry from true to false. Optionally, it also sets the link cost to infinity to indicate that the link is unavailable.

[0081] The injection process for link recovery events is essentially symmetrical to that for fault injection. Researchers select a faulty link on the control panel and click the "Recover" button. The system then resets the fault status flag of that link to false, indicating that the link is recoverable. Subsequently, the link model sends a link recovery notification message to both ends of the router. Upon receiving this message, the routers update their local link-state databases, changing the validity flag of the link entry from false to true and restoring the link cost to its original configuration value. This change in the link-state database triggers the SPF recalculation process again. The affected routers recalculate the optimal path, and the newly calculated shortest path tree may be reintegrated into the recovered link, achieving self-healing of the network topology.

[0082] The algorithm switching event is injected by researchers selecting different routing protocol algorithms during simulation execution via the algorithm selection drop-down menu in the global control panel. Subsequently, the system clears all in-transit protocol packets from the current buffer message pool, as these packets were generated based on the semantics of the old algorithm and may no longer be applicable to the new algorithm. The system retains the current network topology, including all nodes, links, and their attributes, but clears all link-state databases and routing tables. After the link-state database and routing tables generated by the new algorithm are written to centralized storage, the system resumes the main simulation loop, and subsequent packet transmission and forwarding are executed according to the routing rules of the new algorithm. The entire switching process is instantaneous at the user level, without interrupting or restarting the simulation process. Researchers can continuously compare the behavior of multiple algorithms under different network states on the same topology.

[0083] For scenarios supporting the coexistence of multiple routing strategies, the global control panel also allows researchers to dynamically modify the hyperparameters of specific algorithms, such as adjusting the maximum number of equivalent multipaths, modifying the calculation weight of link costs, and changing the fault detection timer. These parameter changes are automatically mapped to adjustable controls on the control panel through code feature tags. When researchers slide the slider or modify the value at runtime, the changes take effect immediately and are propagated to the underlying SPF calculation job, affecting the shortest path tree generation results of subsequent calculations.

[0084] S36: Displays the real-time operating status of nodes and links through a visual interface, and receives external input test data streams, debugging commands, and mode switching commands.

[0085] In this embodiment, to meet researchers' needs for dynamic intervention in the simulation process, the platform independently encapsulates a globally unified control component at the visualization interaction layer. Technically, this component, as an independently mounted control entity within the scene, utilizes the Facade Pattern architecture, serving as a unified interface between the underlying complex simulation system and external researchers. It centralizes the lifecycle control and core scheduling methods, originally scattered across various underlying modules such as topology management, message scheduling, and routing status, providing researchers with a graphical operational hub that allows them to control the overall situation without intervening in the underlying core logic. At the specific business interaction level, this globally unified control component abandons the hard-coded limitations of traditional simulation tools on fixed experimental procedures, exhibiting strong runtime intervention and dynamic expansion capabilities. For example, when researchers introduce a new network protocol algorithm into the platform, the control panel can directly expose the corresponding parameter configuration items and algorithm switching interfaces. Users can seamlessly switch between different routing strategies or algorithms in real time during the main simulation loop; related parameter changes are immediately applied to the underlying system without interrupting or restarting the current simulation process. The control panel also supports defining the overall execution mode of the network, such as large graph and small graph modes defined in the current platform. In small graph mode, the platform displays more precise effects and visuals to give researchers a clearer understanding of the network's operation; for example, each edge clearly shows the flow of traffic and the load. In large graph mode, which is often experimental, many visual effects are selectively sacrificed in pursuit of higher performance. Furthermore, the panel offers a high degree of freedom in testing and verifying network traffic behavior. Researchers do not need to pre-write static traffic scripts; they can dynamically fill in variables such as source nodes, target nodes, and packet characteristics during topology runtime, injecting test data streams into the network in real time. They can even suspend the underlying global time-driven engine at any time through the scheduling control interface on the panel, switching to a packet-by-packet micro-breakpoint debugging mode. This approach, which completely decouples the complex underlying parallel scheduling from the business algorithm layer and transforms it into an interactive control architecture with "runtime hot switching and real-time parameter binding," enables the platform to rapidly integrate new control modules with extremely low engineering coupling when facing the prototype verification and iterative expansion of various cutting-edge network algorithms. This completely breaks through the expansion bottleneck of traditional network simulation software (such as NS-3) that heavily relies on offline configuration. Please refer to [reference needed]. Figure 5 In the topology, all entities, including nodes and edges, have independent control panels. Selecting these panels during runtime allows you to view their data in real time. For example... Figure 5 The control panel of a router entity is shown, which includes routing tables and lsdb information. The routing tables are rendered using the Odin serializer, and their contents can be rendered in tabular form.

[0086] At the link and node visualization level, the system also provides customizable colors and animation capabilities. The platform deeply integrates the native state indication mechanism of the NodeCanvas framework and provides a fully overridden interface. Researchers can customize the visualization rules for node and edge colors according to different algorithms they are studying. For example, they can assign different color schemes to different fault domains in the network, or gradually change the color from green to red based on the real-time load rate of the link to intuitively reflect the degree of congestion. The system's built-in color-driven pipeline reads data such as link throughput and node convergence status from the centralized management layer in real time, automatically driving the dynamic changes in the color encoding of nodes and edges. When there is packet transmission on the link, as described above, the visualization message priority queue drives the graphic representing the packet to move along the link. Please refer to [reference needed]. Figure 6 When messages are generated in the network, the transmission status can be visually observed through colors and animations, including the cost and load of each edge, as well as information such as how many packets remain from each router to the specified destination. This information can be expanded by researchers themselves. Furthermore, Figure 7 An example of using this platform for dynamic fault domain algorithm simulation is also shown, such as... Figure 7 As shown, in this algorithm simulation, the researchers customized the color rules for the router and the edges. Figure 7 The algorithm uses red to represent faulty links and orange to represent fault domains, which clearly expresses the algorithm's effectiveness.

[0087] Regarding the dynamic injection of test data streams, the global control panel integrates an instant test stream injection function. Researchers can dynamically fill in the relevant parameters of the test data stream on the control panel without pre-writing static traffic scripts or interrupting the running simulation process. Specifically, researchers select an existing router as the sender in the source node selection box and another router as the receiver in the destination node selection box, filling in characteristic fields such as packet payload size, priority, and packet type. Optional settings include the number of packets and the sending rate. After completing the information, clicking the injection button immediately constructs test data packets based on these parameters and forwards them hop-by-hop to the destination node from the selected source node, according to the currently effective routing protocol algorithm and routing table content. Researchers can inject different test streams multiple times consecutively to compare the impact of different traffic characteristics on network performance on the same network topology, or to verify the scheduling effect of specific routing strategies on traffic between specific source and destination pairs.

[0088] For single-step debugging, the system provides micro-breakpoint debugging capabilities for verifying complex protocol behaviors. The global control panel integrates simulation execution control buttons, including modes such as run, pause, single-frame advance, and single-packet advance. When researchers click the pause button, the system suspends the underlying global time-driven engine, the main simulation loop stops automatically advancing, and the current simulation state is completely frozen. This includes all in-transit packets in the buffer message pool, the link-state databases and routing tables of each router, and the rendering state on the visualization canvas—all remain unchanged. In the paused state, researchers can click the single-frame advance button, and the system executes a complete simulation frame processing flow, including the aforementioned five stages: parallel arrival detection, arriving packet delivery, protocol processing, packet transmission, and SPF calculation and scheduling, before returning to the paused state. By continuously clicking the single-frame advance button, researchers can meticulously observe the evolution of the network state at the frame level and locate anomalies in protocol behavior.

[0089] Regarding performance mode switching, the system offers flexible operating mode selection to meet the varying needs of different experimental scenarios for display effects and simulation performance. Two operating modes are defined on the global control panel: small-graph mode and large-graph mode. In small-graph mode, the platform focuses on refined visualization. Each link in the topology canvas clearly displays the traffic flow animation, the link edges show the current load values ​​in real time, and each router node displays the count information of packets to be forwarded. The colors of nodes and edges are refreshed frequently based on real-time status. This mode is suitable for teaching demonstrations, protocol behavior demonstrations, and interactive debugging of small-scale networks, giving researchers a clearer and more intuitive understanding of the network's operational status. In large-graph mode, the platform prioritizes ultimate simulation performance. The system selectively abandons the aforementioned refined display effects, such as disabling packet flight animations, reducing the refresh frequency of node and edge colors, and hiding the real-time display of link load values, thereby freeing up more CPU and GPU computing resources for the underlying Burst parallel computing and SPF computing jobs. In this mode, the system can stably support lock-free concurrent forwarding determination and SPF routing calculation for the entire network routers within a single frame in a 100x100 ultra-large-scale network topology. It is suitable for large-scale network performance testing and routing convergence time statistics, primarily for experimental purposes. Switching between the two modes is achieved by modifying the configuration switch of the visualization rendering pipeline. The underlying computing module's operating logic remains completely unchanged during the switch, ensuring the consistency and reproducibility of simulation results.

[0090] The above is an introduction to the routing simulation method provided in the embodiments of this application. The NodeCanvas node graph drawing base class has undergone multi-level inheritance and logical extension, constructing a semantic network topology model that includes a global topology graph, abstract network nodes, specific routers, and bidirectional physical links. A globally unique identifier (ID) allocation and bidirectional mapping mechanism based on monotonically increasing integers has been designed, transforming the original string addressing into fixed-length integer addressing, thus establishing an efficient concurrent access path between topology nodes and the underlying unmanaged container. This method also combines the Odin Serializer serialization framework with the underlying reflection mechanism to automatically parse and map the complex underlying routing states (such as multi-layered RIB routing information bases and hash tables containing ECMP records of equal-cost multi-paths) into a clearly structured hierarchical interactive view on the inspection panel. Adopting a data-oriented design, the state of all network node attributes and the global routing table is completely flattened and centrally stored in a continuous unmanaged memory container at the underlying level, eliminating cross-object access overhead. By utilizing the Burst compiler and Compute Shader technology to accelerate the centralized contiguous memory in a multi-threaded parallel manner, lock-free concurrent forwarding determination and SPF path calculation of all routers in a single frame under a 100*100 ultra-large network topology were realized.

[0091] It is understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. Furthermore, in some possible implementations, each step in the above embodiments may be selectively executed according to actual circumstances; it may be partially or fully executed, without limitation here. All or part of any feature of any embodiment of this application can be freely and arbitrarily combined without contradiction. The combined technical solutions are also within the scope of this application.

[0092] Based on the methods in the above embodiments, this application provides a computer-readable storage medium storing a computer program that, when run on a processor, causes the processor to execute the methods in the above embodiments.

[0093] Based on the methods in the above embodiments, this application provides a computer program product that, when run on a processor, causes the processor to execute the methods in the above embodiments.

[0094] It is understood that the various numerical designations used in the embodiments of this application are merely for descriptive convenience and are not intended to limit the scope of the embodiments of this application.

Claims

1. A visualized routing simulation verification platform, characterized in that, include: Visual interaction layer, centralized management layer, and Burst parallel computing layer; The visualization and interaction layer is used to provide a graphical display and runtime interactive interface for building network topology based on the Unity editor, Odin serialization framework, and NodeCanvas node graph framework. The centralized management layer connects the visualization interaction layer and the Burst parallel computing layer. As the sole data source, it includes a topology management module, a message scheduling module, and a router status management module. It is used to realize the unified registration and global identifier allocation of network nodes, the centralized submission and batch delivery scheduling of messages, and the centralized storage and overall planning of the computing operations of the entire network router status data. The Burst parallel computing layer is used to perform multi-threaded parallel acceleration computing on core high-frequency jobs and write the computing results back to the centralized management layer.

2. The platform of claim 1, wherein, The topology management module is specifically used for: In the simulation preprocessing stage, a globally unique integer ID is assigned to each network node in a monotonically increasing manner, and a bidirectional mapping relationship is established between the integer ID and the node name and node object. In particular, IDs are assigned by sorting by node name to ensure that the same network topology generates a consistent ID mapping relationship in different editor sessions.

3. The platform of claim 1, wherein, The message scheduling module is specifically used for: Submit the message to be forwarded to the buffer message pool; By combining the link's bandwidth, cost attributes, and the packet's data payload, the number of transmission waiting frames is calculated through a time-consuming fitting mechanism, and the arrival frame timestamp of the packet is generated. In each simulation frame, a parallel arrival detection job is triggered at the underlying level to check the timestamps of messages in the buffer pool in batches and deliver the arrived messages to the corresponding target nodes.

4. The platform according to claim 1, characterized in that, The router status management module is specifically used for: Adopting a data-oriented design, the link-state database, routing table, and forwarding plane information of all network nodes are completely flattened and centrally stored in the underlying unmanaged contiguous memory container; The link state database is stored using integer ID pairs of the nodes at both ends of the link as keys, and the routing table is stored using composite pairs of router ID and target network ID as keys.

5. The platform according to claim 1, characterized in that, The Burst parallel computing layer includes: Parallel arrival detection jobs are used to determine the arrival status of messages in the buffer message pool in a high-concurrency manner within each simulation frame, and push the index of the arrived messages into the shared index list without locking. Parallel data forwarding job is used to traverse the packets to be forwarded in parallel, look up the next hop in the global routing table based on the integer ID of the target node in the packet, generate a new forwarding packet and submit it to the buffer message pool. The shortest path first computation job is used to recalculate the routing tables for affected routers in parallel when the link-state database is updated.

6. A routing simulation method, characterized in that, The method includes: Construct the network topology, create router nodes and communication links, assign a globally unique integer ID to each node, and establish a two-way mapping relationship between the integer ID and the node name and node object; The link-state database is constructed and the shortest path first calculation is completed through protocol flooding simulation. The entire network routing table is generated and the link-state databases, routing tables and forwarding plane information of all routers are centrally stored in the underlying unmanaged contiguous memory container. The simulation clock is driven by the Unity frame loop. Within each simulation frame, parallel arrival detection, arrival message delivery, protocol processing, message sending, and shortest path first calculation and scheduling are executed sequentially. The link attributes and message payload are converted into the number of transmission waiting frames through the time consumption fitting mechanism, the arrival frame timestamp is generated, the message is stored in the buffer message pool, and multi-hop forwarding is completed through parallel data forwarding jobs; During simulation runtime, link failure, link recovery, or algorithm switching events are dynamically injected to trigger link state database updates and shortest path priority recalculation. The system displays the real-time operating status of nodes and links through a visual interface, and receives external input test data streams, debugging commands, and mode switching commands.

7. The method according to claim 6, characterized in that, The process of assigning a globally unique integer ID to each node includes: Collect the names of all nodes, sort them lexicographically, and assign an integer ID to each node in a monotonically increasing manner; Establish a two-way mapping table from integer ID to node name and from node name to node object reference; Flatten the basic attributes of the nodes and write them into an unmanaged contiguous memory container.

8. The method according to claim 6, characterized in that, Before constructing the link-state database through protocol flooding simulation, all nodes in the topology are sorted, and the successive access and neighbor establishment process of each node is simulated according to the sorting results.

9. The method according to claim 6, characterized in that, The parallel arrival detection includes: Within each simulation main frame loop, a multi-threaded parallel computing job is triggered, and the preset arrival frames of all in-transit messages in the buffer message pool are checked concurrently to see if they are equal to the current global simulation frame. For messages that are determined to have arrived, lock-free concurrent write technology is used to push their underlying data index into the global shared index list; After the parallel detection job is completed, the globally shared index list is read in a unified manner, the arriving message is instantiated into an upper-layer logical message object and delivered to the target node.

10. The method according to claim 6, characterized in that, The shortest path first calculation and scheduling adopts a frame-based cooperative scheduling mechanism, including: A load counter is embedded in the loop logic of the shortest path first calculation job. The load counter is used to quantify the logical operation scale of the current algorithm. After the asynchronous computing task is completed, the accumulated total load value is divided by the preset computing power scaling factor to convert the computational complexity into the corresponding number of simulation clock frames. The immediate write-back of the calculation results is temporarily suspended. A virtual waiting period equal to the number of simulation clock frames is introduced. After the waiting period ends, the newly calculated routing table is written to centralized storage and takes effect.

Images