问题标签 [flow-control]

使用 scapy 时，如何设置流量控制窗口大于 65535 的 tcp 数据包？我知道用 scapy 写作：

将窗口设置为 65535；但是如果需要将窗口大小设置为大于 65535，则应该以不同的方式设置，因为在 tcp 标头中，窗口字段只有两个字节，所以它不能大于 65535，所以应该在另一个中完成方法。我知道这应该是可能的。

谢谢。

为了管理串口，我编写了常用函数，基于以下结构：

我在另一个文件中调用这些函数（见下文）以测试 RS232 串行端口。需要启用流量控制。

为了验证实施，引脚排列 Tx 和 Rx 已连接在一起，CTS 和 RTS 同上。一切正常，发送的消息可以正确读取。此外，当 Tx 与 Rx 断开连接时，没有按预期读取。

但是，当 CTS 从 RTS 中拔出时，端口关闭步骤（约 20 秒）之后的测试块。

但是，如果使用 flowControl == 0 调用函数 setuart()，则测试不会阻塞并立即返回预期的错误代码。

我可能理解错误，尤其是在端口配置中。这是好方法吗？

我正在测试串行端口通信的代码。我现在使用同步 IO 来保持简单。我观察到当 PC 收到 XOFF 时程序暂停，控制台窗口中不再打印。当程序收到 XON 时，它会再次开始运行。

有什么方法可以确定我的程序的串行端口是否早先收到了 XOFF（不管同步和异步 IO），因为在这种情况下，COM 端口驱动程序会阻止端口发送任何字符，我最好在调用之前检查是否收到了 XOFF写文件（）。

我认为一种方法是将 ClearCommError() 与 COMSTAT 结构一起使用。这是唯一的方法吗？我通过阅读https://msdn.microsoft.com/en-us/library/ff802693.aspx得到了这种印象。 如果是这样，那肯定是一种奇怪的做法。

我已经组装了一个媒体转换器，它可以从一侧转换为 100Mbps 以太网，另一侧转换为 100BASE-FX 光纤。该转换器进入的应用程序使用全双工/暂停帧流控制来处理数据过载。我已将硬件配置为接受和处理暂停帧。我需要的是一种测试设置的方法，以查看媒体转换器是否正确处理暂停帧。为此，我有两个问题......

1）有没有人有一个很好的方法来测试一块硬件处理暂停帧？

2）我的一个想法是通过转换器发送数据。这样做时，向转换器发送一个已知长度的暂停帧。然后查看设备是否暂停了正确的时间。这种方法看起来可行吗？如果是这样，是否有一种简单的方法（软件工具）来生成暂停帧来完成我想要做的事情？

在这里的任何帮助将不胜感激。

谢谢，迈克·尼兹

来源：https ://en.wikipedia.org/wiki/Flow_control_%28data%29

当接收方仅从发送方接收到一半窗口大小的数据字节时，这是否像阻塞条件？（发送方在发送窗口大小后期待确认！！！）。认为他提到没有其他实体尝试通信，那是什么意思？。为什么因为在窗口大小的一半之后，接收者仍然期望剩余，如果发送者处于静音状态会发生什么？。接收者做什么？，仍在等待？，在这种情况下发送者期望什么？。谢谢进步。

有 2 个不同的嵌套循环，每个循环都有一个 break 语句来在特定条件下中断外部循环。

我想知道我是否用相同的标题标记了 2 个外部循环，这会引发 break 语句的混淆吗？

然后我尝试了以下代码片段

事实证明代码工作得很好，并且没有出现重新声明问题。我认为这可能与范围主题有关。第一个 break只能看到#1代码块中的outterLoop ，第二个break只能在它所在的范围内看到outterLoop ，也就是#2代码块。结果，不可见的作用域限制了内部break可以“看到”的变量

问：我理解的对吗？如果没有，请纠正我。即使我没有错，我相信我使用了非正式和不精确的描述。如果您能给我一个更正式和准确的描述，那就太好了。

非常感谢

现在我正在通过 Udoo Neo 上的 C++ 中的 UART 与设备通信。为此，我使用 termios 建立连接并将数据写入设备。为此，我想使用硬件流控制并使用 termios 设置标志（CRTSCTS）。

对于硬件流控制，我已将设备 RTS 线连接到板 CTS，并且我还通过示波器检查，如果设备还没有准备好读取，它会给我一个高电平有效。

问题是，在下面的示例中，我仍然丢失了字节，只是用数字向设备发送垃圾邮件，但电路板输出表明一切都正确写入。

我以为使用硬件流控时UART会被阻塞，这样就不会丢失任何信息。我没有正确理解这一点 - 还是代码中有错误？

谢谢您的帮助

}

我们控制客户端每 2 秒通过不同主题的扩散向客户端发送 100 个更新，每个大小为 200-250 字节（每个主题在 2 秒内更新一次）。问题是在发送这些大约 20-30 分钟后，流量控制开始，并且由于流量控制，更新在 1-2 小时后从 5 毫秒延迟到 100 毫秒。有什么方法可以避免在扩散中发布 Control Client 的流量控制？

maxqueuesize 设置为 10000 扩散 api 日志：压力 = 0.04622500000000004 => 睡眠 4 毫秒

我很感激有关如何在 FreeBasic 中设置以下硬件流控制参数的建议

正如规范所说：

流量控制特定于连接。两种类型的流量控制都在单跳的端点之间，而不是在整个端到端路径上。

而在6.9 WINDOW_UPDATE

两种类型的流量控制都是逐跳的，即仅在两个端点之间。中介不在依赖连接之间转发 WINDOW_UPDATE 帧。但是，任何接收方对数据传输的限制都会间接导致流控制信息向原始发送方传播。

但这怎么可能呢？似乎需要所有中介了解h2或h2c协议，我有两个问题：

1. HTTP/2 是一个相对较新的标准，我看到很多网站都启用了它（包括我的博客）。虽然我可以毫无问题地访问这些网站，但这是否意味着沿途的每个中间设备（如路由器和集线器等）已经实现了自己的 HTTP/2 堆栈和流量控制算法（因为 RFC7540 没有规定流量控制算法）？

2. 大多数网站使用h2而不是h2c加密应用层数据。HTTP/2 的流量控制是由接收方发送WINDOW_UPDATE帧完成的，这也是应用层数据，那么中间设备如何知道这些数据是什么？如果他们无法解密数据并看到Window Size Increment部分，他们如何在不转发WINDOW_UPDATE帧的情况下完成流量控制？