StringTheory : MakeGuid not so unique?

[AtoB]

Hi All,

I'm posting this here is I ran into this when working with services in NetTalk. I created a webservice endpoint that needs a GUID for a record-ID and I ran some stress tests on this method. I noticed the backend sometimes gave errors "primary key not unique". Actually restarting the nettalk server several times in a row creates quite a lot of not unique guids.

I've looked at the StringTheory (latest version 3.36) procedure "SeedRandom" (see below) and I think (!) this is maybe where things go wrong. I'm not sure but several things seem strange (but I'm not an expert here ....):

- the "stSeedRandom" calll apparently always takes 0 as an argument (see the self.trace line I added), the clock() and ProcesId seem of no influence ...
- the MouseX/MouseY always return 0 (which maybe is not strange for a nettalk server)
- the seed is "only" determined once (via the static variable), is there a reason for doing this once?

At least the 16 char GUID is not unique enough ...


StringTheory.SeedRandom Procedure()
s1 long,auto
  code
  stSeedRandom(band(clock(),bshift(stGetCurrentProcessId(),24)))  ! process Id's are 16 bit, so we only get the low part of the process ID here
  self.trace('mouseex : ' & mousex() & ' stGetCurrentProcessId() : ' & stGetCurrentProcessId() & ' argument :' & band(clock(),bshift(stGetCurrentProcessId(),24)))
  loop mousex() TIMES         ! take some random calls off the random sequence just to add some more variability
    s1 += Chr(Random(1,100))
  end
  loop mousey() TIMES
    s1 += Chr(Random(1,100))
  end

[Jane]

Looks like an intermittent bug.
He changed the bshift from 16 to 24, which usually creates a negative number in a Clarion LONG and leaves the lower 24 bits zeroes.  And then BANDs that with clock(), which returns 0.
Works if the bshift is 16 instead.  But even that might have a problem at, say, 20 minutes after midnight when the clock() would still be low enough to BAND to zero.

First screen shot shows a test app that happened to get a process ID of 4484. 
24-bit shift results in 75,229,036,544 which overflows a Clarion LONG and leaves a LOT of zeroes to be BANDed (pic from Windows calculator showing result of shift).

Jane

[AtoB]

The randomness indeed probably is dependant on when the server is actually started.

Out of curiousity:

- this "seed" is the thing that needs to be rather random (as each seed as a "fixed" array of numbers in it)?
- the s1 += chr(random(1,100)) is only to get a more random start in the array?
- effectively this could also be s1 = random(1,100), as the s1 is going nowhere?

[Bruce]

Fixed in 3.37
thanks

Bruce