philippe_44 wrote: > Well, in fact I misread the wireshark and the FIN request from the LMS > is ACKnowledged by the bridge's stack but what was missing is the FIN > from the bridge. It should be sent when closing the connection in > return, but I don't because do it in time I don't see it fast enough > (I'm slowly reading buffered data). So, as Paul rightfully pointed it > out, once the server has received the ACK of FIN, it waits TIME_WAIT and > then sends a RST frame that causes the client to wipe-out all already > stored buffered. > > I assume (maybe I'll give it a try) that Linux vs Windows is that the > Linux frame might not send a RST frame and simply move on after > TIME_WAIT. It's an interesting and complicated combination of events but > that's purely a vicious implementation mistake, I now realize it. So it > is probably not Moby Dick, alas!
Looks like you're closing in on it. As a reminder, if it is relevant, I ran a test earlier after adding a TcpTimedWaitDelay registry entry with a value to 30 seconds, overriding its default value of 2 minutes and, after rebooting, the errors still occurred after the same 2-minute interval. At the moment, I am preparing to perform a test with the plugin binary running on a Linux RPi and will post the results of that here. Sam ------------------------------------------------------------------------ SamY's Profile: http://forums.slimdevices.com/member.php?userid=63495 View this thread: http://forums.slimdevices.com/showthread.php?t=104614 _______________________________________________ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
