Fairness

[Paullas]

please dont list tags/names as i woudlnt want to pul the thread. keep it sensible please and informative...

by all means post how it is done though

 

[philipp]

Philip, Nominet comes in many guises, the admin side of it is by far the most customer centric company I have ever dealt with, they are for the most part faultless. The technical side of the company ... well least said, soonest mended. My advice if you do like fair play is to blow the whistle on here, name and shame so to speak, it worked last time and we nearly got an apology ... well maybe not, it may have been a load of lame excuses.

Agreed, I am actually quite a fan of the company, and it's a shame to see their technical group let the side down like this.

Come on Nominet, fix your systems

P.

 

[retired_member6]

I said months back that it's blatently obvious, search einstein something may come up.

 

[philipp]

Have you wrote to them telling them about the flaw? When you point faults out to Jay he usually credits you with being a genius rather than seeing his department as being technically inept

Yes I sent Jay an email describing the problem in detail, and it wasn't a rant or anything like that. I'm still hoping to hear back from him.

P.

 

[FC Domains]

I didn't make the 303 bug public. I just kept hammering on at Nominet that their drops were not random, because they kept saying that they were.
I got called all sorts of names by Jay, until he finally apologised.

I suspect that it's very difficult to make drops truely random, because somewhere in the system they are going to get caught in a time dependant job.

 

[aqls]

Famous "apology" thread.

Several explanations why they couldn't spot the non-randomness of the random drop script. (it was mathematical error).

http://www.acorndomains.co.uk/drop-catching-domain-names/4015-drop-frequency-5.html

-aqls-

 

[SF]

I would be in favour of an investigation, however reading that old thread it seems even when Nominet investigate deeply it seems they miss the obvious.

 

[philipp]

I suspect that it's very difficult to make drops truely random, because somewhere in the system they are going to get caught in a time dependant job.

Okay, I'll bite. Here's an algorithm for doing it better:

1. Shortly before midnight, create a list of all domains due to be deleted from the database the following day, I'll call this the drop list.

2. For each domain in the drop list:

2.1. Pick a random second for the name to drop between 1 and 86400. I'll call this the drop second.
2.2. Insert the domain and its drop second into a drop queue​

3. Sort the queue by the random second picked in 2.1

4. At midnight, enter a loop for each domain in the sorted array:

4.1. Sleep for seconds between now and drop second assigned to the domain at the front of the queue.
4.2. Wait a random number of milliseconds
4.3. Issue the delete command
4.4. Remove the domain at the front of the queue​

That would do it; it's hardly rocket science. Might need to adjust the timings slightly to compensate for 4.2 but I can't see a problem there.

P.

P.S. I understand the difference between random and pseudo-random, but that's a bit out of scope here - and entropy gathering isn't too bad - so let's not go there in this discussion

 

[retired_member3]

There must be more so called bugs as theres still a select few with an advantage?

 

[aqls]

Why drop over just one day?

Why is it that to determine the 92 day drops you have to have extra information that some people have and others don't.

-aqls-

 

[philipp]

Why drop over just one day?

Why is it that to determine the 92 day drops you have to have extra information that some people have and others don't.

-aqls-

Please let's not get off-topic here. I don't know why they have a policy of dropping on one day, but the fact is that the drops are not really random. That's what we need Nominet to fix as the current system is abysmal.

P.

 

[aqls]

process.

Select a number of domains to drop tomorrow.
(non-random event and non-random time)
As the day progresses the drops will become less and less random as in the last 3 seconds everyone will know exactly which domain is due to drop.
Sort domains in random way
(room for non-randomness to creep in)
Put into queue as you mentioned
Set delete script with sleep numbers as you mentioned.
To randomise by seconds and not to nanofractions of a second, means there is a big skew to the same millisecond.
(Possibility that system slows down when alot of good domains dropping, so slight skew to later)
Script may be quicker when array is just one or two names rather than full complement of thousands.

You'd need to know their system to explain things like the 303 bug.

-aqls-

 

[aqls]

ok, didn't see the wait random number of milliseconds - I presume that is to prevent round second bias I mentioned.

