Web-Based Seeding

[Firon 3]

Um, I don't think you quite know what you're talking about.

Oh and images are disabled in sigs.

[Ultima 7]

@Marshy: Please explain how this would "KILL the internet archive." BitTorrent was built so that peers have to upload to offload a lot of the bandwidth that the seed ("internet archive" in this case) would need to share with each peer individually. This works well with the original intent of BitTorrent (offload bandwidth usage from static servers).

[NiteShdw 0]

Isn't this request a little far out of the way of a client? A whole separate program would have to be run on the actual HTTP server. There is a web seeding specification. The best that uTorrent could do is 'support' that specification, but as far asI know, none of the other clients do.

[Nirvana 0]

Isn't this request a little far out of the way of a client? A whole separate program would have to be run on the actual HTTP server. There is a web seeding specification. The best that uTorrent could do is 'support' that specification, but as far asI know, none of the other clients do.

BitTornado, and another one (they're on the first page of this thread) are known to support it. The server tools (to host the seed) are right here: http://e.scarywater.net/bt/download/webseed-0.9a.zip .

Marshy has it all wrong. Let me re-explain. If a torrent has ZERO seeds (or very few) and many leechers, then the HTTP seeding would kick in. So:

A) Bandwidth is NOT wasted uneccessarily

Everyone can complete their download

C) The Company distributing the torrent does not have to pay for the pipes of running a "pure" http download.

[foxyshadis 0]

Hate to revive a thread, but maybe it'll respark discussion. Anyway, this is very similar to how Dijjer (also created by the bittorrent creator) works, except that with Dijjer it's more seamlessly integrated (no torrent files) but incompatible. Web seeding is a much simpler and more scalable way to enable permanent seeds than keeping clients running on servers, and more client support would definitely kick-start its use. The spec is simple and concise, though a tracker extension would also be useful:

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

Of course there's no point in ut supporting the seeding side, just the client.

[Ultima 7]

lol besides the stuff about Dijjer (which hasn't been a failure, IMO), everything you wrote was mentioned in the thread before (the link and the fact that µTorrent should only [and can only] support the client side of the extension). =P

[foxyshadis 0]

I missed the first link in the first post, I thought only the server-side scripts link had been posted.

[silverfire 1]

Just as an offhand note, reviving an old thread is infinitely preferable to starting a duplicate thread.

[Vectorferret 0]

The voting requests page should be more clear about this feature. I voted no and then went to the thread to see why anyone would want the feature. Now that I know what it is, I think it's great. Hybridizing would be quite amazing, especially if we still 1:1 ratio'd. With things like OpenOffice, I can actually download faster from the FTP site than the torrent, but if they were contributing to the torrent, I'd definantly go that way for my downloads. It's a best of both worlds implementation. Also, this would help push BitTorrent as legitimate rather than just for pirates, as it fits with Cohen's original intention of saving bandwidth on servers for legal downloads.

ABC supports it because ABC is an alternate GUI for Shadow's Client (since Shadow's is open soruce). ABC tends to only be updated when Shadow's is.

[JohnJ 0]

If it is a simple addon that you will just insert a http link where the file is located and then the client behaves like as giving the link and authority to other clients and stoping it when you want, then it would be cool.

If it is like TorrentFlux where you should have dedicated servers and root access in order to install then it would suck.

There must be a way that we should utilize the shared webhostings we have and their traffic/connection advantages for seeding!! Always using shared webhosting space/traffic!!!

[Ultima 7]

Sorta like the first guess. The link would be the link to a tracker that points to the file, I believe, and not the file directly.

[Druidor 0]

Im sure one of the private trackers I frequent have a seedbot located on the tracker server as it is used for special seeding to the Elite members so they can DL the file at greater speeds before seeding to general members.

No Idea as to the application they use but 1000K dl is kick ass if you can handle it.

[naugas 0]

There's a smarter proposal out than the original webseed: http://www.getright.com/seedtorrent.html Azureus supports this (and the older one) via plugins.

[r00ted 0]

I cant see why this would/should be implemented into a "client".

