Fundamental architecture of a proxy implementing keep-alive.

I have been trying to write a proxy based on the example provided by
junkbuster, because it was relatively short and intelligible, and compiled
on my target system (NT) and then I found that the basic architecture of
junkbuster seems incompatible with the entire Keep-Alive concept.

Junkbuster relies on the connection NOT being kept alive in order to tell
where one request ends and another begins, and fails to translate and act
upon
      - Keep-Alive
      - Connection
      - Proxy-Authenticate
      - Proxy-Authorization
      - TE
      - Trailers
      - Transfer-Encoding
      - Upgrade

Instead it mindlessly passes them along, producing all sorts of nasty
failures.

The first problem with keep-alive is that I do not know how to tell where a
request or response ends, so that do not know when I can throw away state
for the previous request and prepare to translate new state.

RFC 2616 section 4.3 and 4.4 seems to tell me how I can find the end of a
client request or server response, but it is a large complicated scary
prescription, and it is often far from clear to me what they are saying and
what they mean.

Assuming I knew how to solve that problem, my next problem would be that
proxy client connections would have no necessary relationship to proxy
server connections. I could probably make a quick and dirty fix by
terminating my connection with the client whenever the server terminated its
connection to me, but a better solution (because my proxy will have very few
clients) would be to hold the connection to the client open for a very long
time, and reopen the connection with the server if new client requests came
in when the server connection had closed.

So what I am really looking for is example code for translating those
headers, and separating one request from the next.

Of course squid presumably contains such sample code, but it is huge, and
does so many things, that finding and recognizing and understanding the
parts that do things like the things I want to do is going to be hard.

Well, maybe there is not alternative, but if any of you people can suggest
an alternative, or some smaller and more intelligible example, I would be
mighty relieved.

Another problem with the keep alive concept, is that a single connection
does not correspond to a single conversation. The client may send several
requests along a connection before it receives a response. Does it expect
the responses to return along the same connection in the same order? This
is not clear to me from RFC2616

If this is the case then should one keep a single thread handling the single
connection between client and proxy as long as that connection remains
alive, or should one maintain two threads per client connection, one
processing the flow of data from client to server, and one processing the
flow of data from server to client? This is not at all clear to me from the
RFC.

I assume these architectural issues have been discussed and explained in the
archives, but I do not know what keywords to start searching for in the
archives.

Is there anything smaller than squid that correctly handles keep alive?
Received on Tue Aug 24 1999 - 19:43:48 MDT