mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Akbar Munir Chaudhary <ak...@acm.org>
Subject Re: TCP packet delivery failure
Date Mon, 20 Nov 2006 12:48:05 GMT
>> 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.




Mime
View raw message