Hi Ian,
Shame I wasn't aware of UUIDs. It looks like a very credible solution.
RFC 4122 even defines a URN namespace for it. And it is provided on
many platforms straight away. I think I'll stick to it until I find
someone who convinces me it is not good for some reason.
Thanks a lot for the hint.
Konstantin.
On 29 Apr 2008, at 10:53, Ian Holsman wrote:
Hi Konstantin.
I'm about to look at the same issue for my employer.
for my version I was planning on using apr_uuid_get that uses
uuid_create / uuid_generate function to generate a unique value.
have you looked at this function?
regards
Ian
Konstantin Chuguev wrote:
Hi,
I'm developing a solution generating unique IDs for the requests to
websites that are not only clustered but also geographically
dispersed. This implies the following:
- the website's virtual host section on each Apache server has the
same ServerName which is mapped by DNS to different IP addresses
using various methods, geo-proximity, round-robin, etc.
- the virtual host's IP address is normally but not necessarily *;
- the actual IP address the Apache listens to for this virtual host
is normally, but not necessarily, an intranet address (behind a
load balancer).
After analysing the format of the ID generated by mod_unique_id,
and reading the module's source code, I have a feeling that this
module has serious flaws if used in my situation.
No offence to the authors, I'm sure the module serves its purpose
just right for the majority of its users. But as it seems that it
doesn't do this in my case, I thought I'd better ask if someone
knows why.
I understand that the module is relatively old and likely has been
ported from a pre-2.0 version, when no APR library existed, and
this might explain its design. I'd be glad if someone could either
confirm this or
explain why it has been done like that.
Now to the point of my question. The unique_id_rec structure that
contains the binary representation of the unique ID consists of the
following fields:
unsigned int stamp;
unsigned int in_addr;
unsigned int pid;
unsigned short counter;
unsigned int thread_index;
1. Why use unsigned int timestamp when there exists apr_time_t
which is 64 bit and seems to be at least 1 microsecond accurate?
Surely there is unsigned short counter which helps if there is more
than one request coming to the same IP address / PID / thread per
second, but still I can hardly see this as a better design.
2. Why use unsigned id pid plus unsigned int thread_index if there
exists long r->connection->id? thread_index is in fact produced by
doing htonl((unsigned int)r->connection->id), but MPMs seem to
ensure the child_id is included there already! While it is just 4
bytes long compared to the 8-byte pid/thread_index combination,
still it is guaranteed to be unique among all worker threads of the
Apache server in the system. And I don't think this particular
field needs converting to the network byte order.
3. Using unsigned int in_addr with the server-side IPv4 address
works well in the single cluster in the IPv4 network only. What if
only IPv6 is being used in the intranet? What if multiple dispersed
clusters with exactly the same intranet IP addressing schemes serve
the same website? Please correct me if I'm wrong but I think the
following structure would represent the unique website more
correctly:
- union {struct in_addr, struct in6_addr} local_ip_addr: the IP
address of the local side of the HTTP connection;
- union {struct in_addr, struct in6_addr} dns_ip_addr: one (any?)
of the IP addresses that are mapped to the website's domain name in
DNS. The latter can be omitted if the former IP address is public.
Does anyone see any flaws in the design where the following
structure is used?
apr_time_t stamp; // 8 bytes, converted to network byte order
long connection_id; // size depends on architecture: normally
4 or 8 bytes, doesn't need htonl
union {struct in_addr, struct in6_addr} local_ip_addr; // 4
to 16 bytes
[union {struct in_addr, struct in6_addr} dns_ip_addr;] // 0
to 16 bytes
Comments and suggestions are appreciated.
Konstantin Chuguev
Software Developer
Clickstream Technologies PLC, 58 Davies Street, London, W1K 5JF,
Registered in England No. 3774129
Konstantin Chuguev
Software Developer
Clickstream Technologies PLC, 58 Davies Street, London, W1K 5JF,
Registered in England No. 3774129
