To: [EMAIL PROTECTED]
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 t
> [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
[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 th
cc: [EMAIL PROTECTED]
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. Th
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL 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
[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 creat
[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
ED]>
Subject:Re: Cheap and unique
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 fr
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 pr
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
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, $PI
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*
* 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 t
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.
An
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 {
Apache->pu
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 ea
> >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
>
>
>>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
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.
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]>
>
>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
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. An
hnson [mailto:[EMAIL PROTECTED]]
Sent: 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 "Program
Hello,
OCNS>You 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,
A
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:
> Chec
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
[EMAIL 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 c
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 c
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
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(1
30 matches
Mail list logo
