- From: <spreitze@parc.xerox.com>
- Date: Tue, 9 Feb 1999 11:08:47 PST
- To: Tom Harding <tomh@thinlink.com>
- Cc: spreitze@parc.xerox.com, discuss@apps.ietf.org
> 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? Exactly. > 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. Well, there's not universal satisfaction with how well the current commonly deployed TCP implementations serve the needs of apps that do concurrent request/response protocols. Please do follow the pointer into the HTTP-NG work, which itself builds on a lot of discussion in various IETF circles about whether and what to do in this regard. > 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. That's not an alternative. The mere availability of a message muxing protocol doesn't relieve the higher layer of the responsibility of deciding how to use it. This is a matter of the software in the peers, not the wire protocol (although the design of each naturally influences the design of the other).
Received on Tuesday, 9 February 1999 14:11:06 UTC