> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Gerrard Geldenhuis
> Sent: Wednesday, April 02, 2008 5:25 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] RELP vs plain tcp syslog
>
> Hi
> Thanks, that is good to know. Worth keeping in mind. I was under the
> impression tcp was the miracle cure for udp unreliability but it seems
> not.
>
> There is very expensive software out there that can do guarenteed
> packet
> deliver over tcp...
Well... RELP can *really* do the trick. It needs some help in the
rsyslog engine to work under all cases, that is when the relp stack is
terminated (when the client rsyslog is shut down). But that isn't rocket
science and has just been pushed back by more urgent work (securing the
channel).
So far, relp does single ack, that is the server ack's every packet back
to the client. Client discards packets only after ack. So when a session
breaks, we know what the server has processed. If, however, some of the
acks get lost, we resend packets that the server already processed,
resulting in some mild message *duplication* (we currently have a 128
packet app-layer max window and typically acks come in rather quickly).
To work around this, the client must ack the server's acks
(double-acking). That sounds scary, but is not. It's also not
performance intense and the protocol is modeled that those with
ultra-slim bandwidth can turn it off and live with the message
duplication scenario. If double-acks are active, relp client and server
will go into a recovery phase after reconnect negotiation, in which
mutally acked package numbers are exchanged. To do so, the client must
provide a session cookie back to the server. This is a potential attack
vector and thus I'd like to have secure transport in place before I do
it. Once the recovery negotiation is done, client and server know, and
have discarded, what each other peer has processed. The remaining
packets are re-sent, but under the same reliability settings. So if the
connection breaks at this point again (or during the renegotiation),
we'll simply go into another recovery phase until we finally succeed. It
is of course important that session caches be persisted to disk when an
engine stops - that will be part of rsyslog. The recovery produced
itself is librelp.
Once this is done, and with proper rsyslog queue settings, sufficiently
stable hardware and sufficient disk space, I guarantee (not in a lawyers
sense, though ;)) that you'll never lose a message nor get a duplicate.
This is when I think we have achieved our reliability goal. If all goes
well... summer? ;)
Rainer
>
> tibco is one I have seen before.
>
> Regards
>
> > -----Original Message-----
> > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards
> > Sent: 02 April 2008 15:35
> > To: rsyslog-users
> > Subject: [rsyslog] RELP vs plain tcp syslog
> >
> > Hi folks,
> >
> > I just blogged about the unreliability of plain tcp syslog. This may
> be
> > interesting for at least some of you:
> >
> >
> http://rgerhards.blogspot.com/2008/04/on-unreliability-of-plain-tcp-
> sysl
> > og.html
> >
> > Rainer
> > _______________________________________________
> > rsyslog mailing list
> > http://lists.adiscon.net/mailman/listinfo/rsyslog
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog