On Mon, Nov 29, 2010 at 00:56, Andrej van der Zee <andrejvander...@gmail.com> wrote: > Hi Sorin, > > Thanks for your reply. > >> >> request_rec->connection->id is a long int that is unique. It is built >> from the process_id and thread_id of the apache thread that serves the >> request. > > Will this be unique for MPM worker across control processes / worker threads?
Yes. It's unique across sites too as it contains the server IP address as well. >> However, a client may open several connections to the server >> during the same transaction, so I guess this does not help you much. > > My assumption is that both client and server have KeepAlive enabled. > In that case, should there "generally" not be just one connection > only? As other people remarked, browsers open several connections even if they and the server support keepalive. Just clear your browser cache and surf to any site while running netstat in a console. >> There's a module called unique_id. It creates a string that is stored >> in the req->subprocess_env and can be logged with "%{UNIQUE_ID}e". It >> encodes the request timestamp, the connection->id, the _server_ IP and >> a random number. It does not encode the client IP or port. However, if >> you combine it with the client-IP and client port that you can log as >> well in the same log line, you could, probably, extract what you want >> after some log-postprocessing. > > So I can decode the unique ID and extract the connection ID from it? I > guess so... > >> >> Different clients behind a NAT router will use different ports. >> However, based solely on ports, you won't be able to distinguish >> between two different clients on one hand or one client that makes >> several connections on the other hand. A method that is used by some >> of my colleagues in order to distinguish between different clients >> (but I don't know much about it, so I can't tell you more) is to >> analyse the TCP header of the packet in order to extract the TCP >> sequence numbers. > > That sounds interesting but as far as I can see this information is > not available in the application layer. Hard to imagine, but are there > any tricks to get this information in Apache modules? Or are your > colleagues using sniffers such as tcpdump? Indeed it is not available at the application layer. I do not know how they do it. S