(I concede, I can't see anything really wrong with your method )

-aqls-

 

[tifosi]

This puts me in a quandary. Would Nominet allow me to run systems for other members where I store and can access data for my own use? A definitive ruling could be helpful.

Isn't that what one company is already doing. How they use the results from their customers is apparently their own business.

S

 

[FC Domains]

But it won't be the only task running on the server. Others with various priorities will also take up CPU time and these will be switched in and out at fixed time slices.
Then the server will also be running Cron jobs, which might even make drops start to queue.

Then the same thing happens again, as the database updates.

I expect there are several overlaid patterns and if you can be bothered to work them out, you will get more drops.

Even it started out as truely random, I don't see how it could end up that way.

 

[retired_member26]

Okay, I'll bite. Here's an algorithm for doing it better:

1. Shortly before midnight, create a list of all domains due to be deleted from the database the following day, I'll call this the drop list.

2. For each domain in the drop list:

2.1. Pick a random second for the name to drop between 1 and 86400. I'll call this the drop second.
2.2. Insert the domain and its drop second into a drop queue​

3. Sort the queue by the random second picked in 2.1

4. At midnight, enter a loop for each domain in the sorted array:

4.1. Sleep for seconds between now and drop second assigned to the domain at the front of the queue.
4.2. Wait a random number of milliseconds
4.3. Issue the delete command
4.4. Remove the domain at the front of the queue​

That would do it; it's hardly rocket science. Might need to adjust the timings slightly to compensate for 4.2 but I can't see a problem there.

P.

P.S. I understand the difference between random and pseudo-random, but that's a bit out of scope here - and entropy gathering isn't too bad - so let's not go there in this discussion

Sorry but I can't stand without writing a comment. This method can not improve anything unless you have a killer script which completes SMTP under 40 ms. Assume I gave you an exact drop time for name xxx.co.uk if you have a lousy script it has no meaning to know the exact drop time. At the end of the day you only have a chance of checking a name for every 60 ms, assume you also have a TAG for your grandma grandpa fiance then you can just use their DAC quota and make that 60 to 15 ms.

This drop game is screwed and beaten to the death. It needs a complete overhaul like dropping weekly names in a week not in a day.

Some people again will attack but I am sure they use DAC quotas with one certain TAG.

TurNIC

 

[grantw]

If Nominet can't get this random thing right they may as well just drop all domains in alpabetical order, 1 second apart. In fact, why dont they just do that anyway - everyone orders their catch list alphabetically and hammers the DAC @ 60ms for 20 minutes a day??

Grant

 

[SF]

Yes I am really confussed now - what would you recommed to get sorted to stand a decent chance of catching... decent hosting and script? - or work out a drop pattern? if there is one?

 

[Paullas]

i think dropping domains over a weekly period rather daily is a great idea, also tag the requests going in.

be interesting if nominet reply to this thread and explain if there system has been flawed again, just to put us members minds at rest as we havent seen them on here for ages now.........

 

[aqls]

Two options:

a) Randomise drops over a running 3 or 4 day (or week) account.

b) For every domain, randomise the drop time and timestamp this drop time (but do not actually drop the domain at this time)

c) Nearest automaton request (or email registration request) after release timestamp gets a release code for that domain. That request is given a gap of say 50ms before the next in line gets given a release code etc. (first one is still open) If the domain remains unclaimed after say 2 seconds from start of release codes then drop it so it is open to all.

As far as I can tell this takes out most of the problems caused by "mathematical errors", concurrent processes, flooding of email servers, etc.

It also gives advantage to those that really want a domain and that would run requests for a single domain for a week.

It does however put more pressure to getting more than one TAG account. A weekly drop spread over a week will still give advantage to those with more TAGs.

This would take alot of the strain off Nominets servers and so they would be able to allow more freedom with for instance registering and dropping domains.

It also takes alot of the skill out of the game, so perhaps they should introduce a quiz . . .

The second option is to leave it as it is but reveal any inconsistencies publicly.

So any non random events that can be discovered by third parties are fair game, but any that are only available to those with many clients/many TAGs/ close relationships with Nominet etc are made available to all.

-aqls-


-
_ _ (tin hat)