TCP DUP ACK是否是lwIP进程被饿死造成的？
Posted: Wed Dec 09, 2020 3:22 pm
大家好
我是#FujiNet项目的固件开发者之一，该项目为#Atari8bit电脑带来了网络适配器。
固件在这里，而且是免费软件。
https://github.com/FujiNetWIFI/fujinet-platformio
我们目前遇到的问题是固件中的Wi-Fi MODEM仿真（目前在这里实现：https://github.com/FujiNetWIFI/fujinet- ... /modem.cpp），如果主机发送了太多的一字节数据包（由于主机为了提高交互性能禁用了Nagle算法），那么ESP32对这些数据包的响应速度不够快，主机会重新发送数据包，最终导致重复确认（DUP ACK），因为ESP32最终确认了所有的数据包，如果晚了一点，最终导致主机认为数据包拥塞过多而拒绝发送更多数据。
我的问题是，如果程序的主线程运行过快，最终会不会饿死lwIP，无法进行基本的TCP内务管理，比如确认收到数据包？如果是这样，正确的解决方案是什么？
我们已经试过了
* vPortYield()在代码中处理接收数据包的所有部分。
* 调整SDK参数以调整静态和动态缓冲区的大小。
* 调整lwIP进程的进程亲和力。
* 明确地在处理收到的数据包的地方设置延迟（作为测试）
我们真的很头疼，任何帮助都会被感激。
托姆-切瑞家
我是#FujiNet项目的固件开发者之一，该项目为#Atari8bit电脑带来了网络适配器。
固件在这里，而且是免费软件。
https://github.com/FujiNetWIFI/fujinet-platformio
我们目前遇到的问题是固件中的Wi-Fi MODEM仿真（目前在这里实现：https://github.com/FujiNetWIFI/fujinet- ... /modem.cpp），如果主机发送了太多的一字节数据包（由于主机为了提高交互性能禁用了Nagle算法），那么ESP32对这些数据包的响应速度不够快，主机会重新发送数据包，最终导致重复确认（DUP ACK），因为ESP32最终确认了所有的数据包，如果晚了一点，最终导致主机认为数据包拥塞过多而拒绝发送更多数据。
我的问题是，如果程序的主线程运行过快，最终会不会饿死lwIP，无法进行基本的TCP内务管理，比如确认收到数据包？如果是这样，正确的解决方案是什么？
我们已经试过了
* vPortYield()在代码中处理接收数据包的所有部分。
* 调整SDK参数以调整静态和动态缓冲区的大小。
* 调整lwIP进程的进程亲和力。
* 明确地在处理收到的数据包的地方设置延迟（作为测试）
我们真的很头疼，任何帮助都会被感激。
托姆-切瑞家