"Mark D. Roth" <[EMAIL PROTECTED]> writes:
> However, we also need to address the issue of how processes initially
> submit log messages to their local syslog daemon. In this case, the
> receiver is still a syslog daemon, but the sender is an application
> process which doesn't have a queue and can't be expected to retry
> transmission or handle asynchronous notification of submission
> failure.
Yes, (this explains my feelings about handling errors, far better than
I did. In some cases you really do want to know, and be able to
handle a failure - but not all applications can, need or want to.)
> Under a low system load, this mechanism should work fine because there
> are plenty of system resources to field these requests. But in a
> high-load situation, the response time for the syslog daemon to ACK
> If the process is something like a webserver, it might choose to
> submit best-effort messages like the current syslog so that it can go
> on serving webpages. OTOH, if someone is trying to break into the
Some sort of message 'type-of-service' (status-info, program error,
high-priority) over and above any particular message's
severity/priority level. Or maybe they're one and the same?
(Of course, a developer will probably consider that all their log
messages are of the utmost importance. But we can try.)
Darren Reed <[EMAIL PROTECTED]> writes:
> I think that is something which the server for the connection needs to
> inform the client about and to which the client can but agree or close.
That could be a use for (another poster's reference to) the PPP
protocol means of negotiating:
-> I'd like 20, please
<- No, but I'll offer you 15
-> Give me 15
<- Ok, you've got 15.
kind of thing, with a successful implementation allowing the
administrator to configure the general parameters whatever they may
be, and specific limits for an application X.
James.
