Quoting Jose Alberto Fernandez <[EMAIL PROTECTED]>:
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Thanks for clarifications.
On the other hand, TCP knows that packet is delivered or not.
Not true. TCP knows if a packet was delivered. It does not know if a
packet was not delivered. The best it can do is resubmit the packet if
the ack fails to arrive within specific timeout. But if the packet is
sent, and I cut the line just after the packet goes there is no way for
TCP to know if that packet arrived and was processed by the high level
application or not, as there is no way for the ack to arrive.
OK, I think I get it. If an ACK is received, the packet has been delivered. If
no ACK is received, the packet may have been delivered or not.
But remember my first e-mail. I want to know that messages have been
delivered.
So, at TCP level, it is (would be) possible.
At socket-level, it is another thing.
And it seems socket API does not do anything with this info (no
exception)
The socket does not have this info, in general. Socket gives you a
virtual communication channel just like your phone gives you one when
you make a call. But there is no guarantee that the line will not fail
and you will loose contact.
This mandates application acknowledge if you really want to be sure
messages
have been delivered. In this case, why does bring TCP over UDP? Only
ordering?
Try to implement all the guarantees of TCP/IP on your own, with all the
cases, and then let us know if you want to do this over and over on
every application you write.
Don't take me wrong me. I don't discuss TCP relevance. I am just trying to
improve my understanding of it by discussing with specialists.
BTW, thanks to everybody for your input,
J-F
