On Thu, Oct 21, 1999 at 12:03:56PM +0200, Magosanyi Arpad wrote:
> Nearly all useful features will require TCP then:)
Important features as client authentication and message signing / encryption
can be performed in UDP without problems.
> > - 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
I'm not sure. First using UDP a lot of resource for state informations are in
the client side so are distribuited (client send the message and wait for
the ACK, server simply logs the message and sends the ACK, if ACK doesn't reach
the client, server will receive a duplicate but it will discard this using the
message seqnum (required..), so we can use only 4/8 bytes for client).
> 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
Are you sure that syslog2 needs public key cryptography? I think it is near
to be useless in our context: since we needs both cyptography and source
verification a shared secret may be a better solution. I think that public
key cryptography is necessary if we needs that some unknown client will
connect to our server using criptography, but seems that it isn't required by
syslog2.
> resources for both state information and number crunching far exceeding
> the resource requirements of vanilla tcp.
I think that using TCP you will require both state informations and socket memory.
> > - If a connection drops with no RST, you are potentially still losing
> > messages
>
> But at least you will know that you have loosed them.
But only when you need to send new logs.
> > - syslog2d will need to recognize dropped connections and reestablish
>
> This is a "useful feature" instead of "problem".
Without this "useful features" you may experiment a lot of problems.
> > - 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.
cyptographically secure authentication using a shared secrets and UDP isn't less
secure. Simply the server will drop all packets with a bad hash value. Hash
verification can be very fast if we makes a table that links source IP address
and shared secrets and hash functions like MD5 and SHA1 are light to compute.
> The bottom line: We either want features, or use UDP with the old protocol.
> For myself I want features.
IMHO it's possible to design a protocol that offers x security features
using UDP and x+y features using TCP. y features may be implemented in UDP
later, but this wil be an implementation problem.
antirez
