RE: Channel response serialization

First of all, thanks for your considered reply. Its difficult to find people
I can have this level of conversation with so forgive me for delving further
into this below...

> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Jered Floyd
> Sent: Thursday, July 25, 2002 10:01 AM
> To: Paul Andrews
> Cc: [email protected]
> Subject: Re: [BEEPwg] Channel response serialization
>
>
>
> > It struck me that that wasn't really the purpose of channels. I got the
> > impression that channels were intended to have a semantic purpose - and
> > that's how I would like to use them, e.g. channel 0 is a
> control channel -
> > you wouldn't allocate multiple control channels arbitrarily to
> get around
> > the serialization restriction otherwise how would BEEP know
> that they were
> > control messages?
>
> Hm.  I defer to Marshall on any statements regarding intent, but I
> think that semantic binding is only one of the purposes of channels.
> While the binding of some specific profile to each channel provides
> semantic separation between channels, the serialization of messages on
> a single channel allows the client to pipeline requests with a
> guaranteed execution ordering.

That's a good point that hadn't really sunk in for me. In fact the SOAP over
BEEP example does precisely that, i.e. binds a particular SOAP message to a
profile, then you can get multiple channels bound to that profile.

One way of looking at that is that there is a virtual channel that is the
sum of all channels that share a profile.

>
> In fact, this is how we make use of multiple channels when performing
> complex tasks in our protocols.  We manage a pool of channels bound to
> a given profile, and then assign messages to 'free' channels
> (i.e. ones with no currently outstanding message), while honouring
> data dependencies by pipelining requests on a single channel.

I take your point about the benefit of having enforced pipelining for
certain types of problem.

>
> While I don't fundamentally object to the idea of allowing
> out-of-order replies on a channel, I don't want to lose the guarantee
> of in-order processing of subsequent messages on a single channel.  I
> posit that in any protocol that allows for volatile data, there are
> few situations in which one is likely to have in-order processing with
> out-of-order replies (while maintaining correctness).

I agree. But that is not a requirement in my case. Or at least, where it is
a requirement there are fairly simple mechanisms for enforcing ordering that
do not require support from the communications protocol.

>
> Question: If we remove the restriction on reply-ordering, do we then
> also allow frames on multiple RPYs or ERRs to be interleaved?  That
> seems like the logical next step.  Of course, then for parallelism we
> really ought to allow frames of MSGs to be interleaved.  But, then
> we're back to something that looks like the channel mechanism, though
> less explicitly managed!

So are you saying that MSGs are essentially sent serially, regardless of how
many channels are open? i.e. if I am sending a very large message on one
channel, othe channels will have to wait to before they can send anything?

>
> > Finally the restriction on reply ordering seems to be arbitrary
> and forces
> > people like me to put in a lot of extra work that we wouldn't
> have to do if
> > the restriction wasn't there (I know, we all want something for nothing
> > :-) ).
>
> PermaBEEP goes a step further towards enforcing this by not allowing
> the application to retrieve the next message on a channel until it has
> initiated a reply to the last message delivered to the application.
> (Note that is initiated, not fully sent.)  This decision was a bit
> contentious, but I think it best serves developers in that it prevents
> them from shooting themselves in the foot in a system that dispatches
> requests into a server framework.

But I like shooting myself in the foot! I guess the point is that
serialization is something that can be layered on top of parallelism, but
not vice-versa. At least when operating within the constraints if a single
framework.

>
> If you think it would be interesting to explore, I believe it would be
> relatively easy to modify PermaBEEP to remove both this and the
> restriction on reply ordering.  I'm not sure there's a lot of value in
> it, though.  (Hm, and I really must roll the 0.9 release soon; I meant
> to do that last month.)

Interesting point. I guess I tend to think that standards are written in
stone. I could act unilaterally to remove the serialization requirement but
I guess I need to convince myself that I'm not talking rubbish and I would
also prefer to work within the standards process if at all possible.

Once again, thanks for taking the time to think about this.

>
> --Jered
>
> _______________________________________________
> BEEPwg mailing list
> [email protected]
> http://lists.beepcore.org/mailman/listinfo/beepwg