Hello! >> I wonder the optional RFC2616 pipelining mechanism for requests in >> HTTP/1.1 >> is anything utilized by clients in the real world or just hypothetical? >> Currently no ICS code (client/server) supports it.
> Pipelining use would require changing the state machine in ICS component. At > first glance I don't think it is too much difficult to implement. But > performance would be enhanced only when using threads to serve each request > in the HTTP server component. The thread has to be used not for the entire > client instance but for HTTP request processing only so that pipelining > could start different threads to execute each request. Of course > serialization would be necessary to send the results in the correct order. > Is there any client which make use of pipelining ? I doubt ! I don't know, but I'm sure there are. For example, web page downloaders may do - as this method is less server-expensive (it may use single thread to process all of requests - not in parallel of course, but it may process clients in parallel). In real life, if all clients would make use of pipelining, server CPU and RAM usage would drop significantly (as less connections would be involved) resulting in saturated client connections. I did something like this for TPop3Cli and TNntpCli and observed significant performance boost (I was writing about this some time - year or two - ago). The changes needed for clients are not that large (at least for TPop3Cli and TNntpCli weren't), but for proper usage of this feature, logic had to be extended - performance boost gained this way was still worth it anyway for both clients connected throught classical network connections (ethernet, dialup) and the GPRS ones (as less packets were transmitted, meaning less bytes transferred in both ways). Also note that in a lagged networks performance boost is even more noticeable (user had to wait for every send command and get response steps, and when pipelining is used, user would wait only for two such steps - send all commands and get all responses). The only caveat I find is - if the client's connection throughtput is higher than client's overall performance and client doesn't use multithreading, such actions may lock it (make unresponsive) for as long as responses are comming and are parsed. One way to overcome this is to use multithreading and put connection in a separate thread - obviously. Others include agressive code optimzation (neither "str := str + char" nor frequent progressbar updates allowed...) - what I find difficult for most today's Delphi programmers (the funniest thing is that the same guys say "Delphi is a bad compiler"). -- Piotr Dalek [EMAIL PROTECTED] ---------------------------------------------------------------------- PS. Fajny portal... >>> http://link.interia.pl/f196a -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
