I have done an implementation of SOAPTransport using the HTTPClient v0.3-3 package from <http://www.innovation.ch/java/HTTPClient/>. HTTPClient supports persistent connections (and many other cool features).
Are you wondering how much time you would save by using persistent connections? The easy way to find out is to run ping from your client machine to your server machine. You will save approximately that much time. If you're on a LAN, that might typically be under 1 ms, so there's not much point. If you're on a WAN, it will be something larger. For example, from home over DSL with VPN, I get ping times of about 100 ms to hit servers on my office LAN. My measured difference in request/response RTT is also about 100 ms. The savings is in the "3-way handshake" of connection establishment. There is client SYN answered by server SYN. The client also has to ACK the server SYN, but that doesn't further delay the client from sending request data. The connection establishment and ping both happen low in the stack, so one is a good approximation of the other. A couple things to be aware of if you contemplate persistent connections. (I welcome comments on these.) [[The server I talk to is a piece of custom code that we run either as an IIS ISAPI extension or as an Apache httpd module. I mention that so that there is no confusion about server-side toolkits of any stripe. We're not using one except for homegrown stuff.]] When I talk to IIS with a persistent connection, IIS closes the server after every request. I haven't looked into this too much because it's not that important in my scenarios, but I think it's because we don't buffer everything up and tell IIS the content-length, nor do we take the necessary application steps to do chunked encoding. In such circumstances, I believe that IIS will always behave the way I'm seeing. In other words, IIS doesn't implicitly do chunked encoding nor does it buffer up application writes and compute the content-length. So, whether you will see persistent connections actually, uh, persist when IIS is the server actually depends on server toolkit behavior (about which I know very little). You don't actually lose any ground in trying persistent connections; you just don't gain anything if they get closed every time. When I talk to Apache httpd (2.0.40) with a persistent connection, I get a chunked response. HTTPClient handles that just fine. Again, our server side software doesn't do anything about that, so I believe Apache is automatically doing the chunking (based roughly on writes from our module). Unfortunately, there is often an effect which kills performance when talking to Apache. I believe it is Nagle's algorithm on the server combined with delayed ACK on the client. In the first packet of the response, Apache sends the HTTP headers and the payload (if it fits). The (entire) payload is one HTTP "chunk". It does not send the second packet containing only the zero-length final HTTP "chunk" until it gets an ACK for the first packet. Due to delayed ACK, the client doesn't ACK the first packet until a 200 ms timer fires. I think this is Nagle's algorithm on the server (even though Apache seems to disable Nagle's algorithm) because it follows a classic odd/even packet count pattern. If the payload spills over into a second packet, TCP sends both packets immediately and they get ACK'd immediately by the client, which in turn lets TCP send the final packet with the final zero-length chunk. (Nagle's algorithm doesn't care how many full packets are involved. It only cares about partial packets and will only let you have one non-ACK'd partial packet.) I also think this is not TCP slow start because the pattern repeats if I do multiple identical requests with the same persistent connection (if it were slow start, I would expect the delay to evaporate after 1 or 2 requests). Of course, I could be wrong and it could be some completely different mechanism delaying the final zero-length chunk. It does always come immediately after the ACK of the first packet, though, which leads me to think it's the server's TCP and not something in Apache. (In case you are wondering, I'm looking at packet data from tcpdump.) Since there are lots of short responses in the land of SOAP requests (and in any event, it's hard to structure your request with the aim of forcing an even or odd number of packet responses :-), this is likely to be a big problem with persistent connections hitting Apache servers. I would be really happy to have my nose rubbed in some obvious fix or workaround for this. -- [EMAIL PROTECTED] (WJCarpenter) PGP 0x91865119 38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>