In short: the server calls ::send() successfully but the data is not going out on the cable. The client send its quit command after some seconds because it does not receive any thing and that command is correctly received by the server.
In details: The server send a command to its clients every 1/10 of second and an heartbeat each second. The clients only return an ack for the heartbeat. We modified the server application to log every command sent and received and we have recorded the pc's traffic with Wireshark. We can match every logged command to a TCP packet, until the problem kicks in. The problem only affects one client at a time. The data continues to flow normally with the other clients. The connection usually works a few minutes before getting into trouble. The connection should works from the moment the client boots until it is closed (ie days).
When the problem occurs, the log file contains the expected commands, but the Wireshark dump contains nothing. The image below show the traffic with one client. The red line is when the traffic stop, but the server continues to call ::send() successfully. 
After about 4 sec, the client timeout and it close the connection. It send a quit command and the server receive it normally.
What puzzle me even more is the packet containing the quit command is not acknowledged with a TCP ACK packet. It is as if the TCP connection is completely jammed on the sending end. The retransmission is an effect of that jam, but even the TCP SYN to establish a new connection is not correctly processed and does not get a simple TCP ACK.
After about 30 sec, the problem disappears and the SYN packet is finally accepted and the communication continues with the new connection.
This was tested on various Windows versions. During the tests, a remote desktop session was used and it never got disconnected by the sam