mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From J-F Daune <daune...@daune-consult.com>
Subject Re: TCP packet delivery failure
Date Mon, 20 Nov 2006 14:53:49 GMT
Akbar Munir Chaudhary a écrit :
>>> But in that case, wouldn't I be better off designing my send
>>> + ACK protocol over UDP instead of going through the overhead
>>> of session opening and closing? I always thought that the TCP
>>> stack in the kernel would actually let the higher layer know if it
>>> has received the ACK for the packet that was requested to be
>>> sent. In fact the kernel's TCP stack must receive the ACK before
>>> it can declare a message to be delivered successfully. Why doesn't
>>> it then pass this information to the higher layer?
>> It's the difference between "Yes, I've heard you" and "Yes, I've done
>> it". By using TCP you know that the data you send will get there in
>> the same order it was sent, but you still need to be able to tell the
>> other side when you've done something in response to that data
>> arriving.
> Well at least in my case, there is a result that goes back to the client
> in response to a command packet that is sent from the client to the server.
> However, the execution of command takes sometime and response can be
> delayed. So I do not want my client to start waiting for the result when it
> does not even know if the server has heard its request or not. So the only
> way out of, as Trustin suggested in his earlier email, appears to be building
> some sort of ACK based protocol on application layer. Honestly speaking,
> it corrects a lot of my concepts of writing applications on top of TCP sockets.
I also think that if you don't receive the TCP ACK, you cannot be sure 
that it has not been received.

So, a ACK message seems necessary.


View raw message