Re: Channel response serialization

I'm not adding terribly much here from the message I just sent, but
I'll add my $0.02.

> The application is one where many (i.e. hundreds or thousands) of
> independent entities on one peer wish to send a request to a remote
> peer acting as a server.

I believe that a (perhaps dynamically managed) pool of channels is the
right solution here.

> 1. I would like to use channels for semantic purposes - i.e. they are
> strongly associated with the meaning of the message.

I'm not sure I follow what you mean by this.  Is it that your profile
is not stateless, and so each channel has some 'defaults' that make
multiple channels operating with the same profile notable and
distinct?  If that's the case, multiple channel pools are necessary.

> If I don't do that then I have to layer another addressing mechanism
> on top of that provided by BEEP. BEEP, itself, associates channels
> with message purpose by assigning channel 0 as the control channel.

If the profile is stateless, but the messages are indistinguishable as
independent entities (i.e. the same data sent on different channels
could have different actions), it sounds like this is a case for more
than one profile.

> 2. If I'm going to have a pool of channels, why not just have a pool of
> sockets instead? OK, I know there are some reasons but the more that I have
> to layer on top of BEEP, the less compelling is the argument for using it.

This is a straw man.  The resource overhead of a channel, once
running, is negligible to that of a socket.  BEEP allows up to 2^31
channels per connection; TCP/IP allows only 2^16 ports per address.

> 3. If I can implement parallel MSG/RPY over a single logical channel, then
> BEEP could do it over a single BEEP channel and save me the bother.

I think the complexity of maintaining a channel pool is not as bad as
you think, but I'm still curious as to what you meant back in point 1.

--Jered