Actually, there was no protocol information at all in the documents posted :-)
That's all in the protocol spec, rather than the architectural overview..
A Draft of the spec will be out before the BOF - honest :-)
The current protocol-level options don't use version numbers; instead, they
use capabilities. This is similar to the gnu style autoconf approach of
finding out what features a machine supports, instead of using the system
name to look up the feature list in a table).
>A) Over the Internet transfering 5 10MB files simultaniously is better
>done with 5 .. 20 TCP connections. Becuase, if one TCP packet is lost
>only 1 TCP connection drops into a timeout<->resend cycle.
This is true except... why did the one TCP packet get lost? Virtually all
packet loss on the Internet is caused by congestion. (I'll need a bit to
dig out the reference for the actual numbers, unless Dave Crocker knows them
off the top of his head?)
>
>
>I think the better thing to keep in mind with HTTP-NG is that is
>a control channel that can transmit data (MGETs...) but has mechanisms
>for allow easy creation of auxilariy data channels. Sounds simple,
>but it should be supportable from a library level.
I can't quite follow this - how does this differ from the mechanism I proposed,
which allows results to be either a session_id for data on this connection
or a url for a media specific transport connection. If the HTTP-NG connection
has reserved bandwidth, then it can split time between the data channels as
it sees fit.
>Also, how does your benchmarking of HTTP-NG compare with HTTP supporting
>MGETs? I would expect that they are within 10% of each other, since
I haven't done the comparison, but I'd expect around a 25%-30% differce for
a document with a few images. A lot depends on how MGET is spec-ed, how
big the HTML file is, and how big the icons are.
MGET (pure and simple)
connect, get foo.html, get-data, close, connect, mget *.gif, get data, close
HTTP-NG
connect, get foo.hml, get-data, get *.gif get-data. close)