Reliable Event Logging Protocol
Reliable Event Logging Protocol (RELP) is a networking protocol for computer data logging in computer networks. It is based on the ideas of the syslog protocol but extends it to provide reliable delivery of event messages. It is most often used in environments where message loss is not acceptable, like in the financial industry.
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 be reliably detected if the last messages sent have actually reached their destination. 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.
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 (which have since been published as RFC 5424, but were not named at that time).
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.
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.
Only publicly available implementations are listed. This list is not exhaustive.
- "Why you can't build a reliable TCP protocol without app-level acks". 2008-05-29. Retrieved 2013-05-06.
- "RELP - the reliable event logging protocol". 2008-03-13. Retrieved 2013-05-06.