分布式模拟系统与应用层路由交换机的技术探索
1. 分布式模拟系统中的化石收集
在分布式模拟系统中，使用受控类型进行化石收集是一个值得探讨的话题。首先来看一段代码：
ep := NEW element_type’(controlled WITH mp, info_data, NULL);
通过详细分析这段代码的执行过程，我们可以发现，当展开聚合操作时，会创建一个临时的匿名对象，该对象带有一个指向消息对象的指针。同时，分配器会创建一个元素类型的对象，并将聚合的“值”赋给它。随后，聚合对象会被终结，包括消息对象的释放，此时就会产生悬空指针。
使用受控类型存在两个主要缺点：
-
复杂数据结构中的终结操作问题
：在具有强链接元素的复杂数据结构中，终结操作可能会导致不必要的释放，从而引发系统故障或产生错误结果。特别是在模拟中，很难证明最终结果的正确性。
-
单一终结操作的不足
：在某些情况下，对于一种类型的单一终结操作是不够的。根据调用终结操作的不同情况，可能需要两种或更多不同的方法。
为了解决这些问题，在原型中添加了基于释放操作的化石收集机制。
2. 原型实验结果
进行了一系列实验来验证化石收集机制的有效性。实验使用的示例包含 200 个交付站逻辑进程（LPs）和 200 个相关的源 LPs。整个系统被分为两个子模型。
由于在单个处理节点上测量使用的内存更简单，因此首先在单处理器工作站上进行了有无化石收集的实验。通过测量模拟运行期间所需的内存与全局虚拟时间（GVT）推进的关系，得到了如下结果：
| GVT | 无化石收集内存使用（MB） | 有化石收集内存使用（MB） |
| — | — | — |
| 250 | 10 | 略低 |
| 500 | 20 | 略低 |
| 750 | 30 | 略低 |
| 1000 | 40 | 略低 |
| 1250 | 50 | 略低 |
从图中可以看出，当没有化石收集时，内存使用几乎呈线性增长；而有化石收集时，曲线的轻微增长是由于源 LPs 的简单调度策略。
同时，为了支持上述想法的实用性，还确定了模拟运行期间不同时刻整个系统中状态栈元素的总数。结果显示其呈现出振荡行为，没有整体增加的趋势。
3. 应用层路由交换机的概述
Top Layer Networks 的 AppSwitch™ 是一款协调的硬件和软件第 7 层应用交换机，旨在通过根据用户和生成消息的应用自动对网络流量进行优先级排序，为数据通信网络提供应用控制。选择 Ada 作为 AppSwitch™ 软件的编程语言，是因为它具备提供高可靠性和可移植性的最佳语言特性组合。
AppSwitch™ 的硬件和软件架构非常复杂，其核心是流量分类技术，由硬件和软件组件共同实现。该交换机可以深入分析传入数据包，直至应用产生的第 7 层报头，以确定数据包的源地址、目的地址和应用类型。流量分类由预配置的应用配置文件库（APL）支持，该库包含流量分类和优先级排序的规则。
4. 各子系统软件架构
-
转发引擎软件架构
：转发引擎的架构专注于以线速路由数据包。由于有大量专有硬件技术支持交换，软件需要与硬件操作保持紧密关系，并且必须以高度可预测的方式运行。其软件结构是一个轮询循环，没有中断。轮询循环有多个路径，主要基于消息流的生命周期：
- 新流设置路径 ：处理新流的设置，通过识别消息的重要属性，包括生成它的应用，以便为消息流的其余数据包应用适当的“定制”应用策略。
- 快速路径（FastPath） ：处理消息流其余部分的大部分路由，通过咨询会话数据库，智能地为数据包路由应用适当的应用策略。
- 会话数据库维护路径 ：用于实时调整所有消息流的路由。
- 广域网（WAN）子系统软件架构 ：WAN 子系统专注于管理 T1 和电话线与 AppSwitch™ 其余部分之间的“电路”，使用 PPP 或帧中继协议。软件同样以高度可预测的方式运行，整体结构是一个轮询循环，只有一个中断用于更新内部时钟。
-
后台引擎软件架构
：与前两个子系统不同，后台引擎有多个关注点，其活动由三种类型的事件触发：
- 消息数据包的到达
- 时间段的到期，触发特定时间的特定操作
- 延迟操作的执行，触发稍后时间的特定操作
后台引擎具有多线程结构，通常为每个处理的唯一事件分配一个线程。其中最重要的线程是 Packet/Event Processor，它负责处理后台引擎中所有排队在 JobJar 中的消息数据包、定时器事件和延迟操作。
为了确保系统在高通信活动期间不会被压垮，Packet/Event Processor 会过滤掉低优先级的消息数据包，并根据 DMA 中断的饱和度减少 DMA 中断的数量，从而将消息数据包的到达进行捆绑，以提高处理效率。
下面是后台引擎的主要组件架构图：
graph LR
classDef circle fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
classDef rectangle fill:#FFEBEB,stroke:#E68994,stroke-width:2px;
classDef queue fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;
A(Clock):::circle --> B(Packet/Event Processor):::circle
C(DMA Input):::circle --> B
D(DMA Output):::circle <-- "processed packets" --> B
B --> E(JobJar):::queue
E --> F(Application/Service/Session Modules):::rectangle
E --> G(Protocol/Session Modules):::rectangle
F --> E
G --> D
H(System Services):::rectangle --> F
I(User Services):::rectangle --> F
J(ModuleObjectMgr):::rectangle --> F
J --> G
K(External DataBase):::rectangle --> F
L(Internal DataBase):::rectangle --> F
M(Disaster Manager):::rectangle --> B
N(Strategic Disaster events):::circle --> M
这个架构将系统的主要模块分为核心模块和扩展模块。核心模块始终存在于后台引擎中，为系统中的任何模块提供一组直接可访问的服务。扩展模块通过一个或多个过程接口为 Packet/Event Processor 和其他模块提供服务。未来，扩展模块可以通过直接下载到 AppSwitch™ 中进行动态替换或添加。
综上所述，分布式模拟系统中的化石收集机制和 AppSwitch™ 应用层路由交换机都有各自独特的技术特点和挑战。通过不断的研究和改进，有望进一步提高系统的性能和可靠性。
分布式模拟系统与应用层路由交换机的技术探索
5. 转发引擎各路径详细分析
在转发引擎的轮询循环各路径中，新流设置路径、快速路径和会话数据库维护路径有着不同的作用和特点。下面通过表格来详细对比：
| 路径名称 | 功能描述 | 特点 |
| — | — | — |
| 新流设置路径 | 识别消息重要属性，确定生成消息的应用，为新流配置相关参数，以便后续应用合适的应用策略 | 涉及消息属性的全面分析，对新流的初始化至关重要 |
| 快速路径（FastPath） | 依据会话数据库，快速为消息流的大部分数据包应用合适的应用策略进行路由 | 强调速度，需要高效地从会话数据库获取信息 |
| 会话数据库维护路径 | 实时更新会话数据库中的数据，确保消息流路由的准确性和适应性 | 注重数据的实时性和准确性 |
这三条路径相互协作，共同保障了转发引擎能够高效地以线速路由数据包。
6. 后台引擎事件处理流程分析
后台引擎的活动由三种事件触发，下面通过 mermaid 流程图来展示 Packet/Event Processor 处理这些事件的详细流程：
graph TD
A[消息数据包/定时器事件/延迟操作到达 JobJar] --> B{事件类型判断}
B -->|消息数据包| C[Packet/Event Processor 接收]
B -->|定时器事件| D[Packet/Event Processor 处理]
B -->|延迟操作| E[Packet/Event Processor 执行]
C --> F{消息数据包目标}
F -->|应用/服务模块| G[应用/服务模块处理]
F -->|协议/会话模块| H[协议/会话模块处理]
G --> I[可能产生新消息或定时器事件入 JobJar]
H --> J[通过 DMA 输出离开后台引擎]
D --> K[触发特定时间操作]
E --> L[触发稍后时间操作]
K --> M[可能产生新消息或定时器事件入 JobJar]
L --> N[可能产生新消息或定时器事件入 JobJar]
从这个流程图可以清晰地看到，Packet/Event Processor 作为核心，对不同类型的事件进行分类处理，并且整个过程中可能会产生新的消息或定时器事件，再次进入 JobJar 等待处理。
7. 分布式模拟系统与 AppSwitch™ 的关联与挑战
虽然分布式模拟系统中的化石收集机制和 AppSwitch™ 应用层路由交换机看似是两个不同的领域，但实际上它们存在一定的关联。两者都需要处理大量的数据和复杂的操作，并且都对系统的可靠性和性能有较高的要求。
然而，它们也面临着各自独特的挑战：
-
分布式模拟系统
：
- 受控类型的使用可能导致复杂数据结构中的终结操作出现问题，引发不必要的释放和系统故障。
- 单一终结操作在某些情况下无法满足需求，需要更灵活的处理方式。
-
AppSwitch™ 应用层路由交换机
：
- 选择 Ada 作为编程语言面临巨大的学习曲线，开发团队需要花费大量时间来掌握。
- 系统中处理器的 Ada 工具链不完整，需要进行额外的开发和完善。
- 构建 Ada 运行时系统以有效支持 Ravenscar 模型也是一个挑战。
8. 未来展望与建议
为了进一步提高分布式模拟系统和 AppSwitch™ 应用层路由交换机的性能和可靠性，可以考虑以下建议：
-
分布式模拟系统
：
- 进一步优化化石收集机制，减少不必要的内存占用，提高系统的稳定性。
- 研究更灵活的终结操作方法，根据不同的情况选择合适的终结策略。
-
AppSwitch™ 应用层路由交换机
：
- 加强对 Ada 工具链的开发和完善，提高开发效率。
- 优化 Ada 运行时系统，使其更好地支持 Ravenscar 模型，提升系统的性能。
- 持续改进系统架构，提高系统对高通信活动的应对能力，确保系统在各种情况下都能稳定运行。
通过以上的分析和建议，我们可以看到，分布式模拟系统和 AppSwitch™ 应用层路由交换机在技术上有着各自的特点和挑战，同时也存在一定的关联。通过不断的研究和改进，有望推动这两个领域的技术发展，为数据通信和模拟领域带来更好的解决方案。
扫一扫
2619
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
