On Aug 26, 2007, at 10:02, Matt Sergeant wrote:
On 25-Aug-07, at 8:37 PM, Guy Hulbert wrote:
The mod_uniqueid module in apache has quite a reasonable
implementation.
There is a perl implementation on CPAN (in my directory).
I'm assuming Ask is referring to Apache::Usertrack, which does this:
Hmn, I did - but that's not what I had in mind. I mixed up
mod_usertrack and mod_unique_id in my head.
From mod_unique_id.c (in Apache):
/* Comments:
*
* We want an identifier which is unique across all hits, everywhere.
* "everywhere" includes multiple httpd instances on the same machine,
or on
* multiple machines. Essentially "everywhere" should include all
possible
* httpds across all servers at a particular "site". We make some
assumptions
* that if the site has a cluster of machines then their time is
relatively
* synchronized. We also assume that the first address returned by a
* gethostbyname (gethostname()) is unique across all the machines at the
* "site".
*
* We also further assume that pids fit in 32-bits. If something uses
more
* than 32-bits, the fix is trivial, but it requires the unrolled
uuencoding
* loop to be extended. * A similar fix is needed to support
multithreaded
* servers, using a pid/tid combo.
*
* Together, the in_addr and pid are assumed to absolutely uniquely
identify
* this one child from all other currently running children on all
servers
* (including this physical server if it is running multiple httpds)
from each
* other.
*
* The stamp and counter are used to distinguish all hits for a
particular
* (in_addr,pid) pair. The stamp is updated using r->request_time,
* saving cpu cycles. The counter is never reset, and is used to
permit up to
* 64k requests in a single second by a single child.
*
* The 112-bits of unique_id_rec are encoded using the alphabet
* [EMAIL PROTECTED], resulting in 19 bytes of printable characters. That
is then
* stuffed into the environment variable UNIQUE_ID so that it is
available to
* other modules. The alphabet choice differs from normal base64
encoding
* [A-Za-z0-9+/] because + and / are special characters in URLs and we
want to
* make it easy to use UNIQUE_ID in URLs.
*
* Note that UNIQUE_ID should be considered an opaque token by other
* applications. No attempt should be made to dissect its internal
components.
* It is an abstraction that may change in the future as the needs of
this
* module change.
*
* It is highly desirable that identifiers exist for "eternity". But
future
* needs (such as much faster webservers, moving to 64-bit pids, or
moving to a
* multithreaded server) may dictate a need to change the contents of
* unique_id_rec. Such a future implementation should ensure that the
first
* field is still a time_t stamp. By doing that, it is possible for a
site to
* have a "flag second" in which they stop all of their old-format
servers,
* wait one entire second, and then start all of their new-servers. This
* procedure will ensure that the new space of identifiers is
completely unique
* from the old space. (Since the first four unencoded bytes always
differ.)
*/
/*
- ask
--
http://develooper.com/ - http://askask.com/
