> > 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... Rainer _______________________________________________ LogAnalysis mailing list LogAnalysisat_private http://lists.shmoo.com/mailman/listinfo/loganalysis
This archive was generated by hypermail 2b30 : Fri Jan 03 2003 - 18:48:33 PST