Le 3/8/13 2:47 PM, Geronimoo CB a écrit : > Hi > > I am no network expert but I thought the purpose of tcp/ip was to insure that > packets arrive (in the correct order and with the right checksum) at their > destination. If a peer writes to the connection and does not receive an ACK > eventually,
How would a peer receive an Ack from a host that does not anymore exist ? > it would cause some low level exception No. There is nothing like an event that magically comes when a peer is brutally disconnected. TCP guarantees you that it can root some message to an host that exists and is connected, but that's pretty much it. You won't have a message that comes back when the peer gets disconnected. > that could propagate up the chain into mina and subsequently into my program > telling me that it was in fact not sent. You have such event when the server can detect that the socket has been closed. You wil then get an exception. But it won't happen when you unplug the cable. > Is there really no such mechanism or have I misunderstood the basic concept? I think you should read a bit about TCP. This is not a futile occupation when you are to write some code based on it. > > Keep alive, hearbeats pings and pongs will just insure that it will detect > disconnections faster No: they are the *only* way you can detect brutal disconnection. > but will not tell me whether my important message was sent or not. The only way to be sure that your important message has been sent is for your peer to send back an Ack for the message, period. > Implementing my own handshake when there is an inbuilt one in tcp/ip seems > excessive. Well, it depends on the criticality of your message... If it's critical to know that the message has been sent - and received !!! -, then your protocol must implement an Ack mechanism. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
