Reliable Event Logging Protocol


Reliable Event Logging Protocol, a networking protocol for computer data logging in computer networks, extends the functionality of the syslog protocol to provide reliable delivery of event messages. It is most often used in environments which do not tolerate message loss, such as the financial industry.

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 aborts, TCP cannot reliably detect whether the last messages sent have actually reached their destination.
Unlike the syslog protocol, RELP works with a backchannel which conveys information back to the sender about messages processed by the receiver. 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. 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.
While RELP was initially meant solely for rsyslog use, it became adopted more widely. 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.

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 may be closed by both sender and receiver, but usually should be terminated 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 publicly available implementations are listed. This list is not exhaustive.