On Thu, 2003-09-11 at 13:27, Adrian Chadd wrote:
On Wed, Sep 10, 2003, Henrik Nordstrom wrote:
One thing that'll improve the IO throughput for COSS quite a bit
is to redo the storeRead/storeWrite interface to try and do
large IO transfers (where large is as much as the store can do).
On Wednesday 10 September 2003 20.32, J.Smith wrote:
Apart from CONNECT, the paper mentions the GET method as well. Not
sure what you exactly mean by allowing the session to be logged
correctly.
Squid needs to be told exacly how many bytes was transferred, and when
the transfer to the client
- Original Message -
From: Henrik Nordstrom [EMAIL PROTECTED]
Squid does application level splicing with multiple receivers (one or
more clients + cache) per server connection. It does not use any
kernel level splicing primitives.
Thanks for the information, I was unaware of that.
On Wed, Sep 10, 2003, Henrik Nordstrom wrote:
It is my opinion that there is many better ways of optimizing proxy
class I/O without resorting to kernel level splicing. For example
it would be very interesting to see a I/O mechanism not involving
copying of data on each read/write combined
Hi.
I just have a quick question about the squid internals, and I couldn't find
anything about this anywhere so I decided to just 'go ask the people who
wrote the code'.
;)
Is Squid capable of doing 'TCP Connection Splicing ?', or does it have
support for this on the platforms that provide this
On Tuesday 09 September 2003 22.21, J.Smith wrote:
Is Squid capable of doing 'TCP Connection Splicing ?', or does it
have support for this on the platforms that provide this as a
kernel service (like AIX 5.2) ?
Squid does application level splicing with multiple receivers (one or
more
