Re: Channel response serialization

hi. first, i think the simplest solution is to simply define a beep feature
that gets negotiated during the greeting that relaxes the serial processing
requirement.


> 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. The server process the requests in parallel and sends
> responses to the requests as soon as it can so that senders don't block on
> the slowest response. I think this answers your question about MSG/ANS. My
> reading of the RFC implies that although multiple ANS can be sent in any
> order to a single MSG. The processing of multiple MSGs on one channel is
> still performed serially, right?

true. but i was perhaps too subtle in my explanation. darren's use of
MSG/ANS in the syslog profile is rather inspired: the server sends a MSG and
the client streams back zero or more ANS.

now, if i wanted to do your application with a vanilla beep engine, i would
have each side send a MSG to the other. i would then allow each side to put
their requests and responses in the ANSs that get sent back. although
there's an extra level of wrapping here (you put request numbers in the data
you send and the BEEP msgno's are opaque), you can implement whatever policy
you want all over one channel...


> Now I could use a pool of channels. But this seems wrong for several
> reasons:
>
> 1. I would like to use channels for semantic purposes - i.e. they are
> strongly associated with the meaning of the message. 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.

i'm not really sure i understand the concern, even though i agree with the
first sentence. you can certainly define a profile that says each MSG/RPY
contains an opaque blob (or whatever you want).


> 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.

firewalls, redirectors (IP address shifting), NATs, etc.


> 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 agree. hence your original comment about defining a new BEEP feature...

/mtr