Behaviour of MODBUS_ERROR_RECOVERY_LINK

[ssgnh]

modbus_tcp模式下，客户端错误恢复模式设为以下，
modbus_set_error_recovery(ctx, MODBUS_ERROR_RECOVERY_LINK | MODBUS_ERROR_RECOVERY_PROTOCOL);
在连接成功后，不停的向服务端发送信息，此时断开网线，modbus_read_registers()会返回-1，但是函数里调用的send会发送成功（发送到tcp发送缓冲里），这样情况能持续几分钟左右。此时将网线插上，发送缓冲区的大量数据会将服务端冲击崩溃，有什么好的解决办法吗？

目前我将MODBUS_ERROR_RECOVERY_LINK标志删除了，通过判断modbus_read_registers()返回3次-1来判断链路中断，感觉不是个好的方法。

[JayHerpin]

im seeing the same issue, but if I leave it disconnected long enough it actually never recovers

[JayHerpin]

Much of this is brought over from here: BlackZork/mqmgateway#39

Steps to reproduce:

Computer and device are both connected via a simple switch. Run the configuration below. Disconnect the device from the switch (or cut its power). Wait for some period of time then reconnect the ethernet or restore power.

At this point the connection doesn't recover.

What is observed:

Notice the packet trace on the right. You can see at time 1713450984.766486 I reconnected the device, but at this point the sliding window never progresses further...

What should Happen:

After the configured responses timeout is hit (up to 3 times?) the TCP connection should be closed and re-opened.

---

Note that as this is happeneing, the kernel's tcp send buffer is continuously growing. I believe that the best thing to do is to close the TCP connection after the device is non-repsonsive for long enough if for no other reason as a way to purge and control the send buffer.

[JayHerpin]

I would be happy to work on the fix for this, however, I am only able to test on a small subset of platforms, and also don't have any serial devices to test against. I am a bit concerned about breaking other's setups by making a change in the core modbus.c logic.

I am almost inclined to have the tcp_flush function close and reopen the connection itself, but that feels a little "out there"

[ssgnh]

因为我发送的频率很快，断网后，内核缓存溢出很快，就会有Broken pipe错误。我测试过，断网后，调用的send函数依然会发送成功，导致断网重连不起作用。我换了种思路，modbus是一问一答，既然断网时问是成功发送的（实际发送到网络硬件了），但是答确不是。我通过多次接收不到回答数据，便认定断网，关闭socket，然后执行connect，这种思路类似于心跳，但挺好使。

3次返回-1是我自定义的，第一次返回-1时，我就发送相同的帧数据（避免传输丢帧导致不回复情况），也就是我发3帧相同数据依然不回复我，便认为通讯故障