目标：在SuT-稳定性下，延迟低于~ 10 [ms]？
感谢添加了关于相当广泛的延迟上限~ 10 .. 100 [ms]的详细信息
+
...这实际上是用Python替换以前用C实现的东西。想法是，如果库的接口层和cli都是用Python实现的，那么用户就更容易为他们的用例构建核心功能。一些更严格的控制循环可能必须作为静态C库或Rust库实现，我们将在Python中调用它们。无论如何，顶层仍然是用Python实现的，它将与C#进行接口。
(= 这里最重要的收获...
需要理解希望拥有的用户扩展易用性和重构架构的成本
+ 谁支付这些成本)
在我们开始寻找解决方案之前：
为了安全、专业地完成这项任务，您很可能会喜欢this，以避免重复未经考虑的常见错误，其中一般性评论源自大量关于创建控制环路下系统~ 80 [us]的第一手经验。
绘制您的控制系统-包括内部生态系统（资源）和外部系统（与外界的交互）
接下来是架构：
没有对玩具的充分理解，就无法决定正确的架构。
了解延迟驱动设备的设备景观，需要我们首先了解（阅读+测试+基准测试），并在系统-测试的过载条件下了解其抖动/漫游包络。不了解这一点将导致盲目和缺乏事实支持的信仰，我们的SuT永远不会撞上现实之墙，这将在最不愉快的时刻证明自己是错误的。
这是不可逆转的错误和不良实践，因为到目前为止所产生的所有成本已经被消耗殆尽...
在绘制架构之前，了解和测试是核心步骤 - 在这里，细节很重要（ref.一个人在h2d/d2h延迟中失去多少？[us]？ - 为什么这些主要成本被报道得如此弱？这是否意味着这些成本不存在？不是的。它们确实存在，您的控制回路每次都会付出代价...因此最好提前了解所有这些隐藏成本，在before Architecture设计和起草之前支付TimeDOMAIN中的费用。)
不要犹豫，尽可能地去分布式 （在合理支持的情况下{{link1:）：
从NASA阿波罗任务设计中学习
- 它是深度分布式的
和
- 适当的工程帮助到达月球
- 它挽救了国家的尊严和这些第一位、迄今为止唯一的外星人的生命
（感谢玛格丽特·哈密尔顿女士在定义她的设计规则和改变许多控制环路系统协调策略的适当工程方面的智慧）
无论是
ZeroMQ (
zmq，作为一种成熟、可组合、良好扩展的基本分布式多对多
行为体系结构，开发在一些微不足道的可扩展正式通信模式原型之上) 还是它的Marting SUSTRIK 共同创立的年轻而轻量级的姐妹
nanomsg，都可以帮助人们组合出一个智能的宏系统，在这个宏系统中，各个组件的优势（或者说是由于没有替代品而产生的垄断）可以相互连接成一个仍然满足延迟阈值的
稳定的、具有优先级意识的宏系统，对于这样的系统，在原则上（或者由于其他原因——成本经济、上市时间、法律限制是首要考虑的问题）不能设计成一个单体
全能系统。
乍一看，这可能会让问题变得更加复杂，但人们很快就会意识到，它确实起到了完全相反的作用：
- 不会浪费任何燃料（是的，投资者的钱）在另一个“重新发明轮子”的过程中...
- 使用业界已经证明可靠的工具通常可以提高可靠性，当然，如果使用正确的话...
- 性能扩展可能会成为一个不错的副作用，而不是太晚重构的恐慌噩梦。
更不用说这些工具独立演化和进一步扩展所带来的积极影响了。
我的系统也面临着类似的困境——对我来说，#C不是一个选择（闭源应用程序依赖性对我们的成功来说代价太高了，甚至可能是致命的）。
- CLI：称为远程键盘是分离第一个Python的确切示例，其中远程可以被读作跨大西洋-键盘
- ML：是城镇中最不受控制的延迟元素，因此需要融合
- 核心应用程序：使用行业标准DLL扩展为分布式计算系统，而不让它知道（只有剥离的核心逻辑保留在原地，其他所有内容都分布式处理，以尽量减少所有控制循环的延迟并处理不同级别的优先级）
- 非阻塞插件：从核心应用程序卸载
- 核心应用程序(1+N)-热备份-阴影：引入到最初的单片C/S外部系统中
是否有必要添加更多的内容，以便实现分布式和独立于原始供应商锁定？
选择从头开始使用成熟的v2.x版本的ZeroMQ，付出了汗水、眼泪和血汗，但我没有一点后悔，在没有做到这一点的情况下，我无法想象如何满足上述要求。
