El Protocolo de registro de eventos confiable ( 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 confiable de mensajes de eventos. Se utiliza con mayor frecuencia en entornos que no toleran la pérdida de mensajes, como la industria financiera .
RELP utiliza TCP para la transmisión de mensajes. Esto proporciona una protección básica contra la pérdida de mensajes, pero no garantiza la entrega en todas las circunstancias. Cuando se interrumpe una conexión, TCP no puede detectar de manera confiable si los últimos mensajes enviados realmente llegaron a su destino. [1] A diferencia del protocolo syslog, RELP funciona con un canal de retorno que transmite información al remitente sobre los mensajes procesados por el receptor. Esto permite a RELP saber siempre qué mensajes se han recibido correctamente, incluso en el caso de que se interrumpa la conexión.
RELP se desarrolló en 2008 como un protocolo confiable para la comunicación entre 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 fundamental para crear RELP. [2] Originalmente, se consideró que RFC 3195 syslog asumiría esta parte en rsyslog, pero sufría de una gran sobrecarga y falta de soporte para los nuevos estándares de syslog de IETF (que desde entonces se han publicado como RFC 5424, pero no se les dio nombre en ese momento).
Aunque RELP inicialmente estaba destinado únicamente al uso de rsyslog, se adoptó de forma más amplia. [ cita requerida ] Actualmente, las herramientas tanto para Linux como para Windows admiten RELP. También existen 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 informático. [ cita requerida ]
RELP está inspirado en RFC 3195 syslog y RFC 3080. Durante la conexión inicial, el emisor y el receptor negocian las opciones de sesión, como el conjunto de comandos admitidos o el tamaño de la ventana a nivel de 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 emisor como por el receptor, pero por lo general deben ser finalizadas por el lado del emisor. Para facilitar la recuperación de mensajes en caso de interrupción de la sesión, RELP mantiene los números de transacción para cada comando y negocia qué mensajes deben reenviarse al restablecerse la sesión.
La versión actual de RELP no especifica compatibilidad nativa con TLS . Sin embargo, las implementaciones prácticas utilizan contenedores en torno a la sesión RELP para proporcionar esa funcionalidad. [ cita requerida ]
Solo se enumeran las implementaciones disponibles públicamente. Esta lista no es exhaustiva.