On Wed, Oct 20, 1999 at 07:03:30PM -0400, Douglas Granzow wrote:
> > If we take it as given that messages will have monotonically increasing
> > timestamps, I don't see that there's a strong need for in-order delivery.
> > If the protocol uses a hash chain on messages, packets which go missing can
> > be detected even without ACKs -- perhaps the receiver should be able to
> > request retransmission in at least some cases.
>
> This sounds like an excellent idea. It approaches the guaranteed delivery
> of TCP without reinventing TCP. It doesn't completely accomplish the same
> thing, though. If messages A B C are sent, and the loghost receives A and
> C, it could detect that B was missing. But what if it only receives A?
> It won't have any way of knowing B or C were ever sent. Perhaps there
> should be a heartbeat of some sort?
I've implemented a similar protocol, it works but with _a lot_ of problems.
if you require high troughput and/or if your net lose a lot of packets this is
even more hard that rewrite a TCP stack.
May implementation is under an hping2 beta and it is very poor because is just
a dirty hack (http://utenti.tripod.it/almanet/hping2-current.tar.gz) but
I really think that under high traffic it is more complex than it appared.
antirez
