On Fri Mar 03 16:27 2000 -0500, Chris Calabrese wrote:
> This list got awfully quiet since the holidays.
> Anybody still out there?
I'm still here, and still very interested in a new syslog protocol.
After my last attempt to revive the discussion failed, I just assumed
everyone else was just as busy as I've been lately. ;)
> I've got a very rough draft of an Internet Draft
> for the stuff we were working on towards the end
> of last year, and I'm looking for co-authors to finish
> it off. See the attached.
Looks good. A few specific comments follow.
> 3.2.4 Selective Storage
> Essentially this boils down to the requirement that
> the originator of a log message have the capability
> to detect that a particular message has or has not
> reached its destination. Since it is more
> important to detect that the message has not
> reached its destination, it is not necessary that
> mechanisms implementing this capability be
> perfectly accurate. Therefore, such
> implementations should not intrude inordinately on
> issues such as performance.
I definitely agree that the verification mechanism should have as
little impact on performance as possible. It might be useful to
mention some possible mechanisms for accomplishing this (either here
or in the "Resource Utilization Considerations" section), such as an
ACK window size determined in the handshaking phase.
I'm not sure what you mean by saying that the verifyable delivery
mechanism doesn't need to be "perfectly accurate". It seems to me
that if it's not accurate, it doesn't do any good.
> 3.2.5.3 Availability
> The following seem reasonable requirements for
> high-availability:
>
> 1. Logging mechanisms should be able to
> transmit their log messages to multiple
> destinations. Therefore increasing the
> probability that at least one will be
> available.
This is an excellent point. You might want to expand upon that to
describe both a "multiple primary" setup (where messages are always
sent to multiple servers for redundancy) and a "failover" setup (where
a secondary log server is used when the primary is unavailable).
> 3. Logging protocols should not require log
> senders to wait synchronously for positive
> acknowledgement of messages sent.
> Therefore making denial of service attacks
> on log senders more difficult through the
> generation of excessive traffic on a
> particular network link.
This doesn't address the issue of initial message submission, where
the process submitting the message needs an ACK for each message if it
wants to use verifyable delivery. It might be better to say that the
client and server will determine during handshaking whether or not
an ACK should be sent after each message (i.e., set the ACK window
size to 1).
--
Mark D. Roth <[EMAIL PROTECTED]>
http://www.feep.net/~roth/
