> > >>>>> "Mark" == Mark Andrews <Mark_Andrews@xxxxxxx> writes: > > [snip] > Similarly if syslogd is using a reliable transport > to talk to another syslogd. That too can block which > will eventualy lead to blockages to applications / > memory exhaustion. *That* is a different beast, not yet discussed. I know that it exists but it is not related to DNS. If it happens, it is really bad and typically results in a complete system hang. There are some situations where a lossy transport is preferable. For example, I have written a syslog/TCP implementation which, if forced to run in single-threaded mode, favours discarding messages over blocking as the later could indeed lead to fatal problems on a typical linux system. The root cause, however, is not reliable syslog per se. The root cause is the implementation. A reliable syslogd actually needs to be implemented with a non-blocking, de-coupled, buffered design. In almost all cases, that means separate receiver threads, a to-be-processed message queue and separate sender threads. Still, you have to decide what to do if the queue size is exhausted. But that scenario is much less likely. In that case, I'd still favour loosing some messages over potentially loosing all AND the system the syslogd runs on. As far as I see it, this is an app-layer issue out of scope for the underlying protocol. The problem, of course, is that syslog is simplex and hop-to-hop, so the original sender will never know that the message was lost. Protocol-wise, I do not see any fix to that except integrating some asynchronous notification mechanism. IMHO, this is outside the scope of syslog. It may be useful to add some hint to implementors pointing to this blocking condition. But I am not sure if it is really justified. Rainer _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf