On Wed, 20 Oct 1999, Robert Webber wrote:
> Instead, can we select one of TCP and UDP the baseline, and make the
> syslog-sec protocol work over either? For example, we could select UDP as
> the baseline and design a syslog-sec protocol which doesn't require
> reliable transmission and acknowledgement. The protocol could also work
> over TCP, if we're careful to avoid problem areas for TCP (like multicasting).
>
> 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.
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
- 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 a connection drops with no RST, you are potentially still losing
messages
- syslog2d will need to recognize dropped connections and reestablish
- There may be simple network devices which want to provide a remote
logging capability without having to implement a TCP stack
I think one of our goals should be to create a protocol which can be used
on any platform. Any discussions of configuration files, kill signals,
command line options, etc. are going to be system-specific and are outside
the scope of the protocol itself. The protocol should be usable whether
the device is Unix, Windows, Cisco, vending machine, or watch. While TCP
capability is certainly nice-to-have, and maybe even a requirement *in a
particular environment*, I don't think it should be a requirement for the
protocol.
> If we take it as given that messages will have monotonically increasing
> timestamps, I don't see that there's a strong need for in-order delivery.
> If the protocol uses a hash chain on messages, packets which go missing can
> be detected even without ACKs -- perhaps the receiver should be able to
> request retransmission in at least some cases.
This sounds like an excellent idea. It approaches the guaranteed delivery
of TCP without reinventing TCP. It doesn't completely accomplish the same
thing, though. If messages A B C are sent, and the loghost receives A and
C, it could detect that B was missing. But what if it only receives A?
It won't have any way of knowing B or C were ever sent. Perhaps there
should be a heartbeat of some sort?
>
> What are the requirements for this protocol which TCP fulfills, and that
> can't be had by other means?
>
> Bob
>
Doug
