the forums at degreez.net

I think the httpseed idea has a good potential for bridging the gap between http and bittorrent.

Unfortunately, if the spec requires that the server have the torrent and run some script, it limits things.

Why not make the spec include a static server or client-processing mode where the client calculates which bytes of which files it should try to download and then makes a GET request with Range or If-Range?

You could theoretically open a torrent for any file that is on a website anywhere. You could also httpseed things by just dropping the bittorrent data somewhere on the server and pointing the torrent to it.

I imagine it might be useful to be able to point the torrent at a few specific files in a torrent, or at a directory that is assumed to contain all the files in the torrent. i.e. ending in a / means it's a directory and has all the files in it, otherwise this httpseed only contains a specific file.

The server would need to handle Ranged GETs, but Apache certainly does that, as well as many others. You wouldn't need PHP on the server. You wouldn't increase server CPU load. You wouldn't throw in the PHP security risk. It seems a much saner option.

This might also increase usability as people could put the file up on their webserver and then a torrent right next to it. People could initiate the transfer with plain http or they could get the data faster with the torrent.

http://bittornado.com/docs/webseed-spec.txt

Read "server-side implementation notes"

1. Limit its average upload to a reasonable level.
If this is a public webserver, they will either be limited by media (because of lots of clients) or by software throttling, anyway. This is only important if someone doesn't have a server or pipe that can handle it.


2. Intelligently tell peers how long they should wait before
retrying.
This could default. A server that is handling all the requests, but only allowing a trickle of data may never need to do this, anyway. However, http clients generally have a default and then retry.


3. translate from an info-hash and piece number to a byte range
within a file or set of files, and return those bytes.
As I say, the client could do this based on the torrent file and then convert that to an http request. Plus, with the client doing this, the server needs know nothing about the torrent. It doesn't even need to know that there is a torrent pointing to it.


It still seems to me that this would be quite useful for some situations. The limitation of having to have the server know about the torrent considerable.

In the situation where there's a big file on a slow http server out there that doesn't have a torrent system and the clients want to have that public server do the seeding, it seems especially useful. Instead of deciding _between_ using bittorrent or http, one could use both of them. In fact, one could use the swarm and several mirrors, rather than just using one webserver.

Perhaps with this implemented on a client, people could also add the url manually in the client. You're downloading some large file from a swarm, but you notice that some webserver also has it, so you click around to "add a url" and paste the url in.

Clients in the future may even be able to take a url and then search some databases around for swarm information automatically.


To me, this just adds a lot of potential and puts the power in the hands of the clients, rather than the servers.

The overhead required for a webserver to be aware of a torrent it's hosting is minimal.
The PHP script required is only 23.8 KB (24,384 bytes) in size.
The MySQL database required is 33.1 KB (33,978 bytes) on my system (currently hosting 4 torrents).

It's a small price to pay to make sure that BT clients aren't hammering the webserver to the point that it becomes a DDoS.

Additionally, a BT swarm that has gotten above a certain size won't need to contact the webseed at all, and properly configured the webseed script or program will refuse connections in situations where enough of a seed base is avaliable.

BitTorrent is designed to decentralize the upload bandwidth as much as possible. Allowing BT clients to directly access HTTP servers hosting files without any kind of control over them would be VERY harmful to that ideal.