Other Directory Sites: SeekWonder | Directory Owners Forum
The following archive was created by hippie-mail 7.98617-22 on Sat Apr 10 1999 - 01:11:00
bram (bram@gawth.com)
Fri, 21 Aug 1998 11:49:49 -0700 (PDT)
On Thu, 20 Aug 1998 proff@iq.org wrote:
> > TCP is end-to-end stream connection. Many people use the word
> > reliable, but I don't: If the receiver shuts down the connection
> > there is no way for the client to know how much data was received.
> > /r$
>
> This is more of an API issue. There is no reason one couldn't hand
> over the last highest received ack to the caller (this is what I
> do in sudp). Of course this doesn't mean that the application at
> the other end has actually read this data - just the stack. The
> more I look at this issue the more I believe the berkeley approach
> is correct, and that application data should be ack'd by the
> application at application level message boundaries.
There's a fundamental point which it's important to understand about the
reliability of any protocol which works over the internet. In any clean
protocol termination there will by necessity be a last message. This last
message, being sent like everything else, will have a sender and a
receiver. If the whole connection dies right as the last piece of the last
message is on it's way, then the sender of the last message will have no
reason to think anything went wrong, while the receiver will have a
problem. There's no way of avoiding this situation, all you can do is
define your protocol in a way where it isn't all that bad a case. Having
an acknowledgement of the last message doesn't help at all - it just makes
the protocol longer, since that final acknowledgement is now the last
message, and subject to the same old problem.
-Bram
The following archive was created by hippie-mail 7.98617-22 on Sat Apr 10 1999 - 01:11:00