A levelez�m azt hiszi, hogy Roger Marquis a k�vetkez�eket �rta:
> 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).
Absolutely not.
A logging system is essentially a net of pipelines, where you want to
know if one of your pipes is broken, or something have dropped out
of the pipes.
So the server-server connections in a logging system are connection
oriented indeed.
This is not the "no news is good news" case.
As Bennett wrote, you can reinvent the wheel and implement TCP functionality
on top of UDP, but it makes your implementation unnecessarily complex.
In the case you don't want reliable, etc connection, you can use the old
syslog protocol, which we should include for backward compatibility.
You talk about "high bandwith" traffic. I guess you are thinking of
video and audio, where getting a packet too late is worst than not getting it
at all. For any other high bandwith traffic I can think of tcp is
far better than UDP, especially when you want to use it on WAN opposed
to LAN.
>
> The choice of protocol should be based on the traffic it's carrying.
> For syslog that's fundamentally connectionless, stateless and by
> extension UDP.
It is not stateless and not connectionless.
--
GNU GPL: csak tiszta forr�sb�l
