httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: [PATCH] mod_unique_id.c
Date Sat, 16 Aug 1997 22:27:52 GMT
Well no the lower 16-bits of time() are the same if you restart the server
twice in one second.  Actually it's worse than that... if you restart the
server in the same second as a child has spawned then you need some 16-bit

Ok, well... let me try again (I really want a whiteboard!) 

Let (a,b,c,d) be a unique id -- in the order (stamp,in_addr,pid,counter). 
Suppose one invocation spawns a child that starts with unique id
(a,b,c,X).  Then suppose a restart happens, or suppose that time goes
backward at some point in the future (i.e. clock screwed up).  It is
possible that another server might spawn a child that starts with unique
id (a,b,c,Y).  I'm trying to guarantee that X and Y are sufficiently
different that this isn't a problem.

Since a is time(0) you don't get much by using it as a random number or as
a seed. 

Note that for c (pid) to be reused on it requires the server to roll over
its pids.  Not a likely thing to happen in one second. 

Ok I have another idea.  I'm going to start using r->request_time for the
stamp.  I'll continue incrementing the counter as before, and seed it with
16-bits from gettimeofday on boxes with that function.  Boxes without that
function won't get clock-going-backwards protection.  I already have a 1
second sleep in global init to make sure the server protects itself
against the restart problem described above. 

and ... I'll provide 32-bit pid support. grr.  32-bit pids means that I'm
using at least 14-bytes unencoded, and 19 bytes uuencoded. 


On Sat, 16 Aug 1997, Jim Jagielski wrote:

> Dean Gaudet wrote:
> > 
> > I actually need a 16-bit somewhat random integer ... and I figured the low
> > end of tv_usec would be good enough.  Other suggestions are welcome ...
> > but I don't think drand/random are sufficient unless we also seed the RNG
> > with something more random than time(0).  The problem I'm trying to work
> > around are server restarts in the same one second interval... or clocks
> > that have gone backwards... but the latter is admittedly not a huge
> > concern.
> > 
> Hmmm... times() returns clock_t which is usually 32bit. Maybe the
> lower 16bits of that? Most implementations of of gettimeofday()
> just call times() anyway, so times() _might_ be a safer
> alternative.
> -- 
> ====================================================================
>       Jim Jagielski            |       jaguNET Access Services
>           |
>             "Look at me! I'm wearing a cardboard belt!"

View raw message