Distributed computing for snapping up domains

[briman1970]

I had this idea over a year ago and would like some educated opinions on how this would work, if at all, and what the pros and cons might be when creating such a system.

If you don't know what distributed computing is, go here... http://en.wikipedia.org/wiki/Distributed_computing

I was thinking... if a few hundred computers could all be connected by automated registration software that used each computer's resources (and internet connection) to hammer the servers with registration attempts for the same names at the same time, wouldn't that increase the chances of grabbing those names before Snap, Pool, etc could?

I'm not sure who'd get the names that were caught, but I have a few ideas about how to work that out. I'm not sure about the minimum number of computers that would have to be connected and I'm ignorant of a lot of the details involved in bringing such a system into existence, but does anyone think it's possible? Would it get the job done?

I know that Snap has partner agreements with a few registrars and TDNAM grabs all the GoDaddy names, so that would pretty much eliminate names from those particular registrars. Is there any way to get around that? If not, are there enough quality names left over to make such a system worthwhile?

 

[Alex]

Don't know anything about whether this is feasible or not, but as an idea it sounds good.
Basically I bump this since there might be others that may be able to answer this.

But I definitely like your way of thinking Brian, it seems you always have fresh ideas, and that is important in domaining.

 

[DotWeekly]

On the system part, I have no clue... But on the domain part, Yes, there are plenty of great domains that drop in a year that I consider "True Drops" that anybody should have a chance at grabbing.

I do think there is an easier way then hooking up a bunch of computers together. Most of the problems that people have, are slowed because of API backends. So by having your own registrar, the only action on it would be from you and what you put on it. So you would have to find somebody to create a great script and only focus on 1-3 Great domains per day and I think the system would pay for itself. The more domains you want to go after, the more Registrars you will need.

According to AllDrops.com, These are some upcoming drops that anybody should be able to get.

FYZ.net
PUX.net
YRY.net
M-X.net
UPJ.com ? shows Register.com as Registrar and I think they are partnered with snap?
LZM.info
13 LLL.us

And that is just with in the next 2-3 days. Let alone all the keyword domains as well.

Rescue.info
Vuxu.com etc...

 

[nicedomains]

I really like this idea.. Very original, what kind of software? I wish I had more to offer with this but I'm not good with that stuff either. Nice idea, though I hope to see more about it. I would like to help out with it too if possible.

 

[sashas]

As an idea, I've been exploring this too. I don't know the technical details since I happen to be clueless about the technical side of computing.
But if you do happen to have something on your hands, let me know. I'll be willing to help financially as much as possible.

 

[cache]

if the database is centralized, how can distributed computing help?

 

[Ronald Regging]

if the database is centralized, how can distributed computing help?

I think this is the key. At some point, as someone mentioned previously, you'd end up bottlenecking due to the limited resources of the registrar and their API. In theory, you may be able to develop this using many APIs from several registrars, but the amount of development and cooperation that would have to go into this would be far more hassle than just starting your own registrar

 

[winst]

It looks good on paper, but...

In theory, a "bot net" or hundreds of computers trying to catch dropped names would work better than just a few servers. I mentioned a "bot net" because I see the best/cheapest implementation is to develop a client software like a P2P network or a distributed client software like SEDI that installed on volunteer's computers.

However, I suspect that companies like SnapNames have special business arrangements with quite a few registrars that share revenue, and I think the chances for catching a name on an open market is pretty slim. over the years, I count at least 15 registrars that have partnered with SnanpNames.

I think many of the expired names are being auctioned off as they expire, not really being dropped.

 

[briman1970]

Thanks everyone for your well thought out responses! More please! We need to "pool" together to figure this out. I'd be willing to sell my whole portfolio if I knew we could make something like this work.

I do think there is an easier way then hooking up a bunch of computers together. Most of the problems that people have, are slowed because of API backends.

Please excuse anything I say in this post that comes across as ignorant, but this is to intentionally stop serious competition, right? I've heard these restrictions are something like one request per second, per computer (or IP)? So, if you had 200+ computers (or IPs?) running a distributed computing script, all making requests on a single domain simultanously, it may theoretically beat out some of the major dropcatchers, correct?

So by having your own registrar, the only action on it would be from you and what you put on it. So you would have to find somebody to create a great script and only focus on 1-3 Great domains per day and I think the system would pay for itself. The more domains you want to go after, the more Registrars you will need.

So Snapnames has no restrictions on the number of reg requests per second at 15+ different registrars? Is that how they pick off so many great domains?

In theory, a "bot net" or hundreds of computers trying to catch dropped names would work better than just a few servers. I mentioned a "bot net" because I see the best/cheapest implementation is to develop a client software like a P2P network or a distributed client software like SEDI that installed on volunteer's computers.

That's exactly what I'm talking about... like SETI@home

I definitely like your way of thinking Brian, it seems you always have fresh ideas, and that is important in domaining.

:red:

 

[sashas]

Brian, whatever you come up with, I'm in on that.
Because in theory, yes your system does sound good and effective. 200 computers linked up together would be more powerful while at the same time, able to send 200 different requests.

I think we all should definitely pool in our knowledge and our resources to come up with something like this. Its high time we stood up against the big players...Goliath doesn't always have to win against David. We could come up with such a solution and whatever names we get would be kept in a trust, and upon selling the name, all the contributors would get an equal share.

