PeerCDN: WebRTC-based peer-to-peer CDN [video](peercdn.com)
peercdn.com
PeerCDN: WebRTC-based peer-to-peer CDN [video]
http://peercdn.com
12 comments
This will open websites to a hole new array of exploits. I don't mean that as a bad thing. Just something that will need to be addressed. I'm thinking seeders sending corrupted/malicious packets to other peers.
It does mention that checks are in place to prevent tampering.
"PeerCDN uses a centralized resource authentication server to generate SHA1 hashes of a site's resources. Data provided by peers will only be used if it is safe and unmodified. All peer-to-peer communication is encrypted."
It may prevent tampering, but it does nothing for surveilance.
Say hello to passwords.
Surveillance, sure. Like a MITM could be a threat, but a MITM is a threat for any HTTP request.
And shouldn't forms still be posted directly back to the server? If it's just a CDN I don't see how any confidential data could be leaked unless the server serves up your credentials in cleartxt. Perhaps I misunderstood you?
And shouldn't forms still be posted directly back to the server? If it's just a CDN I don't see how any confidential data could be leaked unless the server serves up your credentials in cleartxt. Perhaps I misunderstood you?
I like this as a 'tech demo' but i think they are some serious pitfalls if something like this was used.
1) Issues with privacy, leaking information to other peers about who's on the website etc doesn't sound good at all, neither for me as the site owner neither for my users since it could be potentially used as a method for them to be tracked.
2) In 2013, its easy and inexpensive to serve any kind of static files, videos are quite big and that might be the only valid case, however...
3) If you used this to stream video, it would require a great number of seeders for videos to buffer fast and start playing with no iterations.
4) How much of your user hard disk are you going to take over to store your things? Are you storing content that is outside the context of there current page?
I could go on and on, i see so many issues with such practices but here is the most important:
Your users will hate it, they will hate being used in such a manner, they will hate there upstream being used, they will hate there hard drives being used. They will hate you.
1) Issues with privacy, leaking information to other peers about who's on the website etc doesn't sound good at all, neither for me as the site owner neither for my users since it could be potentially used as a method for them to be tracked.
2) In 2013, its easy and inexpensive to serve any kind of static files, videos are quite big and that might be the only valid case, however...
3) If you used this to stream video, it would require a great number of seeders for videos to buffer fast and start playing with no iterations.
4) How much of your user hard disk are you going to take over to store your things? Are you storing content that is outside the context of there current page?
I could go on and on, i see so many issues with such practices but here is the most important:
Your users will hate it, they will hate being used in such a manner, they will hate there upstream being used, they will hate there hard drives being used. They will hate you.
Great for the websites. Not so great for mobile users or those with data caps (it's usually a transfer cap so it doesn't matter if you're downloading or uploading). I wish unlimited data was more prevelant, alas, that's not the case.
"If peers are slow or the central PeerCDN server..." So there still is a central server involved, I'm guessing for coordination.
"If peers are slow or the central PeerCDN server..." So there still is a central server involved, I'm guessing for coordination.
Yep, we run a globally-distributed central tracker server to coordinate which peers have which files. We've considered making it completely distributed, but the added complexity and latency doesn't seem worth it at this stage.
Good point about the upload bandwidth. We currently do some nice things to hopefully alleviate the effects of this. If the user is on mobile, on a slow connection, or on a device that's on battery power (yes, you can detect this in JS!), we can behave nicely and use less or no upload bandwidth.
Good point about the upload bandwidth. We currently do some nice things to hopefully alleviate the effects of this. If the user is on mobile, on a slow connection, or on a device that's on battery power (yes, you can detect this in JS!), we can behave nicely and use less or no upload bandwidth.
Don't forget there also users who are capped by their ISP that aren't on mobile too. It's a weird situation, but you may also need to blacklist certain ISPs or you'll have some users who are a bit peeved.
I don't think any privacy issues are at play since the assets are hashed, but it seems like almost every site I visit in the EU has those annoying "this site is using cookies" banner that I have to acknowledge. I can tell you that's a total browsing experience buzzkill, but do you think some jurisdictions will demand something similar? I don't mind sharing bandwith since I'm not data-capped.
I don't think any privacy issues are at play since the assets are hashed, but it seems like almost every site I visit in the EU has those annoying "this site is using cookies" banner that I have to acknowledge. I can tell you that's a total browsing experience buzzkill, but do you think some jurisdictions will demand something similar? I don't mind sharing bandwith since I'm not data-capped.
I would assume browsers could put up a permission box for WebRTC usage, or ask for permission for sending more than a certain low bitrate. Of course, in the case of a site using PeerCDN the incentive for a site visitor to allow it would be negligible as compared to a website using it for a VoIP service.
Edit: Grammar.
Edit: Grammar.
My that layout looks mighty familiar...
http://cl.ly/image/212W3P2X2t1L
This sounds awesome, though.
Edit: Totally missed the footer as pointed out in the replies. I got unlucky with a red cable under the red link on my screen.
http://cl.ly/image/212W3P2X2t1L
This sounds awesome, though.
Edit: Totally missed the footer as pointed out in the replies. I got unlucky with a red cable under the red link on my screen.
If you look in the footer
> © 2013 PeerCDN, Inc. Site design inspired by Meteor.
> © 2013 PeerCDN, Inc. Site design inspired by Meteor.
the bottom of their site says © 2013 PeerCDN, Inc. Site design inspired by Meteor.
Nice work! How do you plan on dealing with the leeching ratio though? It'll be far higher than traditional bittorrent (where the user leaves the app running in the background).
Leeching shouldn't be too much of a problem: the user will upload while they remain on the page (which should be much longer than it took them to download the assets).
the status quo is essentially that everyone is 100% leech and downloading from the origin, so even if the ratio is worse than bittorrent, any peering would be a win.
This is really interesting as something that everyone agrees upon and is taken to mean what the web is about. Unfortunately, that's not it's current state. How big can the burden on the visitors be, and is it opt-out instead of opt-in? Sounds like brooding trouble.
Really glad to see cool things being done with WebRTC though.
Really glad to see cool things being done with WebRTC though.
This is a surveilance and policy nightmare. I predict within 0-3 months of launch this service will be banned on school campuses, corporate networks, mobile networks, and anywhere else that it ends up being used.
Also - browsers are not reliable. Unless people get paid to spin this up on real servers, this is going nowhere (like XDN).
Also - browsers are not reliable. Unless people get paid to spin this up on real servers, this is going nowhere (like XDN).
The internet is a surveilance and policy nightmare.
It may be difficult to ban if it's running JavaScript in the browser and using simple http. I'm not an expert in WebRTC, but I wouldn't dismiss this out of hand.
It may be difficult to ban if it's running JavaScript in the browser and using simple http. I'm not an expert in WebRTC, but I wouldn't dismiss this out of hand.
My biggest concern is if a user closes their browser window while another peer is streaming some content. I'm assuming Peer CDN connects to someone else or uses Http's Range to fetch the rest of the file off the server?
Yes, that's exactly how the fallback will work. You can download content from 1 or more peers. If all the other peers disconnect, then it'll fallback to the origin HTTP server and fetch the remaining bits using RANGE requests. There are a whole bunch of reliability checks to ensure that files are downloaded correctly, completely and as fast as possible (re-downloading as few chunks as possible or not at all).
Will my server have to support RANGE requests for all accelerated assets?
Yep, your server will need to support Range requests. If it doesn't, then assets will just load over HTTP normally.
How do we get into the beta? Market Loco could totally use this.
"Offloading part of the web hosting burden to site visitors reduces bandwidth costs." How does this exactly works?
It uses WebRTC to make peer-to-peer connections between a site's visitors.
Very interesting idea.