Re: APPLCORE: An architectural question

spreitze@parc.xerox.com wrote:

> > I wonder how much complexity the protocol software can actually hide from the
> > application.
>
> It can actually reduce complexity, by replacing two problems (multiple connections and multiple outstanding requests on a connection) with one (multiple connections).
>
> > It seems that structures for tracking all of the outstanding
> > requests and handling their responses are bound to make it into the application
> > code
>
> Most server-side software that takes itself seriously allows for multiple connections to be active at once.  I think general-purpose client-side software should too.  So "tracking all of the outstanding requests and handling their responses" is something that will be done anyway, as a consequence of handling multiple active connections.
>
> > especially if multiple responses to the same request are allowed.
>
> That's an entirely different can of worms, orthogonal to muxing.
>
> > On another note, has anyone here had a chance to look at my XP draft?
>
> I have.
>
> >  ... It tags requests and responses, as a wire protocol must, but a
> > software implementation could still take the "mux" approach.
>
> No, the kind of muxing that's done in HTTP-NG's muxing protocol isn't about code in the peers, it's about what happens on the wire.  It interleaves messages chunk by chunk (where a "chunk" is only a piece of a message, and choosing the chunking is up to the peers).  An advantage of this fine-grained interleaving is that one message doesn't get held up by slow or blocked consumption of another.  You can't get that back in software if your wire protocol says one message has to be sent in its entirety before another can be started.

Taking clues from your message (as a lousy substitute for actually poring over the HTTP-NG work), I gather that the idea is for clients and servers to think they are creating multiple connections, when in fact everything gets routed over the same connection?  That should be a big improvement for the web, although it does solve the same problem that TCP does already when there are multiple real connections open at once.

Another approach is for a higher-layer application protocol, or the application itself, to choose when to use multiple requests and when to open another connection.  Just like the choices involved in writing multithreaded code that uses a serial resource like a system event queue.

Received on Tuesday, 9 February 1999 13:58:32 UTC