Re: APPLCORE: An architectural question

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

Received on Tuesday, 9 February 1999 12:02:35 UTC