On Wed, Oct 20, 1999 at 02:11:55PM -0300, Emiliano Kargieman wrote:
> a good idea, given that we don't end
> up with an HTTP-like protocol that opens a TCP connection for every little
> 100byte packet. The overhead is just too much. I'd rather go for keeping
> one single TCP connection open for each host we are logging to.
I think that keeping a TCP connection open shows some implementation problem.
SO_KEEPALIVE socket option is a bad idea, it can take even _two_ hours to
notice that connection is down. Think at following scenary: host and client
are connected, no log traffic. Connection goes down for some reason, for example
because server has reset connection but RST was lost or it crashs and reboots.
Client isn't informed, but some program wake-up and has a lot of logs to do,
so client try to send new logs to the server but server reset is connection.
If is a slow net a threeway handshake can be very very slow and if while
some process needs to log I think it's a problem. Clients must
implement some buffer but I don't now how large it must be. Another problems
comes from necessity of notice when link goes down. Using TCP you need some
`ping' features with a lot of overhead. Using UDP you simply needs only a
packet to check that other host is alive, for example sending an
UDP->syslog2->null request and waiting for an ICMP.
With this I _dont_ want to maintain that UDP is better than TCP for
syslog2, simply I think that to choose TCP without a deep analysis may
be an error. So since seems that both UDP and TCP have some advantages
a good solution may be to design a protocol that can be simply implemented
using both TCP and UDP.
> > For the exact same reason we should investigate the possibility of having
> > SSL as the crypto layer of transmission.
>
> I would rather have a separate specification of the crypto layer, and
> aninterface specification if you want (although i find this being an
> implementation
> issue) to free us from any specific choices here.
Yes but as you can notice your client buffer must be lager if you use
a 'slow' crypto layer protocol. So protocol, implementation and cripto
layer seems to be not so stratified.
(plese, for this and next mails, sorry for may poor english)
antirez
