RE: Channel response serialization

Thanks for taking the time to think about this, and hopefully I'm not being
too troublesome (or just plain dumb) but there are few people around that I
can work through these sorts of issues with.

I've been trying to think of an example that would illustrate what I am
driving at and I think that a web browser loading a web page works quite
well - it is familiar to everyone and it illustrates what I am trying to say
from the point of view of a client.

So. When a web browser loads an HTML page, that page will have on it many
references to objects that also need to be retrieved in order to fully
render the page. Generally, the layout of the page is known from the HTML
document - all the render has to do is retrieve the various referenced
objects and render them into the space that has been left for them. That, to
me, is the interesting part. A browser parallelises the retrieval of those
objects by opening multiple TCP connections and issuing HTTP/GET commands
down each one. Each connection itself operates serially.

The analogy in BEEP would be to create a profile that specifies the use of
GET. The browser then uses multiple channels to download the multiple
objects. Intra channel communication being serial, inter channel
communication being parallel.

The browser now has essentially the same management problem that it had with
plain old TCP. It has to decide when to create a channel and when to release
it to avoid the overhead of channel creation. It has to queue requests to
each channel to ensure that the requests are written atomically (actually,
that's a supposition). If one response on a channel takes a long time (maybe
the server is drawing a graph into a JPEG and then returning the JPEG)
subsequent responses on that channel will be held up and the page renderer
will have to wait.

On the other hand, if the browser could just use one channel (the GET
channel), down which it could pump requests and from which it could retrieve
responses in any order, the renderer would not be held up (at least not by
the communication protocol). There would be less management overhead - just
the one channel to decide to open and release. There would be no contention
for the use of channels (either writing to them or reading from them).

OK, so the renderer would have to decide just how many objects it was going
to try and draw in parallel, but that decision would be independent of how
it uses a protocol to retrieve the objects it wants to draw. In fact, it
might have a thread pool that it allocates rendering operations to. But the
point is (maybe) that there is only one pool to have to worry about, at
least as far as the browser is concerned.

I guess the point is that the restriction on ordering of responses seems to
be arbitrary when it comes to the actual protocol definition itself. If a
given library feels that it has to impose that restriction, then that should
be up to the library. Though I guess that both ends would have to agree on
any ordering restrictions as part of the session negotiation.

The problem I have on the server side is very similar - i.e. there is an
engine that can process many requests in parallel. Now, I receive multiple
requests on one channel and I could process them in parallel. If the API
will not deliver me a request until it has received a response to an
outstanding request, it is effectively throttling me. Maybe the API will
deliver me multiple requests but relies on me returning response strictly in
order - now I have to throttle myself. If the API will deliver multiple
requests and accept responses in any order then it will have to throttle
itself in order to meet the serialization requirement.

OK the client could use multiple channels, but then the client is
effectively dictating how many operations the server can perform in
parallel.


> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Jered Floyd
> Sent: Thursday, July 25, 2002 10:21 AM
> To: Paul Andrews
> Cc: Marshall Rose; [email protected]
> Subject: Re: [BEEPwg] 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
>
> _______________________________________________
> BEEPwg mailing list
> [email protected]
> http://lists.beepcore.org/mailman/listinfo/beepwg