pr 20, 2002 at 04:30:33PM -0700
On Sat, Apr 20, 2002 at 04:30:33PM -0700, Darin Fisher wrote:
> ahmetaa wrote:
>
> > what is it good for?
> >
>
> see http://mozilla.org/projects/netlib/http/pipelining-faq.html
>
> darin
Some time ago, I sent some mail with some minor nits to Gordon Bennett
about what can be pipelined when. They may be of interest to you.
In this message, I also take issue with the use of the term
idempotent, which is a perennial battle of mine.
I've poked around in the mozilla networking libs a good bit while
implementing Http Extensions. Let me know if you want to geek on
pipelining issues.
--
-eric
([EMAIL PROTECTED])
Feel free to forward this message to any list for any purpose other than
email address distribution.
--- Begin Message ---
I screwed up and gave out the wrong URL at the bottom. URL 2 has
changed - see line 67.
On Fri, Sep 14, 2001 at 09:14:18AM +0200, Gordon Bennett wrote:
> Darin Fisher wrote:
>
> > I'm working toward implementing HTTP/1.1 pipelining for mozilla.
>
>
> Excellent! The only browser I know of which already implements this is
> Amaya - <http://www.w3.org/Amaya/>. It's open source so you may want to
> look at how it does this. Does anyone know of any other browsers that
> support pipelining?
Amaya gets its network layer from libwww [1]. I just published a few
cheesy notes [2] i took when I was working on it Jan 97. I'd be
interested in working with you and incorporating any notes you come up
with.
> > Pipelining can also dramatically reduce the number of TCP/IP
> > packets. With a typical MSS (maximum segment size) of 512 bytes, it
> > is possible to pack several HTTP requests into one TCP/IP packet.
A nice use case is when you have a proxy on your local network. The
client to proxy connection will frequently have an MSS of 1420 or so
(I forget the exact number).
> Nice idea. Amaya only sends 1 request per packet.
Oops, that's probably my bad. I probably won't get around to fixing it
but I'll keep it in mind and feel guilty about it.
> > complete. The HTTP/1.1 spec does not provide any guidelines on the
> > ideal number of requests to pipeline. It does, however, suggest a
> > limit of no more than 2 /keep-alive/ connections per server.
>
>
> Well, Amaya only uses one persistent connection to my proxy, and I've
> seen it pipeline up to *thirteen* GET requests without any problems. You
> could take that as a kind of unofficial W3C recommendation.
We used the libwww robot [3] to test different pipeline sizes when
working on the SIGCOMM 97 [4] HTTP 1.1 Performance paper [5].
"Only idempotent requests can be pipelined, such as GET and HEAD
requests. POST and PUT requests should not be pipelined."
I think idempotent is a word that has been popularized in its misuse
by TimBL. An idempotent operation F has the characteristic that
F(F(X)) = F(X). I think we need to borrow from the german to get the
word we want: hasnosideeffect. A PUT opperation, for instance, is
idempotent but has a side effect.
The danger in putting a POST in the pipeline is that the connection
may go south leaving you with no idea whether the server recieved and
executed the POST and thusly no idea whether to try again. I beleive
it is, therefor, fine to put an operation with side effects at the
head of a pipeline. Henrik did most of pipeline queing logic (i worked
on the underlying data structures) so I don't know if libwww does
this.
I have another HTTP 1.1 client/proxy/server package written in Java
that I'd glad to dust off if it would be interesting to you. I used
it to test queuing algorythms for preventing deadlock in pipelined
proxies. Let me know if it's of interest.
[1] http://www.w3.org/Library
- [2] http://www.w3.org/Team/Eric/HTTP1.1/Implement
+ [2] http://www.w3.org/2001/09/15-HTTP-Impl
[3] http://www.w3.org/Robot/
[4] http://www.acm.org/sigcomm/sigcomm97/program.html#s22
[5] http://www.w3.org/Protocols/HTTP/Performance/Pipeline
--
-eric
([EMAIL PROTECTED])
Feel free to forward this message to any list for any purpose other than
email address distribution.
--
-eric
([EMAIL PROTECTED])
Feel free to forward this message to any list for any purpose other than
email address distribution.
--- End Message ---
