On Mon, Nov 29, 2010 at 08:56:50AM +0900, Andrej van der Zee 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?
>
> > 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?
This assumption is most likely wrong. Even with keep-alive browsers will
open more than one connection. After all, keep-alive and multi-connect
solve different problems.
> >
> > 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?
No, package assembly is the operating system's job - Apache sees a
stream of octets, not packages.
HTH Ralf Mattes
>
> Thank you,
> Andrej
