Le 4/1/14 10:34 AM, TRAN Antoine a écrit : > 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? Your application needs to deal with such a scenario, yes.
> >> 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. Again, that's your application work to deal with such a scenario. TCP is not, and never meant to be, reliable. And what is true on the server side is also true on the client side (ie, no matter who initiates the communication, you have to deal with connection interruption, or, better said, you have to add some ACK mechanism plus some idle detection on bth side if you want to be sure that the messages are being transmitted). -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
