A levelez�m azt hiszi, hogy Douglas Granzow a k�vetkez�eket �rta:
> > In fact, let's make UDP the baseline requirement. If there are useful
> > features that require TCP, then they should be added as options, with the
> > note that TCP is required to make them work.
Nearly all useful features will require TCP then:)
>
> This sounds like a decent idea. Let's make UDP the baseline for now. As
> we come up against issues that would seem to require TCP, perhaps we can
> think of a creative way to meet the requirement without TCP. If we get to
> the point where it seems like we are reinventing TCP, we can reconsider
> it. And we can certainly allow for syslog2 to be used over TCP.
>
> I came into this considering TCP to be a requirement. I don't like the
> uncertainty of whether or not my messages are received by the loghost.
> However there are certainly issues to be considered. Other people have
> stated them, but I'll try to summarize some of them here:
>
> - If you do one TCP connection per message, you are spending a lot
> of resources building up and tearing down TCP connections
I guess no one was serious about doing a tcp connection per message.
>
> - If you create a persistent connection, your main loghost will be
> maintaining potentially thousands of connections, consuming memory for
> send and receive queues, etc.
If you do the same with UDP, you will have to use the same amount of resources
for state informations. And if you want crypto in UDP, you either have to
do it per packet (and basically forget public key cryptography), or have
resources for both state information and number crunching far exceeding
the resource requirements of vanilla tcp.
>
> - If a connection drops with no RST, you are potentially still losing
> messages
But at least you will know that you have loosed them.
>
> - syslog2d will need to recognize dropped connections and reestablish
This is a "useful feature" instead of "problem".
>
> - There may be simple network devices which want to provide a remote
> logging capability without having to implement a TCP stack
This is the only argument I can regard as a serious one. But if they can't
do tcp, they can't do more advanced things either like cryptographic
authentication, etc. We have plain old syslog protocol here, with nothing
to talk about.
The bottom line: We either want features, or use UDP with the old protocol.
For myself I want features.
--
GNU GPL: csak tiszta forr�sb�l
