Vania wrote in support of server side id generation:
> Moreover, client generated ids may not be unique.
> Two independent clients could generate the same id and
> confuse the server.
My calculations lead me to think differently. Given:
a server that receives 100 unique requests/second
a client that generates ids as: ctime cat'ed with a random number
Let X = the probability of id collision on a server given client
side id generation
Let Y = the probability of id collision on a server given server
side id generation.
Now, besides generation of ids, the server must know when to expire
them. We've seen two reports that place session boundaries (one
as determined by server logs & the other by client side monitoring)
at around 20 minutes, but let's define Z as this parameter.
X is directly proportionate to the time the request is issued plus
the robustness of the random number generator on the clients, which is
a function of bit lengths and algorithms employeed. Either way, this
is rare, and the server can attempt to break ties based upon IPs.
(statistically, I could compute these odds, but would have to choose
bit lengths and algorithms, which is controversial in itself ).
Y depends on the server id generation mechanism. If the current time is
used, than Y is Z times that of X, where Z can be whatever session boundary
you desire, but if Z is too small, you run the risk of incorrectly
terminating a session (i.e., server must ensure unique ids across
the lifespan of the client's navigation, which it can not control -
only the client can reliably do this).
If the server uses an IP scheme, then proxied domains cause problems.
Now, the unique name space for ids is determined by the number of
requests per proxy, which is increasing rapidly.
Thus, the worst case for X is that machines from with a proxied
domain access the same server using the same id. This is a narrow
id space.
The worst case for Y is a fraction of X (where the fraction is the number of
proxied users), but is magnified by the expiration on ids, which overrides
the gains of the fraction, since this must be at least an order of magnitude
larger than a second.
Further more, the generation of unique ids on the server side means
that some shared memory is used, which means locking, which means
blocking. This can only serve to decrease the throughput of servers
(what's the point of issuing unique ids if you turn away half of the users
away?). Additional resources (computational and memory) are consumed
by the management of ids and their recycling.
If a client generates an id, the server simply logs this to file
or the logging module and performs its number one function: object
delivery.
Regards,
Jim.