reply body modification

From: Michael Ulbrich <mul@dont-contact.us>
Date: Sat, 06 May 2006 11:15:08 +0200

Hi all,

I'm running an experimental version of squid-2.5.STABLE12 with patches
that allow for modifiying the client reply body. Patches have been
applied mostly to client_side.c and especially clientSendMoreData().

Since I need a chunk of body data which meets certain size criteria, I
check the size parameter on entry to clientSendMoreData() and return
without sending anything to the client if not enough data is available.
For practical reasons, I chose to wait until CLIENT_SOCK_SZ (default 4k)
bytes are passed via buf.

Returning from clientSendMoreData() is accomplished by calling

clientWriteComplete(fd, NULL, 0, 0, http);
memFree(buf, MEM_CLIENT_SOCK_BUF);
httpReplyDestroy(rep);
return;

This has been tested and works ok up to CLIENT_SOCK_SZ=16384.

A further increase of CLIENT_SOCK_SZ to 32k leads to a strange
phenomenon, in that reading the reply of the origin server often seems
to starve out at sizes around 17k. Although the origin server keeps on
sending data and seems to fill the receiving socket buffer (netstat
claims that sufficient data is available for reading), the associated
file descriptor never comes back via comm_poll() signalling that new
data has arrived.

AFAIK this strange behaviour only occurs, when data is read from a
distant server and httpReadReply() is called several times with small
chunks of data (e.g. 12x1448bytes). Serving the same data from a local
httpd, seems to work flawlessly since the receiving buffer is mostly
filled by only one call to httpReadReply().

I'd very much appreciate, if somebody could give me any pointers where
to look further and probably find a solution to this problem.

TIA + best regards ... Michael Ulbrich
Received on Sat May 06 2006 - 04:04:44 MDT

This archive was generated by hypermail pre-2.1.9 : Thu Jun 01 2006 - 12:00:04 MDT