Tom Perrine wrote: >It was a bad idea when you heard of it, and its still a bad idea, AT >LEAST FOR SYSLOG. I can easily see places where multiple virtual >channels over a single TCP connection could be useful. The >"stackable" session profiles is kinda a nice idea. If I was going to >do a fourth generation TELNET, BEEP would be a good answer, if there >were some libraries... It's a bad idea _in_ _general_. Remember LAT? It was a DECNet terminal multiplexing thingie used by DEC Terminal servers in the 70's and 80's. It sucked. Why? Because it's _REALLY_ hard to apply security filtering to multiplexing protocols - the protocols get extended and the next thing you know you've got file transfer and sharing and IP-over-multiplexed-channels and everything gets very grotty very fast. The ostensible reason for having those kind of multiplexed protocols is usually something like "that way we don't have to have as many sockets open" which is a silly argument when you consider that Web Services have caused a lot of changes to Unix (and Windows) kernel internals to make lookups on sockets and management of large numbers of sockets more efficient. It's probably easier for a modern BSD system to handle 10,000 live sockets today than it was for an 80's BSD kernel to handle 1,000. I suspect it was similar concerns that led the "designers" of syslog-1 to use UDP - no need to have a daemon that could effectively cope with large numbers of connected-state sockets. So, the braindamage began - I guess it was too hard to look up the man pages for shared memory system calls, or to just put it all in the /dev/log driver (and had a tamper-resistant-kernel-mode system logging facility like most REAL operating systems...) I'm consistently amazed that people worry about syslog performance. ;) How can you, when 99% of syslog implementations share the common performance improvement mechanism of dropping the UDP packets when the transmit queue on the client overflows. (See earlier posts by me in this list regarding how bad it can get under loads...) Making something that can _receive_ all those packets is straightforward - fixing all the broken syslog clients is a much more serious problem. If the standards process actually worked, the entire syslog protocol (especially the UDP client side) would be deprecated. *sigh* Re-reading this before I hit "send" I muse briefly about the possibility of becoming a "software historian" - I don't think anyone's done that, yet. Hmmm... "Social and economic factors and their influence on the development of logging protocols in California during the early 1980's..." I can see it already... mjr. --- Marcus J. Ranum - Computer and communications Security Expertise mjrat_private (http://www.ranum.com) _______________________________________________ LogAnalysis mailing list LogAnalysisat_private http://lists.shmoo.com/mailman/listinfo/loganalysis
This archive was generated by hypermail 2b30 : Thu Dec 05 2002 - 14:11:06 PST