RE: Channel response serialization

OK. I don't want to rat-hole on this so: do I understand correctly that you
are proposing to amend the RFC to make serialization on a channel optional?

The rest of my points below all boil down to the same thing (I think).
Namely that it would be a shame to have to layer another communications
protocol on top of BEEP. Naturally I'd be layering an application protocol
on top, but then that's the whole point.

By the way if we end up using BEEP in our projects I'd be more than happy to
get involved either at the standards level or at the library level assuming
that no-one objects of course (and assuming that my boss didn't mind and our
legal department etc. etc.).

Thanks for taking the time to reply by the way.

> -----Original Message-----
> From: Marshall Rose [mailto:[email protected]]
> Sent: Thursday, July 25, 2002 11:38 AM
> To: Paul Andrews; [email protected]
> Cc: Marshall Rose
> Subject: Re: [BEEPwg] 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
>
>