Thank you for your quick answer. On 31/03/2014 21:59, Emmanuel Lécharny wrote:
Le 3/31/14 9:56 PM, Jon V. a écrit : > TCP works perfectly. If there is a problem. It is elsewhere. > > Implementing message delivery confirmation is a part of a higher level > protocol. If the network/TCP is connected; it will be delivered. > > > Here is what happening regarding missing packets 39-55. Those are packets > that probably exist in the native io buffer. No application can read what > is in there? The assumption is that data in there will be written. However > a socket can be closed while data exists in this buffer. > Your higher level proto needs to send back an ACK with a packet number. You > need to handle this yourself. So this confirm my first statement? " 1. TCP reliability is not enough for messages not to be lost." If the cable is disconnected for a few seconds and if the TCP socket is closed (which is OS-dependent), whether in client or in the server, the application needs to reproduce the same message delivery acknowledgment of the TCP's one? > In what environment are you expecting TCP sockets to close all the time? Not all the time, maybe just once. We don't want the message to be lost if this happens. completely agree. When you unplug the cable, there is nothing MINA can do : the connection is still opened on its side, until a timeout occurs. It seems this is OS-dependent (this is right in Linux, in Windows before 7 it closes quickly). In other words : if a client disconnect brutally without signaling that it is disconnecting, then unless you check the connection periodically for idleness, you are dead in the water. Ok, but it does not matter that the server is aware that the connection has been closed (temporary). What matters is that the client is aware of that, whether at application or transport-level. Am I wrong somewhere? Thank you. Yours sincerely, Antoine
