Thursday, February 05, 2009

On the reliable plain tcp syslog issue ... again

Today, I thought hard about the reliable plain TCP syslog issue. Remeber? I have ranted numerous times on why "plain tcp syslog is not reliable" (this link points to the initial entry), and I have shown that by design it is not possible to build a 100% reliable logging system without application level acks.

However, it hit me during my morning shower (when else?) that we can at least reduce the issue we have with the plain TCP syslog protocol. At the core of the issue is the local TCP stack's send buffer. It enhances performance but also causes our app to not know exactly what has been transmitted and what not. The larger the send buffer, the larger our "window of uncertainty" (WoU) about which messages made it to the remote end. So if we are prepared to sacrifice some performance, we can shrink this WoU. And we can simply do that by shrinking the send buffer. It's so simple that I wonder a shower was required...

In any case, I'll follow that route in rsyslog in the next days. But please don't get me wrong: plain TCP syslog will not be reliable if the idea works. It will just be less unreliable - but much less ;)

1 comment:

JGT said...

If you are looking for a reliable transmission method, look at how the RADIUS protocol (RFC2865) handles the issue.

Busy at the moment...

Some might have noticed that I am not as active as usual on the rsyslog project . As this seems to turn out to keep at least for the upcomi...