Reliable Event Logging Protocol: Difference between revisions

Revision as of 00:29, 21 May 2013

Revision as of 07:40, 22 May 2013

Line 2:

==Overview==

RELP uses [[Transmission Control Protocol|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 be 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 arehave nowsince knowbeen bypublished baseas RFC 5424, but were not named at that time).

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

==Technical Details==

RELP is inspired by RFC 3195 syslog and RFC 3080. During initial connection, sender and receiver negotiate session options, like supported command set or application level window size. Network event messages are transferred as commands, where the receiver acknowledges each command as soon as it has processed it. Sessions mymay be closed by both sender and receiver, but usually should be termintedterminated by the sender side. In order to facilitate message recovery on session aborts, RELP keeps transaction numbers for each command, and negotiates which messages need to be resent on session reestablishment.

The current version of RELP does not specify native TLS support. However, practical deployments use wrappers around the RELP session in order to provide that functionality.

==Implementations==

Only publicallypublicly available implementations are listed. This list is not exhaustive.

* librelp - the original C RELP library

Line 29:

{{Uncategorized|date=May 2013}}

[[Category:Internet protocols]]

[[Category:Internet standards]]

[[Category:System administration]]