[6772] in www-talk@info.cern.ch
Re: More on HTTP-NG timings
daemon@ATHENA.MIT.EDU (Simon E Spero)
Tue Nov 22 15:08:22 1994
Date: Tue, 22 Nov 1994 20:52:44 +0100
Errors-To: listmaster@www0.cern.ch
Reply-To: ses@tipper.oit.unc.edu
From: Simon E Spero <ses@tipper.oit.unc.edu>
To: Multiple recipients of list <www-talk@www0.cern.ch>
koblas@netcom.com (David Koblas) writes:
>
>I have a few issues with HTTP-NG, on on a protocol level it didn't appear
>as if there was a PROTOCOL-VERSION byte in the headers. Such things like
>this are always important.
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)
