RE: [logs] Syslog payload format

From: Rainer Gerhards (rgerhardsat_private)
Date: Fri Jan 03 2003 - 13:53:36 PST

  • Next message: Buck Buchanan: "RE: [logs] Windows Event Log Analysis"

    > > That way, we keep consistent with the rest of the world. 
    > And, yes, I 
    > > would definitely like to see (and implement) a such simple RFC3164 
    > > over TCP as you suggest: plain 3164 EXCEPT
    > > 
    > > - TCP is used
    > > - the message format stays as in 3164
    > > - if one message is sent in a TCP session, there is no 
    > modification to 
    > > 3164 format
    > > - if multiple messages are sent in a single TCP session, the second 
    > > and all subsequent messages START with LF (or CRLF - well 
    > either one 
    > > or the other).
    > I'd have to disagree, for two reasons:
    > - Why not make the timestamp ISO?  The new transport obviously 
    >   requires new code, so ... ?
    I simply still assume that we not to intend to spec a new protocol. So I
    am thinking more or less in the boundaries of 3164. Keep in mind we need
    to interoperate.
    > - And here's the big one: The (CR)LF needs to _terminate_ messages,
    >   _not_ start new messages.  Why?  Well, consider a host that only
    >   sends messages a few times a day, and also consider the fact that 
    >   I might want to do automatic alerting for a certain event.
    >   Without termination, I would have to wait several hours for the
    >   next event to arrive before I could act on the message.
    >   Recognizing that EOF is termination of an event is hardly
    >   rocket science. All fgets() implementations do this.
    If we stay with 3164 (slightly enhanced for TCP), the message will never
    be split across two packets. There is a 1024 char limit for this reason.
    As such, when the end of the received packet is reached and there is no
    LF, then *this* is the end of the message. No need to wait any more
    hours. Of course, if you engineer a new protocol, I fully agree...
    LogAnalysis mailing list

    This archive was generated by hypermail 2b30 : Fri Jan 03 2003 - 18:48:33 PST