I didnt read indepth, just waht's stated in this thread, and yea, there are ways to run BT tracker clients on the server/tracker end, correct? So, basically, if a torrent on the tracker had low seeds, the server/tracker-side client would kick in, and start helping out by sending pieces out. Addressed to the peers, and From the tracker address.

This seems more of a server side implementation. Like, for example, I believe when revision3.com, commandn.tv, and other torrent based pod/vidcasts release new episodes, they use something similar to this. remote machines, all over the world, to help spread out the torrent, on high speed connections until a reliable seed/peer ratio picks up, and tags along, at which time, they would disconnect their main servers/web seeding.

[DreadWingKnight 310]

There's a smarter proposal out than the original webseed: http://www.getright.com/seedtorrent.html Azureus supports this (and the older one) via plugins.

Unfortunately, I see no mechanism in the getright proposal that would permit multi-file torrents to be seeded by a webserver.

[1c3d0g 0]

Well don't worry about it r00ted. IIRC it's gonna be implemented a bit seperated from the main program, thus only the peeps who need to use the web thingy will have to download that part.

[Ultima 7]

Erm... this whole thing is mostly a server-side thing. People are only asking for µTorrent to understand the httpseeds field, and probably create a torrent with HTTP seeds too.

@1c3d0g: Eh? Why would there need to be a separate thing for torrents with web-based seeding?

[1c3d0g 0]

That's what I heard. :| But since I haven't even seen it in action, you can dismiss my comment...

[Nirvana 0]

Lots of people seem to like it...could we maybe see it in v1.5? Also, to whomever is still asking this question: No I am not asking for the creators oif utorrent to get the server side implemented, that would need to be made as a different program. I am only asking for the CLIENT SIDE code to be added. Maybe the coders would like to contact the shadow, or take a look at httpseeds.py in BitTornado's Source?

[splintax 0]

The way I see it, ideally, a .torrent could have ANY http:// link to the file(s) embedded in it, and you could add an http:// link as a peer to accelerate your downloads.

The only think I'm not sure about is how you can manage to only download certain pieces of a file over HTTP, IIRC this isn't supported by all servers? :/

[Ultima 7]

That's basically the idea that the GetRight developer suggested, but as DWKnight pointed out above, multi-file torrents would be a pain in the ass that way. For this reason and the reason you pointed out above, I feel that only proper HTTP seeds as described in the spec should be allowed =T

[JigPu 0]

Actually, I really like GetRight's idea. Although the existing spec is not clear on how multi-file torrents should be handled, it would be a simple matter to extend it to allow them. As I see it, there are two ways that it could be extended:

1) Multi-file torrents would have URLs for each file available in the "url-list", and these would be matched to the file downloading based off of the filename. When the Bittorrent client wishes to use an HTTP seed for file XXXXyyyy.zzz, it checks in the "url-list" for a file with that name.

2) The "url-list" in a multi-file torrent would contain the URL to the parent directory where files are contained. If a piece is wanted from an HTTP seed, the file's name is simply concatenated to the end of one of the directories in the url-list.

The first is a lot more flexible for file location, since not all the files have to exist at the same path (or even on the same server!), though suffers from the fact that no two files may have the same name. The second is stricter in where files may exist (the directory structure of the downloaded torrent must be mirrored on the HTTP server), but files can have identical names because of this. Both suffer from the fact that filenames (and directories as well for the 2nd method) contained on the servers MUST match those being served via HTTP.

The BitTornado spec is a lot less problematic in one sense, since it does not suffer from the filename problem, but more restrictive as HTTP servers require additional software to be of any use to the BitTorrent community.

Personally, I'd love to see either implemented, though if given a choice I'd prefer an extension to the GetRight method since the filename problem isn't all that huge, and there are (and likely always will be) more HTTP servers without a BitTorrent frontend.

JigPu

[Ultima 7]

Hm... you make a good point there...

[DreadWingKnight 310]

http://wiki.depthstrike.com/index.php/P2P:Protocol:Specifications:HTTPSourcing

How's about this as a possible alternative to getright's (rather incomplete) proposal?

[mattd 0]

Hello, just like to revive this thread, it would be absolutley awsom is utorrent could implement the client side of this to communicate with a web based seed.

Any new information on if this is going to be implemented?