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.
While it's great that you've created a session based control protocol,
so that you can take advantage of all of the years of development into
congestion control that TCP uses. There are a few small issues...
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.
B) If one were transmitting real multimedia object over the chanels,
having only one identified channel for data transmission make it harder
to do bandwidth reservation, since it is harder to determine if the
channel is a text file or a video stream.
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.
--- 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 most of the time saving is probably comming from the reduction in TCP connection creation. David --koblas@homepages.com