:Re: Cheap and unique
[EMAIL PROTECTED] wrote:
I've been following this conversation and I'd like to clarify whether my
idea (since I and others want to do this as well) would be use an
incrementing counter for uniqueness. Then also store a bit of secret
randomness, concatenate both values
[EMAIL PROTECTED] wrote:
I would have sent both to the client. The sequence would be *the* id and
is guaranteed to be uinique by the database (or whatever else is around
that does this reliably). The idea is that by combining the random secret
with the ID and sending the digest with that the
[EMAIL PROTECTED] wrote:
digest source might be able to locate the bits just by trying a lot of
them. I would expire them after a while just to prevent that from
happening by stating that if there is a 15 minute session, new random bits
are generated each five minutes.
I missed the start of
]
cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject:Re: Cheap and unique
[EMAIL PROTECTED] wrote:
digest source might be able to locate the bits just by trying a lot of
them. I would expire them after a while just to prevent that from
happening by stating
Ken Williams wrote:
If you have the additional requirement that the unique values shouldn't
be easily *guessable*, that becomes a very hard problem, precisely
because random and unique are such poor friends. Usually people
just cheat by generating a large random ID such that the
it away after a period.
Does that sound right?
Josh
Perrin Harkins [EMAIL PROTECTED]
05/06/2002 01:15 PM
To: Ken Williams [EMAIL PROTECTED]
cc: OCNS Consulting [EMAIL PROTECTED], [EMAIL PROTECTED], David
Jacobs
[EMAIL PROTECTED]
Subject:Re: Cheap
[EMAIL PROTECTED] wrote:
I've been following this conversation and I'd like to clarify whether my
idea (since I and others want to do this as well) would be use an
incrementing counter for uniqueness. Then also store a bit of secret
randomness, concatenate both values together and create a
PROTECTED]
Sent: Monday, May 06, 2002 11:45 AM
Subject: Re: Cheap and unique
[EMAIL PROTECTED] wrote:
I've been following this conversation and I'd like to clarify whether my
idea (since I and others want to do this as well) would be use an
incrementing counter for uniqueness. Then also store
On Wednesday, May 1, 2002, at 06:46 AM, OCNS Consulting wrote:
Of course srand seeds rand. And yes, it is a good way to generate
random numbers for a one time application RUN.
The original poster is not looking for random, he's looking
for unique. These are in many ways *opposite*
Good morning.
Ken is correct - I am not looking for random, I am looking for unique.
Unique and sequenced would be ideal, but it's tricky because if I use
$i++.$IP_address.$parameter.$PID
{$i is global, $IP_address is the server address, $parameter is a
parameter that was just passed in,
David Jacobs wrote:
Good morning.
Ken is correct - I am not looking for random, I am looking for unique.
Unique and sequenced would be ideal, but it's tricky because if I use
$i++.$IP_address.$parameter.$PID
{$i is global, $IP_address is the server address, $parameter is a
David Jacobs wrote:
I'm converting a few CGI scripts that used the PID as a
cyclical unique
number (in concert with TIMESTAMP - so it was TIMESTAMP.PID).
Our goal is to find a replacement function that is extremely cheap
(cheaper than say, random(100)) and will never repeat.
Any
* David Jacobs [EMAIL PROTECTED] [2002-04-30 18:31]:
A global counter hanging around is a good solution, but not perfect if
we deploy on multiple servers.
That depends on what you initialize the global to; if you do something
like the last octet of the ip of the vhost and increment it by the
Hi there,
On Tue, 30 Apr 2002, David Jacobs wrote:
I'm converting a few CGI scripts that used the PID as a cyclical unique
number (in concert with TIMESTAMP - so it was TIMESTAMP.PID).
Our goal is to find a replacement function that is extremely cheap
(cheaper than say, random(100))
David Jacobs wrote:
I'm converting a few CGI scripts that used the PID as a cyclical unique
number (in concert with TIMESTAMP - so it was TIMESTAMP.PID).
Our goal is to find a replacement function that is extremely cheap
(cheaper than say, random(100)) and will never repeat. Any
Check your Programming in PERL book. Specifically, the srand function.
RB
-Original Message-
From: David Jacobs [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 30, 2002 3:39 PM
To: [EMAIL PROTECTED]
Subject: Cheap and unique
I'm converting a few CGI scripts that used the PID as a
PROTECTED]]
Sent: Tuesday, April 30, 2002 2:44 PM
To: David Jacobs
Cc: [EMAIL PROTECTED]
Subject: Re: Cheap and unique
David Jacobs wrote:
I'm converting a few CGI scripts that used the PID as a
cyclical unique
number (in concert with TIMESTAMP - so it was TIMESTAMP.PID).
Our goal
OCNS Consulting wrote:
Check your Programming in PERL book. Specifically, the srand function.
'random' ne 'unique'
A random function could return the same number 10 times in a row. It's
very unlikely, but it could happen. That's the definition of random.
- Perrin
You could try - Math::TrulyRandom CPAN module.
RB
-Original Message-
From: Perrin Harkins [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 30, 2002 4:08 PM
To: OCNS Consulting
Cc: David Jacobs; [EMAIL PROTECTED]
Subject: Re: Cheap and unique
OCNS Consulting wrote:
Check your
Hello,
OCNSYou could try - Math::TrulyRandom CPAN module.
Perrin's comments still apply. There is no guarantee that a random number
generator of any type (truly random or otherwise) will return unique
values. In fact, one would fully expect repetition after some amount of
time.
Humbly,
: Tuesday, April 30, 2002 4:35 PM
To: Perrin Harkins
Cc: OCNS Consulting; David Jacobs; [EMAIL PROTECTED]
Subject: Re: Cheap and unique
On Tue, Apr 30, 2002 at 04:08:00PM -0400, Perrin Harkins wrote:
OCNS Consulting wrote:
Check your Programming in PERL book. Specifically, the srand
function
David Jacobs wrote:
I'm converting a few CGI scripts that used the PID as a cyclical unique
number (in concert with TIMESTAMP - so it was TIMESTAMP.PID).
Our goal is to find a replacement function that is extremely cheap
(cheaper than say, random(100)) and will never repeat. Any
I'm just curious - what's wrong with the function you're already using?
Steve
Mod_Perl hangs on to it's PID, so it's no longer unique. (I _believe_)
mod_unique_id looks like a good solution, pending performance.
Thanks for your help so far, everyone!
David
Hi,
I'm just curious - what's wrong with the function you're already using?
Mod_Perl hangs on to it's PID, so it's no longer unique. (I _believe_)
TIMESTAMP . $$ . $GLOBAL++
might work just as well (as $global will persist)..
Cheers,
Alex
--
Alex Krohn [EMAIL PROTECTED]
David Jacobs wrote:
I'm just curious - what's wrong with the function you're already using?
Steve
Mod_Perl hangs on to it's PID, so it's no longer unique. (I _believe_)
But the timestamp will make it unique - as long as you're not serving
several requests per second.
If you are,
Mod_Perl hangs on to it's PID, so it's no longer unique. (I _believe_
But the timestamp will make it unique - as long as you're not serving
several requests per second.
I'm building the system so I can be confident up to thousands of
requests/second. Looks like unique_id_module is good
I'm just curious - what's wrong with the function you're already using?
Mod_Perl hangs on to it's PID, so it's no longer unique. (I _believe_)
TIMESTAMP . $$ . $GLOBAL++
I use the above.
If you create a global for the child process then that is adequate since
the PID belongs to the
Michael Robinton wrote:
I'm just curious - what's wrong with the function you're already using?
Mod_Perl hangs on to it's PID, so it's no longer unique. (I _believe_)
TIMESTAMP . $$ . $GLOBAL++
Do not use concat, but sprintf 0 padding. Here is an example that can
happen easily which
In my post I've missed the 'd' token in %05d
Here are a few possible solutions that will do all the work for you
Apache/UUID.pm
--
package Apache::UUID;
use strict;
my($base, $seq);
die Cannot push handlers unless Apache-can('push_handlers');
init();
sub init {
29 matches
Mail list logo
