El protocolo de registro de eventos fiable ( RELP ), un protocolo de red para el registro de datos informáticos en redes informáticas, amplía la funcionalidad del protocolo syslog para proporcionar una entrega fiable de mensajes de eventos. Se usa con mayor frecuencia en entornos que no toleran la pérdida de mensajes, como la industria financiera .
RELP usa TCP para la transmisión de mensajes. Esto brinda protección básica contra la pérdida de mensajes, pero no garantiza la entrega en todas las circunstancias. Cuando se cancela una conexión, TCP no puede detectar de forma fiable si los últimos mensajes enviados han llegado realmente a su destino. [1] A diferencia del protocolo syslog, RELP funciona con un canal secundario que transmite información al remitente sobre los mensajes procesados por el receptor. Esto permite que RELP siempre sepa qué mensajes se han recibido correctamente, incluso en el caso de una interrupción de la conexión.
RELP se desarrolló en 2008 como un protocolo confiable para la comunicación de rsyslog a rsyslog. Como explica el diseñador de RELP, Rainer Gerhards , la falta de transmisión confiable en el syslog estándar de la industria fue una motivación central para crear RELP. [2] Originalmente, se consideró que RFC 3195 syslog ocupaba esta parte en rsyslog, pero sufría una gran sobrecarga y faltaba soporte para los nuevos estándares IETF syslog (que desde entonces se publicaron como RFC 5424, pero no se nombraron en ese momento) .
Si bien RELP inicialmente estaba destinado únicamente para el uso de rsyslog, se adoptó más ampliamente. [ cita requerida ] Actualmente, las herramientas tanto en Linux como en Windows son compatibles con RELP. También hay implementaciones internas para Java. Si bien RELP aún no está formalmente estandarizado, se ha convertido en un estándar de la industria para el registro de computadoras. [ cita requerida ]
RELP está inspirado en RFC 3195 syslog y RFC 3080. Durante la conexión inicial, el remitente y el receptor negocian las opciones de la sesión, como el conjunto de comandos compatibles o el tamaño de la ventana del nivel de la aplicación. Los mensajes de eventos de red se transfieren como comandos, donde el receptor reconoce cada comando tan pronto como lo ha procesado. Las sesiones pueden ser cerradas tanto por el remitente como por el receptor, pero por lo general debe ser terminada por el lado del remitente. Para facilitar la recuperación de mensajes en las cancelaciones de sesión, RELP mantiene los números de transacción para cada comando y negocia qué mensajes deben reenviarse en el restablecimiento de la sesión.
La versión actual de RELP no especifica la compatibilidad con TLS nativa . Sin embargo, las implementaciones prácticas usan contenedores alrededor de la sesión RELP para proporcionar esa funcionalidad. [ cita requerida ]