[relp] RELP Windows Port

[Rainer Gerhards]

> -----Original Message-----
> From: relp-bounces at lists.adiscon.com [mailto:relp-
> bounces at lists.adiscon.com] On Behalf Of chris mr
> Sent: Monday, June 16, 2008 9:40 PM
> To: relp at lists.adiscon.com
> Subject: [relp] RELP Windows Port
> 
> Rainer,
> I was just looking into RFC3195 when I found the RELP rsyslog
> implementation.  I think this is an excellent move forward with system
> logging.  This is a much simpler implementation than RFC3195; well
> done!

Thanks - though one has to admit that there still exists a number of subtleties. But RELP saves quite some overhead because it doesn't need channels and also does not support message fragmentation (which is not a constraint given the  scope of what it is intended to).

> I see that you are relying on the client to re-transmit the message if
> client-server transaction fails.  You also mention the server issuing
> commands (hints) to the client and I think that is a great idea.  The
> server should be able to re-request the message from the client

Once a message was successfully acked, this is no longer possible. Otherwise, the client would need to have infinite memory.

> , as
> well as the client should receive acknowledgment that the server
> processed the message successfully.  Receipt acknowledgment of the
> message at the transport layer is not enough.  I think a successful
> logging protocol should extend itself all the way until the last
> byte of the message is written to storage and verified.

That's true, but comes at additional subtleties. For example, what determines success of an application transaction? Is it successful execution of all associated actions? What if actions run asynchronously? What if they invoke remote instances which in turn invoke other remote instances?

However, this is not really the business of RELP. The question here is when the upper layer issues the ACK. It may hold the ACK until some define success is reached (and as I have written, there may be multiple definitions of success).

Rsyslog in theory is capable of handling all that together with the relp lib. In fact, it already is extremely reliable, if configured correctly. You just need to be sure that the relp server puts messages into a disk-based, non-lossless queue. This mode brings you much further than most logging applications even consider worth thinking about ;)

The rest will hopefully some time materialize - but it obviously is something that I would like to see sufficient requests from the field, because it does not make sense to implement that complex beast if nobody needs it.

> I particularly like the relp_software field which will help with
> application specific message parsing.
> Am I reading this correctly that a successful transaction will be
> a minimum of eleven packets or can the offers part be bypassed?

I haven't counted that frames lately, but that number sounds a bit high (if looking at the relp level, if you count TCP acks and setup, it is probably correct). The offer phase is mandatory, as it enables the peers to adopt to each other and select a working set of communications capabilities.

The bottom line is that you need some overhead to make the reliability happen. But even if it is at 11 frames, that shouldn't really be a problem except if you drop connections very often. I expect a typical RELP session to be active for 24 hours or so.

HTH
Rainer
> -chris
> 
> 
> 
> _______________________________________________
> RELP mailing list
> http://lists.adiscon.net/mailman/listinfo/relp
> 
> NOTE WELL: all postings are provided under the terms of the GNU Free
> Documentation License. See listinfo page for details.
> 
> IF YOU DO NOT LIKE THIS POLICY, DO NOT POST TO THE LIST.