Re: Channel response serialization

"Paul Andrews" <[email protected]> writes:

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

You're welcome... there's no need to apologize; as Darren pointed out,
you're fulfilling the purpose of this list.  And it's always useful to
have more people with an understanding of BEEP, so that it can take
over the world. :-)

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

As long as the channels are stateless, yes.  It's a nice abstraction
to have if your application wishes request parallelism.  You can also
use channel groups, or the pipelining on individual channels, to
provide the same sort of functionality as SCSI's tagged queuing.  "I
want all of these tasks done as quickly as possible, and here are a
few ordering constraints."

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

Not quite, MSGs are sent serially on a particular channel, but frames
on multiple channels may be interleaved.  If we remove the
restrictions on RPY ordering, it seems most sensible to also allow
MSGs and RPYs on the same channel to be interleaved, and then I think
we've gone and lost most of the advantages of having multiple channels
in the first place.  (That is, we get something that is confusing and
complicated.)

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

Metatarsal ballistics aside, while we can implement serialization on
top of a parallel layer, we can't implement pipelining on top of a
parallel layer (because we have to wait for the response to arrive on
a channel before we know we can send the next request and have it be
processed in order.)  I think one of the purposes of the channel
abstraction is to explicitly allow for both the intra-channel
asynchorony of pipelining and the inter-channel asynchrony of
parallelism.  I'd rather not see pipelining go away in favor of
intra-channel parallelism... I don't think it's called for.

(I won't address your web browser example here, as I think Darren and
Marshall did a good job of that.)

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

I'd be happy to point you at the right parts of the code if you'd like
to explore this further, but I really do think that channel pools are
the right way to go about doing this.  But perhaps I'm old and set in
my ways. *grin*

--Jered