P2p on Notes

WebRTC

melo@simplicidade.org (Pedro Melo) — Sat, 30 Jul 2016 11:57:38 +0100

WebRTC provides the API’s to implement P2P connections between clients, like browsers.

Probably the best article on WebRTS is this: WebRTC in the real world: STUN, TURN and signaling - the signal level is extremely high.

Below I keep a bunch of links to specs and software that I’ve looked at.

Browser Support

Support for WebRTC in browsers is restricted to Chrome and Firefox, but both Edge and Safari have it under development.

Personally, I believe that in the ²⁰¹⁷⁄₂₀₁₈ we should be able to use this technology with ease.

Code examples

a step-by-step video chat application.

WebRTC and Socket.IO

Most examples of WebRTC focus on audio and video, but the RTCDataChannel is also very interesting because it allows a “socket-io”-like interface directly between peers. In fact, there is even a Socket.IO P2P project already, so you can use the same API everywhere.

Infrastructure

If you plan on using WebRTC, you might want to have your own STUN/TURN servers, with proper authentication. If you plan on multi-user video, then a Multipoint Control Unit is a wise investment.

Ready-to-use Conference software

Spreed WebRTC: all-in-one solution for multi-user video conferencing. Core server in Go, client powered by Node.js and Websockets. Includes support for Desktop Sharing with Chrome and Firefox. Requires a separate TURN server, but recommends CoTurn (see next section). They sell a turn-key hardware/software solution, Spreedbox, that looks really good…;
BigBlueButton - current version only uses WebRTC for audio. There is a HTML5-client in the works with full WebRTC support. Probable the most tailored to classrooms, lots of useful tools (chat, presentations with annotations, voice control, pools, audio, video, SIP dial-in). I’ve been using this software since 2010-ish;
BlueJeans: Comercial, doens’t mention price, so you probably can’t afford it, but impressive set of supported software.

STUN/TURN servers

In case you need a STUN/TURN server, your best bet is probably coturn. It has everything that you’ll ever need.

An (worse) alternative is restund. The main developer doesn’t have a repository available.

A forked version or restund is available, and there is a simple Docker image for restund that you can use to get quickly up-to-speed.

Multipoint Control Unit and Selective Forwarding Units

Apart from commercial MCU’s (like the Cisco MCU), there are a couple of OSS projects you can look at:

the Lynckia project has Licode that includes a MCU, Erizo;
Janus: the general purpose WebRTC Gateway - looks good, small and simple;
Medooze has a MCU, with an openSource variant, that should support WebRTC. It does seem to require a SIP server though…

Other providers:

AhoyConference has a download for their server, including a RaspberyPi version, with a 5-user license included. This solution includes support for screen sharing with a Chrome extension;
VideoBridge is a SFU, part of the Jitsi project. The entire project has a lot of goodies.

I wish this could happen here

melo@simplicidade.org (Pedro Melo) — Sun, 22 May 2005 00:18:43 +0000

Check out http://arstechnica.com/news.ars/post/20050519-4925.html. I quote my favorite part

The plaintiffs do not know the identity of the persons they wish to sue, let alone the details of precisely what was done by each of them such as to actually prove infringement. Such facts would only be established after examination at trial. […] It is sufficient that they show a bona fide claim, i.e., they they really do intend to bring an action for infringement of copyright based on the information that they obtain, and that there is no other improper purpose for seeking the identity of these persons.

Nevertheless, the court found IP addresses deficient as a justification for forced identification, and they rejected the argument that the broadband companies were in possession of documents detailing who these users are in real life. With regards to this latter issue, the court rightly noted that matching an IP at any given time to a user constitutes more than re-producing information (e.g., there’s no peice of paper they could surrender; rather, they’d have to investigate themselves). Along similar lines, the court said that the evidence presented amounted to nothing more than hearsay. As you can see, the gist of the decision centers not on ideology or copyright analysis, but on the rules of evidence.

This is really interesting. I’m specially impressed by the notion that when an ISP gives information about a user based on the IP address, the court compares this to hearsay.

Of course, this was in a Canada court, and I don’t think that we’ll see something like this in Portugal anytime soon.

P2P? Think NNTP...

melo@simplicidade.org (Pedro Melo) — Fri, 06 May 2005 11:41:50 +0000

Celso wrote about using P2P technology to distribute content, in the context of blogging.

There are two types of content that you might want to distribute: the syndication feeds, and the HTML pages.

The syndication feeds is a hot topic right now, specially in the Feedmesh group. Feedmesh already has notification distribution and it seems to be working great. In the two previous weeks there where some messages about full content distribution of feeds in the Feedmesh mailing list.

My personal view about syndication feeds distribution is well known to Rui and Nuno who are forced to listen to me every time the subject comes up. I’m a firm believer that NNTP is the way to go regarding the distribution of RSS/Atom feeds. Notice that I’m not talking about Usenet, but the NNTP protocol itself.

If you use NNTP to flood your content network, and write the files in a easy-to-export layout so that you can put any HTTP server over it and use that as a syndication proxy, you have a basic Content Distribution Network (CDN) for small files.

There are a lot of small issues that can be improved. There is no need for each node to keep a copy of every feed. If the logs of the HTTP server are used as a lazy-subscription mechanism, falling back to plain HTTP Proxy when the feed is not found locally, but signaling the NNTP server that he should accept that feed from now on, you have a organic beast that follows the trends of your client base. You can also expire old feeds that nobody seems to be reading, or expire only the feed itself but keep the meta data of feeds that are not updated (so you can answer 304 to our clients). We can (and should) store the feed data as GZiped files, so you don’t need to GZip-on-the-fly.

You can point out a lot of drawbacks to this system: the publisher looses statistics of readership, you can’t do password protected feeds (at least not in the traditional basic HTTP authentication sense), among others. But those are the tradeoffs that we make to save yourself a lot of traffic.

My personal side-effect is that if this kind of infrastructure was available, we could extend Feedmesh to the syndication clients. The current Feedmesh is only useful to be used between the major syndication aggregation services because it sends all the feeds that where modified. But if each node in this CDN also provided a filtered Feedmesh feed based on subscriptions of clients, then they could remove all the pooling and switch to a trigger-based content retrieval if they so wished (care should be taken to prevent a swarm of request, but that could be done by controlling the stream of updates sent by this service).

The question is who will support this. Well, the optimistic person inside me, would like to believe that the ISPs would be interested to provide a better service to it’s customers, and if they had a simple system that just worked, they would install it on their own networks, and give it to their clients. The advantages are that they would save some bandwidth (negligible in a world of Bittorrent, I know) and give better service to its customers.

But the main push, the main collecting of feeds seems to be a perfect fit to the current syndication aggregation services. They already need to do it because their business model is based on having the most fresh content, so each one of them fetches the changed feeds whenever we ping them. If they start pushing the content via NNTP, we just might have the seed we need to implement something like this.

The HTML distribution part is different, and I think we are starting to see the solution: Google Web Cache.

Google is happy to do that service for you, to be your Coral Network. It seems obvious to me that Google value is related directly to the freshness of their own index. So they want your HTML as soon as it changes. So if Google taps the Feedmesh notification stream, they can see two things: that a specific page has changed, so they can fetch it, index it and cache it (and feed their own GWA), and (as a bonus) mark that page as more than likely being a blog and with that improve PageRank by removing the problems that the blogs are causing them.

Akamai is probably going to be relegated to DNS and static content CDN from now on.