Darren, > There's a third possibility, which is to use the pathID to determine > where the message originated from. That is, you *are* a > relay, you just > happen to generate some messages yourself, as well. This approach has > the advantage of having only one <iam> to match up with the > SASL login. > (I.e., if your SASL login included the type information, > neither of your > above approaches would work.)
Oops... good point (I have to admit I haven't thought about this because I am not yet ready to implement these... ;)). > I think the choice is in part dependant on what you "mean" in some > sense. Are you simply relaying messages locally, or are you actually > generating them yourself? That is, I could see someone using *both* #1 > and #2, with one channel for messages like "the relay syslog process > just had a configuration change", and another channel for > messages like > "the machine on which the relay syslog process is running just lost a > disk drive". Actually, I am thinking on the later case. We have a solution that does a lot of monitoring which includes a syslog subsystem. So it can relay syslog messages but it also is a "device" in the spirit of syslog, that is it e.g. creates messages based on text file data and Windows event log data picked up as well as e.g. detection of went-down remote services and such. So that piece of software acutally *is* both a relay as well as a device. Given the SASL implications, it looks like I even should create two SESSIONS to the remote peer (option #4 ;)), one saying it is a device and one saying it is a relay. Would this work with the SASL auth? (I guess this is a quick yes/no for you, so I do not yet read the specs...) I guess option #5 would be to have the device part of my application forward messages to the relay part. This would effectively add one path element to the overall path and I have the impression that this is probably the worst way to do it. Any more comments? Rainer
