Roger Marquis wrote:
>
> Bennett Todd <[EMAIL PROTECTED]> wrote:
> >1999-10-20-14:08:30 antirez:
> >> I think (hope) it's possible to reach our goals even using UDP. Why to use
> >> TCP if strong auth it's possible even using UDP? Also in a lot of case auth
> >> and cryptografy isn't needed with some hosts so a 'modular' protocol may be
> >> a good choice.
> >
> >But for a high-performance, reliable delivery, it'd be kinda silly
> >trying to do it with UDP;
>
> Actually, it seems kind of silly to use TCP for what is essentially a
> connectionless protocol. We do need reliability, of course, but that
> can be taken care of with application-generated ACKs, without a lot of
> coding. We don't need the sequence numbers, sliding windows, or other
> traffic shaping features of TCP. We also don't need to initiate
> connections from the destination to the source.
I'm kinda in agreement with this. One of the nice features of udp syslog is
that the source needs a route to the sink but not vicea versa. But I also
know that not all the messages get there :-(. The problems with ACKs and
sliding windows are issues when congestion takes over and retransmission
with slow start takes over. I already see daily buffer overruns on some
sources!!
What is needed is for the replacement protocol/application to step down
from it's new authenicated/hashed/encrypted/non-repudiated form to the
current basic udp stream. This looks essential to keep compatiblity. This
stepping will mostly likely be a configuration switch/flag. But would it be
useful as an automatic failsafe when TCP ACK start failing (for whatever
reason)?
Gavin.
--
Gavin Longmuir
RSA PGP fingerprint: 6E 68 B6 D7 37 46 BA 3C 04 D7 44 B6 EB 15 3D BA
Did you know that the ARPANet/Internet is truely over 30?
The facts http://www.isoc.org/guest/zakon/Internet/History/HIT.html
