Reliable Event Logging Protocol: Difference between revisions

Revision as of 11:02, 6 May 2013

Revision as of 21:42, 7 May 2013

Line 2:

==Overview==

RELP uses [[TCP]] for message transmission. This provides basic protection against message loss, but does not guarantee delivery under all circumstances. When a connection is aborted, it cannot reliably detected if the last messages sent have actually reached their destination.<ref>{{cite web |url=http://blog.gerhards.net/2008/05/why-you-cant-build-reliable-tcp.html |date=2008-05-29 |title=Why you can't build a reliable TCP protocol without app-level acks |accessdate=2013-05-06}}</ref>. Contrary to the syslog protocol, RELP works with a backchannel, over which information of messages processed by the receiver is conveyed back to the sender. This enables RELP to always know which messages have been properly received, even in the case of a connection abort.

==History==

RELP was developed in 2008 as a reliable protocol for [[rsyslog]]-to-rsyslog communication. As RELP designer [[Rainer Gerhards]] explains, the lack of reliable transmission in industry-standard syslog was a core motivation to create RELP.<ref>{{cite web |url=http://blog.gerhards.net/2008/03/relp-reliable-event-logging-protocol.html |date=2008-03-13 |title=RELP - the reliable event logging protocol |accessdate=2013-05-06}}</ref>. Originally, RFC 3195 syslog was considered to take up this part in rsyslog, but it suffered from high overhead and missing support for new IETF syslog standards (which are now know by base RFC 5424, but were not named at that time).

While RELP was initially meant solely for rsyslog use, it got wider spread adoption. Currently tools both under Linux and Windows support RELP. There are also in-house deployments for JAVA. While RELP is still not formally standardized, it has evolved into an industry standard for computer logging.