1. You would likely dedicate a subdomain.
2. Pagination is irrelevant since this is DNS.
3. DNS trashing is hardly a big deal considering how low resource they really are by todays standards. Likely unnecessary for most anyway.
4. Trackers could be done on any protocol in theory, HTTP is ubiquitous.
5. That’s really up to the browser. There’s no standard for BitTorrent clients either and they managed. Could even have a separate process to mimic that of a typical BitTorrent client, though considering how long most people keep browsers open it’s likely not needed.

* you have to worry about things such as people going to site.com or http://www.site.com. how do you handle things such as pagination and pages with ?page=2

* depending on the page this torrent is gonna be changing every 10 minutes, and isp dns caching isn’t gonna help much at all, you will just be giving people old useless pages. you can keep the ttl low, but then your dns server is gonna get thrashed no matter what.

* i dont know the bittorrent protocol at all but last i checked, trackers run over http. so your web server is getting hammered you have yet another server to worry about getting hammered after that.

* how long do you propose people’s browsers maintain seeding a page? ratio of 1? 2? as long as im at that site? as long as my browser is open? as long as its in the cache? if you have peers connecting to a tracker and not being on any longer than 10 seconds thats gonna render attempting to get the page almost useless.

1. Accept Encoding is correct since the server would serve a .torrent (over HTTP) as the response should it find the browser can accept it. The DNS layer is a fallback initiated by the browser should the HTTP download server fail. This is by far the most common point of failure in a high traffic environment. Accept Encoding doesn’t switch protocols as you claim it merely tells the server if it can offer a .torrent or not.

2. DNS would really hold only 1-2kb at most. It would hold the .torrent which generally run 1kb for essential info only. As I mentioned this is not really that different than storing SPF data in a TXT or SPF record. Downloading the actual file is up to the torrent network. ISP’s could cache the torrent itself if they wanted to keep it on their network and offer faster downloads to their customers.

Robert:
For the fallback, just having a pointer to a magent: URI might be better? Not so much data to cram onto your DNS servers, and all that.

We are trying to get torrents and advanced download features into a HTTP download interaction users are already familiar with…In the sense that they don’t need to know it’s being used, because it all happens automatically in the background. Yes, you can lists torrents and all mirrors for a file w/ a metalink (XML). This is what things like the openSUSE download redirector (MirrorBrain) and other Linux distributions are using metalink for. Some clients download from torrents mirrors at the same time, then share over BitTorrent when finished.

For metalink, we’ve been using transparent content negotiation which is apparently not the correct thing to do in some people’s opinion, but works. I’ve been told the HTTP Link header is the correct thing for us, so I’m hoping it’d be good for torrents too.

If anyone is interested in this, feel free to help us improve what we’re doing by dialoging and collaborating.

DNS servers can also handle a ton of traffic without much effort. They are often one of the older boxes a hosting provider has running.

1) It’s not what DNS is designed for
2) I don’t know how many hosting providers allow you to declare your own DNS entries, but mine doesn’t. I’m limited to making subdomains on the same server as my main site. I can’t even make one that points to my home computer or a dynamic DNS (no-ip.com, etc) entry. Noone may be able to use it.
3) Even without your DNS solution we’re still much better off than before. Not to mention, if the server does go down, our solution at getting users to use BitTorrent to download the file has already clearly failed. The whole point is to keep the server up.

Not sure how else you would do it though. Redirect all traffic to a mirror of the torrent file on TPB or elsewhere, maybe… some servers that are failing to serve too many users with full web pages may improve if all they have to do is reply with a Location header.

Also your Accept idea isn’t really all that great, since right now servers would go check any media type they’re sending against that field (ideally) and check to see if that media type can be handled by the client. If not, it might send a different media type. The wildcards there mean that the browser wants the server to send whatever it’s got… an explicit declaration of application/x-bittorrent would seem to be redundant, not to mention it changes the way that header is expected to be parsed by the server (*/* now means everything… EXCEPT bittorrent! Not exactly intuitive.).

I like the Accept-Encoding method if only because with X-Torrent, the browser would likely send GET and expect to get the full file via HTTP… which the server would then send along with the X-Torrent! A bit of a waste of bandwidth when the server is just going to cut it off and use the torrent.

Otherwise the client should send a separate X-Header of it’s own to indicate BitTorrent support, to get a torrent file in return.

Or we could go and add yet another string to the User Agent to indicate built-in BitTorrent support. Perhaps a JavaScript method too.