Rainer Gerhards wrote:
> 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...)
Well... it depends. :-)
If you log into that SASL as "xyz.example.com", then one session with
one or two channels is fine. If you log into that SASL as
"xyz.example.com/relay" then yes, you'd likely need two separate
sessions if you also wanted to act as a device. It's more an interop
thing than a definitive yes/no answer.
Having multiple channels means you wind up with a more complicated BEEP
library underlying your implementation. (Allowing only one active
channel at a time simplifies things somewhat, in terms of window
management and buffering and such.) But my personal preference (i.e.,
how I was thinking of it when I wrote the initial spec) would be to use
a separate channel for each device or relay, or to use separate path
elements. It doesn't really make much sense to keep flopping who <iam>
back and forth over one channel. Indeed, I no longer even recall why it
was felt desirable to allow multiple successful <iam> messages on one
channel.
Obviously, if you're also supporting syslog-raw, you'll need multiple
channels as well, and you might potentially want a channel (as yet
undesigned) for configuration of the relay itself, specifying where
different types of packets go, etc.
--
Darren New, San Diego CA USA (PST)
Don't take home left-over tripe.
It'll just digest itself before
you get around to eating it.
