javascript - 数据流向

数据流的方向究竟是什么意思？

让我们考虑一种特定类型的软件，以便我们可以将数据流计数限制为更大的想法。

电信传输中的数据流分为两大类。

A. 传输硬件将东/西数据......从一个数据传输设备传输到另一个。通常，这种数据流太快，软件无法直接处理，而且数据同时双向流动。

B、电信传输数据控制称为北/南数据。该流包含 5 个软件数据流。流程是到/从本地硬件，以及从/到操作用户或主机。

B中通常有5个流（电信传输数据控制）：

status_update - 软件定期读取硬件状态信息（通常每秒一次）并将捕获的信息传递到本地“快速”存储（其他命令可以找到它以显示或传递到主机）
警报更新——非常类似于状态更新（即定期读取），但只是警报。警报具有持续时间和超时，并且相当复杂。
pm-update -- 非常类似于状态更新（即定期读取），但该软件会收集特定活动的汇总计数......输出多少字节，错误秒数等。这也有循环 15分钟时间桶，超时和其他并发症。
配置控制——用户应用的命令可以改变操作配置。sw 响应用户命令，更改特定的硬件配置寄存器。大多数 T1/E1 硬件可以在任一模式下运行，用户需要在启动时配置每个子系统。
供应控制——用户应用启用（或禁用）特定硬件类型可用性的命令来“传输”东/西数据。（想想客户计费服务）

从架构方法来看，这些流程中的每一个都可能是需求拉动或供应推动，但可能不是两者兼而有之。

需求拉取示例：状态更新（流向为北，从硬件到本地存储）

在我工作的大多数系统上，状态更新是由系统时钟触发的，并且在典型的需求拉动中，时钟事件触发了从硬件中读取所有状态条件。这些收集到的信息通常存储在本地“快速”存储中，其他命令可以在其中找到它以显示或传递给主机。

supply-push 示例：配置（流向为南，从用户到硬件）

任何配置（或配置）命令都与系统时钟异步（因为人类不喜欢也不擅长同步）。因此，当用户按下回车键时会触发一个动作，并且供应推送的数据（命令参数）会流向硬件。

对于supply-push，有时会进行协调工作，即在进行特定的其他事情时不允许配置（或prov）更改，但这通常使用简单的互斥锁来处理。

总结 - 在上述架构级别，流程可能看起来比实际更简单。

例如，有时，要在需求拉动期间阅读，软件必须“勾勒”硬件的某些特性，而“勾勒”感觉就像“方向错误”......但在这种情况下，“勾勒”是不是数据流的一部分，只是通过提取/拉出数据来完成数据流的开销。

类似地，要写入配置数据，软件有时必须确定硬件是否允许更改到下一个配置，这可能通过从硬件中读取来检查。这些读取感觉像是错误的方向，但同样，它不是数据流的一部分，只是一些流开销。

这种二元性发生在许多层面。

我不能说太多桌面软件，但我在很多地方看到了需求拉动和供应推动。在我看来，也许有些不那么自律，但这更有可能是因为我缺乏大型桌面应用程序的经验。