1

i was thinking it would be cool to implement native torrent support in a web browser so that the following html would render an image on the page:

<img src="magnet:?xt=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C" alt="smiley face" height="42" width="42">

i have looked around and such a thing doesn't appear to have been done before, but it seems to me that it would have a lot of advantages - for example in content delivery networks, or to provide redundancy when hosting files.

could such functionality be implemented as a browser plugin, or is there a better way? what steps would be required?

4
  • I can't think of anything more fun than waiting infinitely long for a page to finish loading. Bittorrent can be very useful for distributing GB files, but dreadfully ineffective at serving 42×42 images.
    – msw
    Commented Jan 23, 2015 at 6:22
  • maybe. it just depends how many seeders there are. Commented Jan 23, 2015 at 6:39
  • Opera contains a torrent client. Commented Jan 23, 2015 at 9:11
  • There is a problem with this: a magnet URI does not actually specify a particular mechanism to locate and download a file. It is a protocol agnostic scheme that is used with multiple protocols. If you write a browser plugin that resolves them using bit torrent, and I write one that uses gnutella, how should the browser decide which to use on a given page?
    – Jules
    Commented Jan 23, 2015 at 20:34

1 Answer 1

2

The idea is feasible, but of little use due to the nature of web browsing and bittorrent behaviour.

For small resources, e.g. images, the overhead of setting up a swarm and keeping it reliably seeded is way too big compared to just serving the image directly from some server.

For large resources, e.g. long video elements, it would be justified, but then you would want to stream the content so that the user has something to see right away, not download-and-play. (It's a web browser, after all, not a download utility.) But BT doesn't offer any guarantee that you receive the first part of a file first, so it can't reliably stream anything. I suspect this is why others haven't run with the idea yet.

5
  • The bittorrent client can decide which blocks to request first. It can start in the beginning, which for example the video feature uTorrent does. Commented Jan 23, 2015 at 9:13
  • That's interesting. Does this make other members of the swarm request the first blocks first, too? Or do they simply ignore non-satisfiable requests? Commented Jan 23, 2015 at 9:17
  • When connecting a to a peer they'll send you information about which blocks they have and they also send you a notification whenever they downloaded a new block. So clients only request blocks the peer has. Commented Jan 23, 2015 at 9:25
  • The problem with sequential downloading is that peers often leave once they finished downloading, so early pieces would be available on many peers and late pieces would be available on few peers. The tit-for-tat strategy doesn't work well either, if a client who has more pieces than another has all pieces they have, instead of different ones. This means random requests improve efficiency of the swarm, which is why many clients that support video streaming still mix sequential download with requests of random or rare blocks. Commented Jan 23, 2015 at 9:29
  • sequential downloading is feasible on large swarms and when clients keep uploading content. A browser would have to keep uploading downloaded resources for a reasonable amount of time to not be a selfish leech. But the user might not expect his browser to occupy significant amounts of upload bandwidth.
    – the8472
    Commented Mar 5, 2015 at 15:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.