Re: Channel response serialization

Paul Andrews wrote:
> 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.

...

> 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 could send one MSG with a GET listing *all* the URLs it wants to
retrieve from that server. The server could put each response into a
separate ANS. The ANS can be returned in any order, interleaved. However,
the browser would not get any responses to the second GET until all
responses to the first GET had been received. (It would also be difficult to
abort cleanly without dropping the TCP connection.)
 
> 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.

This is how the core of the BEEP-C library works. If you reply out of order,
your reply is just queued in the library until you have everything in order.
You can even process and queue chunks in interleaved order, with the first
response being picked out of the stream, then the second response being
sent.

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

No, he's saying that if you're allowing multiple MSGs being processed at
once, then the next logical step is to allow multiple MSGs to be sent
concurrently. Otherwise, you're holding up the second MSG while waiting for
the first MSG to go out over the wire. If the first MSG is very large and
the second MSG is small and fast to process, you might be able to get the
response from the second MSG before you even finish sending the first MSG.
But that's not how it works now, because once you start sending the first
MSG, you have to finish sending it.

Right now, you can start sending a MSG on a second channel before the MSG on
the first channel is finished.

> I would
> also prefer to work within the standards process if at all possible.

You are working within the standards process. Look at the name of the
mailing list. :-)

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

Things to be thankful for, #37:
   No sausage was served at the Last Supper.