From chris.misztur at yahoo.com Mon Jun 16 21:40:26 2008 From: chris.misztur at yahoo.com (chris mr) Date: Mon, 16 Jun 2008 12:40:26 -0700 (PDT) Subject: [relp] RELP Windows Port Message-ID: <849473.98311.qm@web63703.mail.re1.yahoo.com> 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! 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, 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. 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? -chris From chris.misztur at yahoo.com Mon Jun 16 22:33:55 2008 From: chris.misztur at yahoo.com (chris mr) Date: Mon, 16 Jun 2008 13:33:55 -0700 (PDT) Subject: [relp] Windows Port 2 Message-ID: <155967.53975.qm@web63707.mail.re1.yahoo.com> Doh... I forgot to ask. What about a Windows port of RELP? Chris From rgerhards at hq.adiscon.com Tue Jun 17 13:51:02 2008 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 17 Jun 2008 13:51:02 +0200 Subject: [relp] RELP Windows Port In-Reply-To: <849473.98311.qm@web63703.mail.re1.yahoo.com> References: <849473.98311.qm@web63703.mail.re1.yahoo.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA30921B@grfint2.intern.adiscon.com> > -----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.