In some email I received from Roger Marquis, sie wrote:
[...]
> Except that syslog doesn't need sequence numbers, it doesn't need
> sliding windows, it doesn't need slow-start or any of the other
> connection-oriented features of TCP. These are features which
> facilitate continuous, bidirectional data circuits. Syslog messages
> are not, in the vast majority of cases, connection-oriented. They
> don't need to setup, maintain, and tear-down a session/circuit. 99% of
> syslog data requires only a single packet and a single ACK (for
> reliability).
>
> The choice of protocol should be based on the traffic it's carrying.
> For syslog that's fundamentally connectionless, stateless and by
> extension UDP.
If you showed me evidence, in court, that was based on an unreliable
source, how could you claim that what was being presented was itself,
reliable and accurate ?
The next implicit problem with UDP is to do with size - you can only
fit so much in a UDP message, without causing fragmentation. There
are a number of protocols (DNS comes to mind) which have limitations
built in because of that. With syslog today, there is an arbitrary
limit of 1024 bytes in a syslog message. Start adding in checksums
and you run out of room real quick.
If I want to do strong authentication of the server I'm sending data
to or it is going to attempt to expect strong authentication from me,
I would expect TCP to be a natural mechanism for supporting that.
However, that is different to applications sending syslog messages to
the local daemon (assuming that is the model people wish to work with).
Is there any need to change that protocol ? An RFC covering the old
syslog protocol would do this.
Darren
