Removed catching thread.

[PoshTiger]

I look forward to you posting your response from nominet that I and a whole load more catchers got a while ago.

No-one's going to post any info about how their script is better than other's so it's funny to see members trying to get it.

 

[SFSF is verified member.]

Thats the invincible i know and love welcome back!

 

[PoshTiger]

I do wonder how so many people reading this thread probably aren't getting any work done today. For the avoidance of doubt, I will be writing an email today to Nominet listing membership tags and domain names caught that I would like them to investigate. I will also be following it up with a telephone call to senior management. I want everything forensically investigated and then a decision about a way forward. Call me selfish for attempting to ruin the party but someone was always going to try to do it. Obviously if you've nothing to hide, there's going to be no problem.

i'm on at the moment and the wife isn't speaking to me i've been on my phone all day.

i'm offline now but looking forward to some reading later. ;-)

 

[DaveP]

We all know though that a great system and server only goes so far, much like a pro poker player still needs luck too.

If it's a bug my guess is some very specific latency detection shortly before the domain drops, perhaps for example 100 milliseconds before there's a not so clear indicator it's about to drop, so all one has to do is fire off 100 EPP creates a millisecond apart.

I haven't yet found this indicator though. =)

Edit: Ok, in that case, it's not a bug but a (undocumented) feature.

 

[SFSF is verified member.]

here is my code:

query-= domain.co.uk-avail-register anyone can copy if they want i dont mind?

 

[Retired_Member42]

We all know though that a great system and server only goes so far, much like a pro poker player still needs luck too.

If it's a bug my guess is some very specific latency detection shortly before the domain drops, perhaps for example 100 milliseconds before there's a not so clear indicator it's about to drop, so all one has to do is fire off 100 EPP creates a millisecond apart.

I haven't yet found this indicator though. =)

Edit: Ok, in that case, it's not a bug but a (undocumented) feature.

If I had to guess I'd go with something like this also. Waiting to find out if the domain is available and then sending your reg request is going to be too slow given that 99 other tags could well have got the availability notification back before you. I believe there is a change in the response times when a domain is about to drop.

I must admit I did question whether any of the people who provide hosting catching were utilising others peoples tags in this way. It wouldn't be too hard to get 10 customers on board chasing domains, notice the delay in the response time and fire off the EPP create from your master tag. I can't imagine any other reason drop catchers would encourage more competition for peanuts each month. Providing hosted catching seems counterproductive unless it works to your advantage.

I often run my tag at 60ms and gamble on the drop in the 7 hour window - my script has caught some contested stuff but even at 60ms it has no chance against the major players.

 

[Retired_Member42]

This garbage I keep reading about milliseconds is still making me chuckle. So much so that the cleaner keeps thinking I am laughing at her.

Why is the time being divided in milliseconds instead of picoseconds? The latter was the unit I was working in back when I bothered to drop catch. Anyone trying to suggest that to be effective you need to DAC every millisecond is daft. It would make you more effective than if you didn't but why not go into picoseconds and claim to require even more DAC allowance to cover an even more granular period of time?!

More resources = exponentially better coverage of the overall day, assuming quality of server configuration, quality of "script" and network connectivity are equal. One doesn't have to cover every millisecond of picosecond, one just has to have more coverage overall to have a better chance of noticing an available domain name and registering it prior to someone else.

The timing is only a factor during the polling. Each script will take a different amount of time to react to the availability notification and send the registration request. The route to Nominet will also differ between catchers. It's not just a case of saying let's poll every picosecond and we'll get the domain. At some point, it's out of your hands and the timing is solely down to your server processing, your script processing, the route to Nominet and how long Nominet take to process your request.

You could quite easily poll every picosecond and lost out to a 200ms catcher simply because their server processes faster, their code is better and they have a more direct route, less hops to Nominet.

 

[AssetDomains]

This garbage I keep reading about milliseconds is still making me chuckle. So much so that the cleaner keeps thinking I am laughing at her.

Why is the time being divided in milliseconds instead of picoseconds? The latter was the unit I was working in back when I bothered to drop catch. Anyone trying to suggest that to be effective you need to DAC every millisecond is daft. It would make you more effective than if you didn't but why not go into picoseconds and claim to require even more DAC allowance to cover an even more granular period of time?!

More resources = exponentially better coverage of the overall day, assuming quality of server configuration, quality of "script" and network connectivity are equal. One doesn't have to cover every millisecond of picosecond, one just has to have more coverage overall to have a better chance of noticing an available domain name and registering it prior to someone else.

Maybe this is were I'm being stupid and that's why I never catch but given playing by the rules the maximum you can query is once every 60 milliseconds were do picoseconds come into it please enlighten us

 

[ian]

So would a delayed response to a EPP create request when domain is available (a few seconds rather than milliseconds) suggest a slow connection, or a very close response to catching the drop?

 

[grantwgrantw is verified member.]

Maybe this is were I'm being stupid and that's why I never catch but given playing by the rules the maximum you can query is once every 60 milliseconds were do picoseconds come into it please enlighten us

You should probably re-read the DAC Acceptable Use Policy!

 

[DaveP]

You should probably re-read the DAC Acceptable Use Policy!

But he is right?

http://registrars.nominet.org.uk/registration-and-domain-management/acceptable-use-policy

The maximum query rate is 1,000 queries per rolling 60 seconds recalculated every 5 seconds and a maximum of 432,000 per rolling 24 hours, recalculated every five minutes.

