Paul A Vixie writes:
explorer and navigator have both done this since their respective 3.0's. however, they both still open N (where N defaults to 4) connections to the same server rather than depending on persistence and limiting themselves to 1 connection per server. so they will reuse their N connections for more than one fetch if there are more than N objects to be fetched from some server to fill out one "page". phil howard says this is a feature, but now that the size of a graphic can be given in its enclosing page it is no longer nec'y to get the graphic objects' headers before laying out the page, and i think that for the good of the network and the origin servers it would be nicer if these browsers could learn to serialize their fetching a LOT more.
Merely laying out the page isn't enough. It helps, and unfortunately some browsers (e.g. explorer) don't seem to even use this feature correctly. Having a bunch of blank positions where buttons are supposed to be doesn't give one any idea a button is supposed to be there, or even where "there" is, until some stuff, either the first pixels of that button, or the buttons around it, are getting loaded. Seeing only the top button of a table of buttons doesn't help to find where the active space is for the green one you know you always click on, or the one with the person's head. One approach that can be used to get around this is to make all the images be very small low res only files, and include some Javascript that will detect when those are loaded and then start the medium res loading, and after that, the high res loading. But I would not want to depend on people who have degrees in graphical arts to be in a position to manage network bandwidth controls, so other fundamental solutions are still needed. My multiplexing protocol would need a persistent TCP connection. There would be 254 different subchannels. A byte code of 255 is a flag to the multiplex control. 255,255 means a real 255 in the current subchannel. 255,0 means EOF in the current subchannel. 255,N means a switch to subchannel N (1-254). The sender can determine how many bytes can be sent in one subchannel before switching to another. If more features might be required, such as per subchannel flow control, then more codes could be reserved (it might be good to reserve all of 200-254 for now). AFAIK, no valid HTTP would begin with a 255,1 so this multiplexing would likely be detectable dynamically against HTTP. -- Phil Howard | suck8it5@no57ads3.com w1x8y9z0@no0place.com no95ads7@anyplace.org phil | eat90me5@noplace5.net w5x2y1z6@noplace0.net end5it87@lame5ads.net at | ads9suck@spammer5.com no67ads8@anyplace.net end1it03@spam0mer.edu milepost | ads1suck@nowhere3.net end5ads3@anyplace.org stop1727@nowhere8.com dot | stop6it4@anywhere.edu w5x2y9z4@spammer8.org end0it35@noplace8.org com | stop6ads@noplace2.com stop0it9@anyplace.edu stop9ads@dumbads1.net