CommunityDomaining?

 

[Ronald Regging]

So Snapnames has no restrictions on the number of reg requests per second at 15+ different registrars? Is that how they pick off so many great domains?

I'm not sure thats how it works, though it very well may. I wouldnt imagine that these partner registrars are using their resources in a combined effort to catch names for Snap. I think its more along the lines of, IF a domain is registered through them, AND its dropping, they renew it and send it off to Snap to auction. So it's not a matter of sending requests, as much as it is just them renewing the domain before it becomes publicly available, like GoDaddy does.

Something else to consider.. Say you managed to pick up a nice LLL.com and sell it for $10,000. Not even taking into account the commission for the sale, and the cost of distributing equal payments to 200 participants, you're still only looking at about $50 per person

 

[sashas]

But you can imagine getting atleast $25 to each of those 200 people everyday, given the quality of names dropping.
Over a month, that works out to $750, more if you have some bigger catches.

Thats not bad at all, I would say

 

[Kate]

With that system you are not going to beat snap et all for high value domains like LLL .com.

You can pool as many computers as you like, they will all be too late so only direct access to the registry will give you a chance (keep in mind that snap has dozens of registars working for them, plus all the tasters and the competition).

All that you are going to get is the leftover, the low-priority or no-priority domains (.ie non-backordered domains) that are caught and tasted by a myriad of registrars.

 

[briman1970]

With that system you are not going to beat snap et all for high value domains like LLL .com.

You can pool as many computers as you like, they will all be too late so only direct access to the registry will give you a chance (keep in mind that snap has dozens of registars working for them, plus all the tasters and the competition).

All that you are going to get is the leftover, the low-priority or no-priority domains (.ie non-backordered domains) that are caught and tasted by a myriad of registrars.

You seem to know how the system works better than some of us. Please give us some more information?

 

[NP02139]

You seem to know how the system works better than some of us. Please give us some more information?

I like the idea, but the biggest challenge to overcome isn't processing power. Your biggest challenge is registry connections, and I'm afraid that you won't get the access/connections you need unless you have access to your own regitrar connections. There isn't an API that I know that will give you the priority access you need to catch GOOD dropping domains.

 

[Spade]

Your biggest challenge is registry connections, and I'm afraid that you won't get the access/connections you need unless you have access to your own regitrar connections. .

Thats exactly the issue. Registrars are only allowed so many connections to the registry per second. That is why the large drop catching services work arrangements with as many registrars as possible. The more registrars, the more connections per second you can make in an attempt to get dropping domain names.

If I remember correctly, SnapNames has something like 30 registrars within its system.

Additionally there is the issue you pointed out. The largest registrars have contracts already to where there domain names will go. Godaddy's network goes to TDNAM - NetSol and Enom Domains go to SnapNames, and so on.

I think a more important question is what % of dropping domain names, are actually going to be "True" drops? Im not positive on this issue, perhaps someone can enlighten us who has studied this more indepth.

I think creating a drop catching service is next to impossible at this stage in the game. Atleast, creating one with a chance at beating out the big boys. (Even GD has 3 Registrars). So, I think the focus should be on courting the smaller registrars, with no or small affiliations to Snap/Pool/ClubDrop.

You would have much better results if you could convince smaller registrars to send there expiring domain names to you, and then sending them off accordingly.

Justin

 

[briman1970]

I like the idea, but the biggest challenge to overcome isn't processing power. Your biggest challenge is registry connections, and I'm afraid that you won't get the access/connections you need unless you have access to your own regitrar connections. There isn't an API that I know that will give you the priority access you need to catch GOOD dropping domains.

OK, so how many registry connections does Snap have approximately? How many requests per second (or whatever) can they make? Let's say they can make 1000 requests per second, for example on any one name. If so, then 1000 computers running the script simultaneously should be able to compete, correct? Maybe I'm not getting a the whole picture...

 

[Spade]

OK, so how many registry connections does Snap have approximately? How many requests per second (or whatever) can they make? Let's say they can make 1000 requests per second, for example on any one name. If so, then 1000 computers running the script simultaneously should be able to compete, correct? Maybe I'm not getting a the whole picture...

I think its much less than that - I thought it was like 100 connections per second. Atleast thats what Bob Parsons suggest on his blog back in 2006 when he disccused the .eu landrush fiasco.

 

[verbster]

This kind of links back to the land rush issue of eu and such....the registrars setting up the bogus but functional registries just to grab names....so that part does have merit.

 

[Kate]

You seem to know how the system works better than some of us. Please give us some more information?

OK here is a more detailed explanation.
When using an API you first send a request to the registrar, then the registrar will query the registry no your behalf and pass the results back to you. You cannot do 1000s of requests per second this way - it's way too sloooooow.
On the other hand as a registar you have a direct connection to the registry so you skip the middleman (API) - it's the critical point. So you can broadcast more requests in less time.
We are talking about milliseconds here (or hundredths of seconds).

There are other things you *may* do to optimize things like host your scripts on a network as close to the registry as possible so that the number of hops is maintained at a minimum...
If you are wondering what I mean by 'hop' a tutorial on the traceroute command will cast some light:
http://www.exit109.com/~jeremy/news/providers/traceroute.html