60 * 16 = 960. You can't add a 17th in before the 1000 mark.

 

[Retired_Member42]

Yes I agree. One needs a well optimised server and a well written "script". The way to get the best connection to Nominet, as far as I am aware, is to peer with them (via lonap or linx) and then plug that connection into your drop catching machine directly (running software on the machine to make it perform as a router). That way you have no ISP switch or router in the way of their connection to Nominet (which would also go via their lonap or linx connection, not your own) because when I last checked it wasn't possible to peer with Nominet via any other peering point. For reference, I have done this. I used to peer directly with Nominet via lonap. I know how it performs. Certain things make more of a difference than others though. It's not all equal.

This is my point. The time you'd shave off by having all of the above (good script, server, route to Nom) is going to far outweigh multiple tags polling for availability regardless of how fast they are as sooner or later they're going to get the notification back, hit the wall and then the timing is just down to their setup. This is where I believe the guys who are catching consistently have the advantage. I could run my script polling every picosecond across 100 tags and still not beat the other guys to the registration even though I knew the domain was available before them. Short of there being some kind of signal a domain is about to drop or some strange way of detecting the actual drop time I really think it is just down to an extremely optimised process - all elements and nothing to do with tag gaming.

 

[grantwgrantw is verified member.]

I'll be interested to read the outcome of the investigation Invincible! I don't know what you know but judging by some of your your posts and the fact that you're not dropcatching at the moment I think you're barking up the wrong tree and doing it with a limited view of what's happening.

Totally happy to be proved wrong!

Grant

 

[AssetDomains]

You were bringing milliseconds into the discussion earlier, saying we'd need 200 DAC's to cover each millisecond in the 200ms gap, I believe. My reply was why just break it down to 200ms and why not divide that again into picoseconds and claim one needs even more DAC's to cover that same period of time?

Given that they catch anytime in a 24 hour period and you agreed that drop times were random as far as we all know then there scripts must be polling 5 times a second or 200ms

What was wrong with that assumption.

 

[ian]

Might suggest Nominet's systems slowed down because everyone tried to do the create at the same time. If you want the best connectivity, I feel you need to be peering via linx or lonap. That requires several £thousand investment (lonap setup fees, £2000 a year membership), colo space in THE or THN I'd imagine, an AS number, getting PI space from RIPE, getting another ISP to be your LIR, getting someone to run your cables, buying an enterprise grade router and switch. Those data centres aren't cheap either. I was in THE and then moved to THN.

This all helps, but there was a very obvious change in success when a few domainers started catching everything, so unless linked, I cannot see them all just so happening to invest the vast amounts of money in the setup you've mentioned at the same time. It seemed to centre around a Nominet update, but maybe that was just a coincidence.

 

[ian]

Given that they catch anytime in a 24 hour period and you agreed that drop times were random as far as we all know then there scripts must be polling 5 times a second or 200ms

What was wrong with that assumption.

Based on catch times I've recorded, I would agree this is likely, but why still such an advantage. I've been beaten by presumably 5/sec whilst querying at 32/sec.

 

[ian]

If you've got decent coverage on the maximum speed setting across the day, which can be achieved with 4 tags, and perhaps a few more, you will have better coverage than 1 tag could achieve.

This is true, but no greater advantage over any other catcher that just so happens to be querying at the same 16/sec speed at that same time. You would need a lot more tags to counter that, and the rest.

 

[AssetDomains]

I was asking why do you feel you need just 200 extra DACs to cover every 1 of the milliseconds in that 200ms gap? Why not break that 200ms into picoseconds and then claim you'd need even more DACS (more than 200) to cover each picosecond in that 200ms?

I don't believe one would need so many extra DACs. I do believe that more DAC resources distributed across the day would give exponentially better return at least to a point. So having 10 will be better than having 2 or 3. We almost appear to be forgetting how brief a millisecond is. If you've got decent coverage on the maximum speed setting across the day, which can be achieved with 4 tags, and perhaps a few more, you will have better coverage than 1 tag could achieve.

Because I assumed there was approximately 100 TAGS all polling at the same time each going for a name 5 times a second all being equal which I know its not.
From that 500 requests for the domain per second or one request coming in every 2ms on average.

If supper catcher A got a not available response then in the time between poll's there should have been 100 requests all checking if the name is available if there systems were even half decent they should have been able to register the name long before the 200ms were up my home IP can get a response in 10ms

Looking back through my old logs when I wasn't hosted by anyone 100 does seem a bit high now probably more like 30 - 40

 

[Retired_Member42]

Even on full speed you're still going to lose out. Sure you'll know the domain has dropped quicker if you're running at 60ms than the 200ms guy but what if that 200ms guy queried 140ms before you and their script is slightly faster? What if your script took 140ms more to send the reg request than the other guy? Getting the notification, sending the reg request and Nominet processing it takes a lot longer than an availability poll.

If I had 4 memberships/tags I'd be looking to stagger them all at 200ms for the full 24 hours. Not simply covering the full 24 hours at 60ms. I feel you'd have a much better chance at catching this way.

 

[ian]

If I had 4 memberships/tags I'd be looking to stagger them all at 200ms for the full 24 hours. Not simply covering the full 24 hours at 60ms. I feel you'd have a much better chance at catching this way.

Good point, instead of 16/sec on 4 tags (with obviously an overlap in timing somewhere), you'd be running at 60ms, where as 4 tags split evenly at 5/sec all day/night, you'd be running the equivalent of 50ms.