norm
This commit is contained in:
nicc@gfex.com.cn
193
my-project/docs/NORM.md
Normal file
193
my-project/docs/NORM.md
Normal file
@@ -0,0 +1,193 @@
|
||||
面向NACK（否定ACK）的可靠组播协议。
|
||||
## NORM基本结构
|
||||
### 消息
|
||||
NORM 消息包含在 UDP 数据报的数据字段中。
|
||||
NORM 对象是指 NORM 消息中携带的三种不同类型的批量数据：NORM_OBJECT_DATA、NORM_OBJECT_FILE、NORM_OBJECT_STREAM。
|
||||
NORM_OBJECT_DATA是指静态计算机内存数据内容，而NORM_OBJECT_FILE是指计算机存储文件。这两种消息类型都为有限的内容块提供可靠的传输，但进行了区分，以允许接收方确定为接收的消息内容分配哪种类型的存储。
|
||||
NORM_OBJECT_STREAM是指连续数据内容的流（非有限）。NORM 支持与 TCP 类似的流数据的可靠传输，但 NORM 接收器能够加入流内容的接收，而不考虑流中的时间点。
|
||||
### 会话
|
||||
NORM 会话是指使用 NORM 在两个或多个网络主机之间交换信息。通常，NORM 会话使用预先确定的 IP 地址和端口号进行，这些地址和端口号通常与在会话之前确定的 IP 组播组地址相关联。可以使用其他协议确定这些地址，例如会话描述协议 （SDP） [RFC 4566] 或会话公告协议 （SAP） [RFC 2974]。尽管 NORM 是专门为组播组通信而设计的，但它也支持单播通信。
|
||||
### 节点
|
||||
NORM 节点是指参与 NORM 会话的单个节点。每个节点都有一个唯一的标识符。当节点传输 NORM 消息时，此标识符被记录为source_id。
|
||||
### 实例
|
||||
NORM 实例是指 NORM 会话的连续段上下文中的单个节点。当节点加入 NORM 会话时，它具有唯一的节点标识和实例标识。如果节点出于任何原因离开会话，然后重新加入会话，则节点标识保持不变，但实例标识会更改。当前实例被记录为instance_id。
|
||||
## NORM消息格式
|
||||
NORM 有两个通用消息类，即发送方消息和接收方消息。NORM 发送方消息类型为：NORM_DATA、NORM_INFO 和 NORM_CMD。 NORM 接收方消息类型为：NORM_NACK、NORM_ACK 和 NORM_REPORT。
|
||||
所有 NORM 消息都由一个必需的公共标头、一个消息类型标头和一个有效负载（数据）部分组成。可以在标头和有效负载部分之间插入一个可选的扩展字段，用于指定正在使用的纠错编码、拥塞控制算法或其他会话管理信息。
|
||||
|
||||
### NORM公用消息头
|
||||
|
||||
**版本（4 位）**
|
||||
协议版本号。
|
||||
**类型（4 位）**
|
||||
NORM 消息类型（即 1 = NORM_INFO、2 = NORM_DATA、3 = NORM_CMD、4 = NORM_NACK、5 = NORM_ACK、6 = NORM_REPORT）。
|
||||
**hdr_len（8 位）**
|
||||
用于识别头部扩展的添加。如果“hdr_len”值大于给定消息类型的基本值，则意味着存在头部扩展。
|
||||
**序列号（16 位）**
|
||||
有两个用途（取决于消息类型）：
|
||||
|
||||
- 允许接收方保持对数据包丢失的估计，以促进拥塞控制。
|
||||
- 支持防止NORM_NACK或NORM_NACK消息的消息重放攻击。
|
||||
|
||||
**source_id（32 位）**
|
||||
在给定 NORM 会话的上下文中发起消息的节点的唯一标识。
|
||||
### 发送方 NORM_DATA消息类型
|
||||
NORM_DATA 消息是 NORM 发送方发送的最常见的消息类型。NORM_DATA 消息携带了 NORM_OBJECT_DATA、NORM_OBJECT_FILE 和 NORM_OBJECT_STREAM 类型的分段数据内容。
|
||||
|
||||
浅蓝色为NORM_DATA的数据内容：
|
||||
**instance_id（16 位）**
|
||||
当前参与 NORM会话实例的唯一标识。
|
||||
**grtt（8 位）**
|
||||
发件人当前估计的组往返时间。
|
||||
**backoff（4 位）**
|
||||
在使用基于定时器的 NORM NACK 反馈抑制机制时，接收机用于确定最大回退定时器值的值。
|
||||
**gsize（4 位）**
|
||||
发件人对组大小的当前估计值。
|
||||
**flag（32 位）**
|
||||
二进制标志提供信息以帮助接收方适当地处理有效载荷。
|
||||
**fec_id**
|
||||
FEC 编码（前向纠错，通过在发送数据时添加冗余信息（校验码），使接收端能够在接收到的数据中检测和纠正错误，而不需要进行额外的请求。）标识符。
|
||||
**object_transport_id**
|
||||
发送方分配给正在传输的 NORM 对象的值，接收方将其用于传输和修复请求。它以单调增量的方式增加。
|
||||
**fec_payload_id**
|
||||
附加的NORM_DATA有效负载内容的标识符。
|
||||
### 发送方 NORM_INFO消息
|
||||
NORM_INFO消息允许在数据传输中附加一些可选的额外信息，这些信息与传输的数据内容相关联。这使得接收方可以了解所传输内容的性质，从而能够基于这些信息做出相应的处理或决策。
|
||||
NORM_INFO内容必须放在单个NORM消息的有效负载中，因此它被视为“原子”的，即不可分割的。这意味着所有相关信息必须适合于单个消息的大小限制。
|
||||
一个典型的应用场景是发送与数据内容相关的MIME类型信息。例如，当发送方传输一个文件时，可以通过NORM_INFO消息发送文件的MIME类型（例如，文本、图像、音频等），这样接收方就可以根据文件类型做出相应的处理或展示。
|
||||
|
||||
**instance_id（16 位）**
|
||||
当前参与 NORM会话实例的唯一标识。
|
||||
**grtt（8 位）**
|
||||
发件人当前估计的组往返时间。
|
||||
**backoff（4 位）**
|
||||
在使用基于定时器的 NORM NACK 反馈抑制机制时，接收机用于确定最大回退定时器值的值。
|
||||
**gsize（4 位）**
|
||||
发件人对组大小的当前估计值。
|
||||
**flag（32 位）**
|
||||
二进制标志提供信息以帮助接收方适当地处理有效载荷。
|
||||
**fec_id**
|
||||
FEC 编码标识符。
|
||||
**object_transport_id**
|
||||
发送方分配给正在传输的 NORM 对象的值，接收方将其用于传输和修复请求。它以单调增量的方式增加。
|
||||
### 发送方 NORM_CMD消息类型
|
||||
NORM_CMD消息的作用：NORM_CMD消息用于管理NORM会话，其功能包括：
|
||||
收集往返时间（round-trip timing RTT）：用于评估网络延迟和性能。
|
||||
收集和发送与拥塞控制相关的数据：用于动态调整发送速率以避免网络拥塞。
|
||||
同步修复窗口：确保接收方在数据丢失时能够及时恢复。
|
||||
发送方状态通知：提供发送方的状态信息，如就绪状态、发送速率等。
|
||||
|
||||
**instance_id（16 位）**
|
||||
当前参与 NORM会话实例的唯一标识。
|
||||
**grtt（8 位）**
|
||||
发件人当前估计的组往返时间。
|
||||
**backoff（4 位）**
|
||||
在使用基于定时器的 NORM NACK 反馈抑制机制时，接收机用于确定最大回退定时器值的值。
|
||||
**gsize（4 位）**
|
||||
发件人对组大小的当前估计值。
|
||||
**flag（32 位）**
|
||||
二进制标志提供信息以帮助接收方适当地处理有效载荷。
|
||||
**fec_id**
|
||||
FEC 编码标识符。
|
||||
**object_transport_id**
|
||||
发送方分配给正在传输的 NORM 对象的值，接收方将其用于传输和修复请求。它以单调增量的方式增加。
|
||||
**sub-type**
|
||||
**指示后面的命令的类型。**
|
||||
**NORM_CMD内容**
|
||||
|
||||
- FLUSH：表示发件人的临时传输结束。也可以任选地用于从接收器子集收集可靠接收的肯定确认。
|
||||
- EOT：表示传输永久结束。
|
||||
- SQUELCH ：指示发送方响应超出范围的 NACK 的当前修复窗口
|
||||
- CC：用于GRTT测量和拥塞控制反馈的收集
|
||||
- REPAIR_ADV ：通告发送方的聚合修复/反馈状态，以抑制来自接收方的单播反馈。
|
||||
- ACK_REQ：从接收方列表请求应用程序定义的肯定确认（可选）。
|
||||
- APPLICATION：用于需要临时抢占或补充数据传输的应用程序定义的用途（可选）。
|
||||
### 接收方 NORM_NACK消息
|
||||
NORM_NACK消息主要由接收方使用，用于请求发送方修复丢失的数据内容。当接收方检测到数据丢失或损坏时，它可以通过发送NORM_NACK消息向发送方请求重新发送丢失的数据。此外，这些消息还包含向发送方提供与往返计时收集和拥塞控制相关的信息的字段。
|
||||
|
||||
**server_id（32 位）**
|
||||
NORM_NACK消息发往的 NORM 发送方。
|
||||
**instance_id（16 位）**
|
||||
当前参与 NORM 会话实例的唯一标识。
|
||||
**reserved（16 位）**
|
||||
用于未来可能的 NORM 用途
|
||||
**grtt_response_sec（32 位）**
|
||||
根据最近收到的 NORM_CMD （CC） 消息为指定的 NORM 发送方调整的时间戳版本。秒级。
|
||||
**grtt_response_usec（32 位）**
|
||||
根据最近收到的 NORM_CMD （CC） 消息为指定的 NORM 发送方调整的时间戳版本。微秒。
|
||||
**NACK_payload**
|
||||
接收方相对于“server_id”字段指示的 NORM 发送方的维修需求。
|
||||
### 接收方 NORM_ACK消息
|
||||
NORM_ACK消息主要用于支持拥塞控制操作和往返计时测量。
|
||||
|
||||
**server_id（32 位）**
|
||||
NORM_ACK消息发送方。
|
||||
**instance_id（16 位）**
|
||||
当前参与 NORM 会话实例的唯一标识。
|
||||
**ack_type（8 位）**
|
||||
NORM_ACK消息的性质。这直接对应于此ACK适用的 NORM_CMD（ACK_REQ） 消息的“ack_type”字段。
|
||||
**ack_id（8 位）**
|
||||
用于发送方验证接收到的NORM_ACK消息是否适用于当前的确认请求。但对于NORM_ACK(CC)和NORM_ACK(FLUSH)确认类型，"ack_id"字段不被使用。
|
||||
**grtt_response_sec（32 位）**
|
||||
NORM_ACK消息中的一个时间戳。这个时间戳是根据最近接收到的，NORM_CMD(CC)消息调整后的版本，它指示了指定的NORM发送方的时间。精确到秒。
|
||||
**grtt_response_usec（32 位）**
|
||||
NORM_ACK消息中的一个时间戳。这个时间戳是根据最近接收到的，NORM_CMD(CC)消息调整后的版本，它指示了指定的NORM发送方的时间。精确到微秒。
|
||||
**ack_payload**
|
||||
ACK消息中携带的额外信息。
|
||||
### 接收方 NORM_REPORT消息
|
||||
NORM_REPORT用于向发送方报告接收方的状态和数据传输情况。它提供的机制，使得接收方能够向发送方反馈有关数据传输的信息，以便发送方能够根据这些信息调整其传输策略和行为。
|
||||
NORM_REPORT消息可能包含的信息包括但不限于：
|
||||
接收状态报告：报告接收方已成功接收到的数据包序号范围，以及可能存在的丢失或损坏的数据包。
|
||||
网络状态信息：提供关于网络延迟、丢包率、带宽利用率等方面的信息，以帮助发送方了解当前的网络状况。
|
||||
发送方状态信息：提供有关发送方的状态信息，如发送速率、发送窗口大小等，以便接收方了解发送方的传输行为。
|
||||
其他应用相关信息：根据需要，NORM_REPORT消息还可以包含其他与应用相关的信息，以帮助发送方进行更精细的传输控制和管理。
|
||||
### NORM 报头扩展
|
||||
可选的头部扩展在NORM协议中用于提供额外的信息，这些信息可以是与前向纠错、拥塞控制操作或其他会话管理信息相关的。这些头部扩展紧跟在公共头部和特定消息头部之后，但在负载之前（如果消息有负载）。
|
||||
|
||||
**het（8 位）**
|
||||
标头扩展类型。对于可变长度标头扩展，值介于 0 和 127（含）之间。
|
||||
**hel（8 位）**
|
||||
标头扩展长度。指示整个标头扩展的长度。
|
||||
**标头扩展内容**
|
||||
因用途而异。
|
||||
## NORM协议操作
|
||||
### 一般操作
|
||||
通用 NORM 协议操作的详细过程：
|
||||
1、在建立 NORM 会话之后，发送方将一个 NORM 对象分割成一个按顺序编号的序列。这些分段被传输为 NORM_DATA 消息。除了数据内容外，NORM_DATA 消息还带有唯一标识符和 FEC 标识符。发送方还可以发送与 NORM_DATA 内容相关联的带外 NORM_INFO 消息，允许接收方确定相应内容的性质，从而允许应用级别控制接收节点在会话中的参与。与此同时，发送方会定期发送 NORM_CMD(CC) 消息，根据需要收集用于拥塞控制和其他会话管理活动所需的反馈信息。
|
||||
2、当接收方从发送方检测到丢失的内容时，它们可以尝试使用 FEC 机制进行修复。如果修复成功，则接收方将不会发送 NORM_NACK 消息给发送方。利用顺序编号的序列信息，接收方指定缺失的内容。
|
||||
3、当发送方接收到 NACKs 时，它会聚合修复请求，并发送与顺序编号的序列信息相关联的适当修复。
|
||||
4、当发送方到达修复请求的末尾时，它会发送一个 NORM_CMD(FLUSH) 消息，指示传输的临时结束。
|
||||
在通用操作的背景下，NORM 具有特定的机制来解决会话控制、拥塞控制、流量控制、可靠性和 NACK 管理。
|
||||
### 会话控制
|
||||
尽管 NORM 不像 TCP 那样是面向连接的协议，但它确实具有面向连接和无连接的特征。
|
||||
1、NORM 的连接特性和无连接特性：NORM 协议在某种程度上具有连接导向和无连接的特性。它不像 TCP 那样需要进行显式的连接设置（如三次握手），但发送方和接收方必须事先知道对方的地址和端口号，以便加入会话或者重新建立连接。这种特性使得 NORM 协议在网络中断后能够快速恢复会话，并且允许接收方在会话进行时加入。
|
||||
2、状态维护以确保可靠传输：尽管 NORM 是一种类似 UDP 的无连接协议，但它仍然需要维护一些状态信息来确保数据的可靠传输。这些状态信息可以帮助发送方和接收方进行数据的丢失检测和修复，以确保数据的完整性。
|
||||
3、NORM_CMD 消息子类型的保留：NORM 协议预留了一系列 NORM_CMD 消息的子类型，以支持可能在未来开发的会话控制协议。这意味着 NORM 协议具有一定的灵活性，可以根据需要引入新的控制协议来满足不同的需求。
|
||||
### 拥塞控制
|
||||
NORM 使用了一种 TCP-Friendly 拥塞控制方案，使其能够与 TCP 和其他传输协议公平地共享可用带宽。这意味着当 NORM 和 TCP 同时存在于网络中时，它们会共同占用网络带宽，并且不会对彼此造成过度的影响。这种拥塞控制方案基于 RFC4654 中描述的 TCP-Friendly Multicast Congestion Control（TFMCC）协议规范的方法进行了适应。已经证明，该方法能够有效地与 TCP 和组播数据流一起使用。
|
||||
1、TCP-Friendly 拥塞控制方案：NORM 协议采用了一种称为 TCP-Friendly 的拥塞控制方案。这意味着 NORM 能够在与 TCP 和其他传输协议共享网络带宽时保持公平性，即它不会过度占用网络带宽，也不会对 TCP 的性能造成不利影响。
|
||||
2、基于计算的拥塞控制方法：该拥塞控制方案是基于计算的，发送方的传输速率取决于通过 NORM_CMD(CC) 消息收集的数据包丢失估计和往返时间。这些信息有助于确定网络中的瓶颈，并相应地调整发送方的传输速率，以适应网络的变化。
|
||||
3、拥塞控制假设：与 TCP 类似，NORM 假设数据包丢失是由于网络中的缓冲区溢出引起的。因此，当数据包丢失率达到一定水平时，发送方会自动减少传输速率，以避免进一步的数据包丢失。然而，在无线网络中，数据包丢失通常是由于比特错误或网络争用引起的，而不仅仅是缓冲区溢出。这可能会导致 NORM 的拥塞控制在无线网络中存在一些限制。
|
||||
4、速率控制机制的独立性：NORM 的速率控制机制与其其他组件（例如可靠性机制、流量控制机制）是相分离的。因此，可以通过使用其他算法和适当的标头扩展来替换 NORM 的速率控制机制。这增加了 NORM 协议的灵活性，使其能够根据不同的网络环境和需求进行定制和调整。
|
||||
### 流量控制
|
||||
NORM 有四个流量控制选项，允许 NORM 发送方管理到 NORM 接收方的传输速率，以确保接收方不会超载。
|
||||
1、显式水印。使用此选项，发送方请求来自特定一组接收方的积极确认，确认当前传输中指定点或水印的成功接收。如果所有接收方都确认成功接收了水印，发送方可以继续发送新数据。
|
||||
2、隐式水印。这个选项基于接收方集合没有负面确认（NACK）修复请求。发送方使用 NORM_CMD(FLUSH) 来提醒接收方通过指示的水印进行任何需要修复的 NACK消息。然后发送方等待刷新完成。如果没有 NACK 消息，发送方假定水印已完成，可以继续发送新数据。
|
||||
3、基于定时器的流量控制。这个选项根据组往返时间（GRTT）和 NACK 活动来保持传输数据并限制修复窗口的推进。设置一个最小的、可适应的时间限制，在此之后发送方可以继续发送新数据。这个时间限制基于发送方估计的 GRTT 和无NACK消息。
|
||||
4、禁用。禁用流量控制机制，允许发送方以最快方式推进传输数据。
|
||||
水印：数据同步的水印描述了一个预定义格式的对象，为试图建立增量/增量同步的两个系统/数据集提供了一个参考值；在水印值之后创建、修改或删除的被查询数据源中的任何对象都将被归类为“高于水印”，并应返回给请求数据的客户端。
|
||||
### 可靠性
|
||||
NORM通过使用两种前向纠错编码方案（系统码和非系统码）来确保可靠的传输。
|
||||
使用系统码时，发送方先传输一组内容块，然后是一 组纠错编码块。
|
||||
使用非系统码时，发送方在传输之前对内容进行纠错编码。
|
||||
这两种纠错编码方案都可以以反应性或预测性的方式使用。在这两种情况下，都可以影响基于 FEC 的修复，从而允许接收方修复数据包，从而降低了修复请求和修复传输的级别。
|
||||
### 可扩展性和NACK管理
|
||||
面向 NACK 的组播通信容易受到 NACK 内爆的影响。如果大量接收方同时发送NACK，这可能会使发送方以及整个网络不堪重负。NORM 使用 NACK 抑制机制来防止 NACK 内爆。
|
||||
当接收方检测到它在发送方的 NORM 传输中丢失了数据时，它会启动 NACK（否定确认）过程：
|
||||
1、接收方假设其他一个或多个接收方也丢失了相同的数据，并且可能已经向发送方发送了 NACK。
|
||||
2、接收方进入一个基于随机退避算法的等待期。这个超时持续时间由“随机退避”算法定义，根据发送方在其传输的消息中传输的“grtt”、“backoff”和“gsize”字段的信息进行控制。
|
||||
3、在等待期间，接收方继续接收和评估来自发送方的修复消息，并且抑制自己的 NACK。
|
||||
4、如果在等待期结束时，接收方没有收到足够的修复信息，它就会启动自己的 NACK。
|
||||
5、如果 NORM 会话发生在组播路由环境中，NACK 将被传输给发送方以及网络中的所有其他节点。
|
||||
6、如果 NORM 会话不是在组播路由环境中进行的，NACK 将被传输给发送方，发送方立即重新将其发送到网络中的所有其他节点。
|
||||
NORM 的 NACK 抑制机制，结合其 FEC 机制，使得 NORM 组播组可以扩展到非常大的组，同时保持可靠性。
|
||||
0
my-project/docs/bus.md
Normal file
0
my-project/docs/bus.md
Normal file
0
my-project/docs/cpp.md
Normal file
0
my-project/docs/cpp.md
Normal file
0
my-project/docs/dataflow.md
Normal file
0
my-project/docs/dataflow.md
Normal file
0
my-project/docs/udp.md
Normal file
0
my-project/docs/udp.md
Normal file
0
my-project/docs/unlockqueue.md
Normal file
0
my-project/docs/unlockqueue.md
Normal file
0
my-project/docs/无锁队列需求.md
Normal file
0
my-project/docs/无锁队列需求.md
Normal file
12
my-project/docs/组播需求.md
Normal file
12
my-project/docs/组播需求.md
Normal file
@@ -0,0 +1,12 @@
|
||||
NORM组播技术讨论记录：
|
||||
1、NORM协议为基于否定ACK的可靠组播协议，主要提供了会话控制、拥塞控制、流量控制和可靠性扩展等功能。
|
||||
2、可靠组播主要的设计思路：
|
||||
做到消息传递的不丢包、不错包、不乱序。在消息传递过程中要做到数据处理的一致性，以及系统反演的一致性。
|
||||
（1）基于丢包，应该使用何种方式进行重传（TCP？）修复。
|
||||
（2）在拥塞控制、可靠性扩展方面，要控制性能，控制代码量。
|
||||
（3）组播单个丢包的处理是协议层解决；但组播接收方断连、心跳丢失等问题应该由应用层解决。应用层利用探活、心跳、收发包计数等机制，及时判断发送方的状态。
|
||||
（4）整体的设计思路是基于UDP，开发所必要的TCP控制功能，剥离冗余部分。
|
||||
3、可靠组播的使用场景基于交易系统数据流分析，应该包括总线到模块（主备点）、总线到外部。
|
||||
4、对比openPGM等组播协议，分析交易系统所必须的功能，对比性能选择合适的开源协议。
|
||||
5、构建wiki服务器，进行新一代交易系统POC需求管理。
|
||||
|
||||
@@ -1,6 +1,10 @@
|
||||
site_name: 新一代交易系统POC
|
||||
nav:
|
||||
- 无锁队列: unlockqueue.md
|
||||
- 无锁队列需求整理: 无锁队列需求.md
|
||||
- C++选型: cpp.md
|
||||
- 组播协议: udp.md
|
||||
- NORM协议: NORM.md
|
||||
- 组播需求整理: 组播需求.md
|
||||
- 消息中间件: bus.md
|
||||
- 数据流整理: dataflow.md
|
||||
|
||||
Reference in New Issue
Block a user