WebTorrent now works in the browser, end-to-end
twitter.com
twitter.com
https://botbot.me/freenode/webtorrent/2014-09-11/
(wasn't obvious to me what this was...)
EDIT: confirmed: https://code.google.com/p/chromium/issues/detail?id=152875
The goal is to make sure that bittorrent automatically takes full control of the interface when nobody else is using it, yet quickly gives control to whoever needs it when needed, without manual intervention from the user (the notorious "set speeds to 10% to not slow down your web browsing").
That said, uTP being based on UDP gives the nice side effect that NAT traversal is effectively possible.
uTP also implements LEDBAT, which is a scavenger class of congestion control. See CC implementation details: https://tools.ietf.org/html/rfc6817
But I though webrtc still needed dedicated servers to punch through NAT ?
http://www.html5rocks.com/en/tutorials/webrtc/infrastructure...
Decentralized hosting of content that can easily be browsed seems like a useful thing to have.
http://jack.minardi.org/software/syncnet-a-decentralized-web...
Check out this paper to learn more about the Web applied to P2P networks [1].
Li, Ruixuan, et al. "WebPeer: A P2P-based System for Publishing and Discovering Web Services." http://www-inf.it-sudparis.eu/~tata/papiers/sellami/P2P_Disc...
Suppose that my city's newspaper (or TV station) monitored the (socially accepted, widely adopted) P2P networks for reliable mirrors of their own content, then sent each user's browser hrefs to the mirrors, rather than their own site.
The more popular the content, the more likely that your next door neighbor's P2P system can stream it to you.
Since running such software is socially acceptable in this hypothetical future, your P2P software doesn't have to go through the 'discovery' step. One of your hostnames is 1234.main.st.ci.lincoln.ne.us (see http://owen.sj.ca.us/~rk/howto/usdomainname.html) and one of them is mirror5.journalstar.org.ci.lincoln.ne.us. Everybody on Main St already knows your IP address, and if you mirror a lot of content, they might even have an existing active connection... you see where this is going? :)
Unfortunately, I couldn’t find the video. It worked really well though. You could just open the magnet and drag-and-drop copy the files you wanted, or just open them and they’d start streaming.
A significant drawback is that you'll have to keep a tab open for seeding. And no DHT support either.
BT clients are best operated in a daemon-like fashion with access to system facilities such as inotify, udp and tcp sockets alike and as something that does not compete for CPU time/garbage collection/file descriptors/etc. resources with interactive web browsing.
I don't see the advantage of "do it in the browser" here.
Two advantages of "do it in the browser" are, in theory it would run on every platform that browser is installed on with no additional run-time required (like Python or Java), and two, it could run on Chromebooks. Say, in Incognito mode.
I don't see the advantage of "do it native" here. Nor do I see the advantage of doing in the browser. They both seem like perfectly good places to write a BitTorrent client. And I can certainly imagine some interesting cases where I would want to allow my site users to send traffic between each other over a well known, advanced P2P syndication system (rather than cobbling up my own).
Except they aren't. Web APIs don't provide the facilities necessary for a complete bittorrent stack. TCP and UDP sockets are essential (this thing uses webrtc, so it's not even bittorrent-compliant). Additional facilities like mmaped files, epoll-based socket IO and inotify make for more efficient implementations. A good bittorrent client on a gigabit connection can push a lot of data around, hashcheck it and so on.
Some torrents also have thousands of files open simultaneously, this can push the number of filehandles the browser process has to keep, possibly conflicting with other files the browser also wants to open, e.g. its cached files.
You also need to talk to local network devices (UPnP routers), enumerate network interfaces to bind ports to the correct one so you can tell other clients your alternative addresses (this is part of ipv4/ipv6 compatbility) and a whole bunch of other sort of low-level stuff.
Browsers simply do not provide the same access to system APIs. They are not a libc-replacement.
B) you don't NEED a more efficient implementation
C) many torrents do not have thousands of files open
You're confusing "is a complete replacement for bittorrent" with "has uses." This definitely has uses.
"Worse is better."
BitTorrent is extensible: I see you agree with that premise since you listed UDP sockets, formalized by BEP-0029. The objections you level against WebRTC DataChannels make it sound like the particular transports you mention are somehow blessed, that it's not and won't ever be bittorrent unless it's TCP or UDP (and even if it was a hard/fast requirement, one could still benefit from WebTorrent via Firefox extensions and Chrome apps).
Who cares if you're using mmap, epoll, or inotify? Are you intimate with the performance limitations of IndexedDB in all browsers? How versed are you on the performance hit taken by File API? When do these limits become problems? Why would a browser need to keep open a filehandle for every "every" in the first place? That's certainly not at all how https://github.com/js-platform/filer works, on either it's IndexedDB or it's WebSQL backend.
As for your networking dilemmas, I recommend you check out: The network discovery api (which can enumerate UPnP and DNS-SD), WebRTC's TURN/Stun for correctly choosing from available addresses, and a whole bunch of other web stuff that you obviously don't know anything about but think is explicitly the domain of Real Serious Programming With Real Applications.
Not everyone needs to be operating at the fantastical extremes you are concocting, not all use cases are gigantic seedboxes on fat pipes. It's ok to deliver capabilities that someone else might already have, and maybe not even have some quirks or possible points of poor comparison.
You're throwing a whole bunch of technical minutia at the problem you want to have. You're picking a false fight (and one that the web has plenty of good repostes you didn't know/omitted to retort with). The web might not be the best choice for using a gigabit ethernet connection (or maybe it actually does it fine in some conditions!): the act of finding these particular points to dive deep deep into as an excuse to ignore, shun, and spit upon the expansion of human technical capabilities is a close-minded injustice. It's bigotry, simpleminded technical bigotry showing off your inability to open your mind to possibilities, unwilling to open your arms to new improved things becoming available to people who want them and will benefit from their use, it's your own intransigence in the face of the ongoing adaption and mutation going on in the world. You're in for a bumpy ride if you are going to cling so tightly to your notion of what things are for and how they ought be.
While it's only available to privileged and certified apps, Mozilla's TCPSocket Web API[0] gives you (unsurprisingly, given the name) raw TCP sockets.
The W3C also has a TCP and UDP Socket API[1] under development.
Obviously, exposing raw TCP/UDP sockets to the open web is a Bad Idea but Web Apps are more than that.
[0] https://developer.mozilla.org/en-US/docs/Web/API/TCPSocket
It would be interesting to know if the developer looked at btapp.js and if so, why did he decide not to use it? Getting this technology web embeddable will go a long way to start making peer-to-peer a convenient method of downloading content vs directly downloading from a server, there's always going to be further hurdles to overcome with reliability in a case where the swarm lifetime is very short, but seeding with a few servers can help in that situation. If a web app could upload the torrent and data to a server to seed, then replicate it in a few locations it could be a decent DCDN.
[1] http://pwmckenna.com/2012/06/29/making-of-paddle-over.html
Something that is done purely with cross-browser compatible web technologies is far more interesting and promising.
This is REVOLUTIONARY
The idea is to leverage BitTorrent's robustness in the face of random disconnections and reconnections as well as the easy-to-use throttling options that most clients expose.
The server would run a special BitTorrent client that never seeds, to prevent malicious users from using the server as a gateway to redistribute content.
So, rather than the traditional cloud of people seeding and leeching, the only participants would be one client seeding, and the server leeching. Once the transfer completes, the user could disconnect and the torrent would cease to exist.
Firefox 32:
ICE failed, see about:webrtc for more details
Nightly 35a1:
Mandatory/optional in createOffer options is deprecated! Use {} instead (note the case difference)!
setLocalDescription called without success/failure callbacks. This is deprecated, and will be an error in the future.
ICE failed, see about:webrtc for more details
this._pc is null bundle.js:25705
Chrome 37:
Uncaught, unspecified "error" event. bundle.js:9134
magnet:?xt=urn:btih:e666231c9a34be278f6cfc390099e4084b30e023&dn=The.Giver+2014+720p+REPACK+HDRip.x264+AC3-JYK&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.publicbt.com%3A80&tr=udp%3A%2F%2Ftracker.istole.it%3A6969&tr=udp%3A%2F%2Fopen.demonii.com%3A1337
contains first the protocol (magnet:) which tells the OS that this is a magnet URL so give it to some app that can handle that. Since it's in URL form it's all broken down into & separated key/value pairs, so next part:
xt=urn:btih:e666231c9a34be278f6cfc390099e4084b30e023
is the infohash (actual infohash is e666231c9a34be278f6cfc390099e4084b30e02, the xt is just the key for that value, urn:btih probably means something, google it).
The other ones are pretty self-explanatory, the name of the torrent (presumably so the client can display something pretty before it has downloaded the metadata) and some trackers
It's a Uniform Resource Name (hence "urn"), btih (BitTorrent Info Hash) is the namespace identifier and the rest is the namespace-specific string, the actual infohash.
It's sad that BitTorrent is otherwise basically dead (as a way to obtain content). Where I live (Germany) you often get immediately subpoenaed (or the German equiv.) if you use it to download something.
The other day I made the mistake of downloading one of the last How I Met Your Mother episodes via torrent (the first time in years). Two weeks later I had a nice invoice over several hundred Euros in my mailbox :-(, and I know a couple other people to whom happened the same. That's why I wouldn't touch Popcorn Time with a ten feet pole.
It was basically one page explaining that one violated copyright, giving the file name, the date, and the IP address; then a few pages detailing the appropriate laws, explaining how utterly bad piracy is, and telling you how much trouble you are in. Then there was an invoice for a one time "license" for the episode, and the legal fees which were more than the license. Following that, there was a kind of contract you had to sign, agreeing to accept the license, and in case of repeat violation, agree to pay a much higher fee. If I remember correctly, there even was a filled out wire-transfer form you just had to sign and bring to the bank in the end.
If you didn't accept their conditions, and refuse to sign, then they would go to court, which is extremely risky. You might get exonerated, or you might have to pay a lot more, so in the end I just payed the few hundred euros.
Given that the reason I pirated in the first place was that I'm a student and currently can't really afford to buy the media, its especially frustrating...
But I can see why such a strategy would work on their part.
I wonder how many of those letters they send out and how many people stand up to them in court and what the outcome is of those cases.
On top of that I would have used the (firm) German privacy laws to use the discovery process to figure out if they had obtained my (private!) name, address etc in a legal way.
To me this seems like a racket and I highly doubt that the case would have ever gone to court.
I would expect an outcome like this:
https://torrentfreak.com/evidence-against-bittorrent-users-s...
And without a ton of money the German state would likely appoint a legal representative.
Recently, someone argued that their router had a known vulnerability, and the rights holders couldn't prove that their WiFi was not hacked, and that they downloaded the files themselves, so they were acquitted. (http://www.heise.de/newsticker/meldung/Filesharing-Klage-weg...)
In my case, there were two factors that made me pay: First, they were in the right. As annoying as it might be, and whatever my positions on "intellectual property" are, it's hard to argue against that. Secondly, the cable connection belonged to a friend, and I didn't want to expose that person to a couple years of legal uncertainty.
If a cease-and-desist letter is unjustified, or in a grey area, I would definitely stand up against it, because I believe I'd have a good chance in court.
Sounds like the perfect legal defense that an IP address does not identify you.
The only rule might be: do not down load content ( music) from Sony/BMG because they actively monitor the biggest torrent sites/downloads and might get a letter from their lawyer ( which you can ignore basically).
Movies and music from other labels are relatively safe. I don't download anymore since with 7 euro montly ( two beers) I have Google all access, while spotify is free from mobile.
That's absolutely not true. You can use BitTorrent as much as you like, there is absolutely no danger in doing so. If you commit copyright violations however, you might get caught regardless of how you did it.
Of course you only get an "Abmahnung" if you use it for copyright violations. But that is by far the largest use case. It can hardly be ignored that most people, especially "non-technical" ones, associate BitTorrent only with illegally downloading media.
What I wanted to say, is that now - as opposed to a few years ago - the probability of getting into trouble when downloading popular episodes via bittorrent has approached ~1.
My point was basically, the old approach of Joe Average Pirate of 1) installing µTorrent and 2) googling for "Big Bang Theory S05E01 torrent" is as good as dead.
You're right I was a bit sloppy, but that's moot now since I can't edit my post anymore and will probably continue to be downvoted until the text is completely invisible :-(
Now of course, you can make it difficult to join the torrents - for example, by using private trackers - but that makes it as difficult for me as for the hollywood copyright holders.
Then just IP address -> Court order -> ISP -> Your home address and send the threatening letter.
That's just plain wrong. Maybe if you are downloading the latest hollywood flick from TPB you'll get a "Abmahnung" but that's about it. It's nowhere near "dead". If you are not using one of the big public trackers you won't have a problem. There are also free templates to fight these letters.