Accelerated peer-to-peer content distribution

info-beamer hosted can soon optionally distribute content locally among your devices. This can speed up downloads of large files to devices located in the same local network.

Introduction

info-beamer hosted is the most advanced digital signage platform available for the Raspbery Pi. Today we introduce a unique feature that makes it even more powerful and allows types of installations that have been painful to run before.

Getting content on your devices and showing it is what digital signage is all about. At least from the technical point of view. Every time you assign new content, e.g. image/video/fonts or even new code to your devices, info-beamer hosted makes sure that this content eventually reaches your devices. Preferrably as soon as you click on Save. info-beamer hosted achieves this by creating a new synchronization file that tells each device which content files are required to bring your screen to life. Each devices is then notified that there's a new synchronization file. Once received, each devices will then reach out to the info-beamer hosted content distribution network to fetch all pieces of content it hasn't already downloaded before.

info-beamer hosted uses Amazon Cloudfront for content distribtion. Downloads always use secure HTTPS connections. Since Cloudfront has basically infinite bandwidth, even distributing big video files to many devices isn't a problem at all. The content distribution looks like the following image. The content (stored in the "cloud") is retrieved by each of your devices as fast as possible:

The bandwidth bottleneck

If you look at the above image, you'll notice that each of your devices has to individually download the content from the info-beamer distribution network. If you have multiple devices in the same physical location and the same network, each of them still has to reach out to the internet to fetch new content. That's clearly wasteful, especially if you have plenty of devices sharing the same uplink.

Wouldn't it be nice if only one of your devices would download new content from the internet and all other devices would fetch this downloaded content locally from that device? Not only would the initial download be faster (as only one device is using the internet connection) but transferring the content between your devices could also be faster since it uses your local network.

Peer to peer (P2P) to the rescue

The new peer to peer (P2P) feature enables exactly this. If enabled, the content distribution may now look like the following image instead. One of your devices fetches the content from the internet, while all other local devices try to fetch the content from that device:

This might greatly reduce the time it takes to get big videos to many devices. It makes sense to activate this feature even if there's only two devices (like in the images): In the optimal case you cut the required internet traffic in half. If you have a slower uplink, this can greatly reduce the time it takes until content is synced to all your devices.

How to enable P2P support?

All you have to do is check the [X] Enable P2P checkbox in the device configuration editor and apply the new configuration.

FAQ

Does this cost extra?

No. This is an optional feature available for all devices and customers.

Will my devices download content from random strangers?

No. The doesn't happen by design. The P2P feature is only between devices in your local network.

The technical explanation is that device discovery uses broadcast UDP packets to 255.255.255.255. This address is never routed to other networks.

Will my devices upload content to random strangers?

No. Your devices will neither upload or download content to other devices "on the internet". They will only transfer data from other devices in your local network.

Is it secure?

Yes. Transfer of content between devices is encrypted and content received through P2P downloads is cryptographically verified to make sure that it hasn't been tampered with. Just like with all other downloads. An observer can see that devices transfer data but can't peek into the data. You can learn more about the details in the security section or the section at the end of this blog post.

Are P2P transfers encrypted?

Yes. All content transferred between local devices is encrypted. There's no way to decrypt transferred data unless you already know what's inside it. In which case decrypting it is pointless as you already know the content. In other words: An attacker that doesn't know what is transferred between your devices can't decrypt any transferred data.

Can my devices be hacked through the P2P feature?

No. Just like the rest of the info-beamer hosted system, everything has been designed to be as secure as possible: The peer to peer service running on your devices is heavily sandboxed: It has no access to any other data on your devices, can't write the the SD card and is running in its own limited user account. Additionally it's written in a safe programming language and its memory consumption is limited.

Enabling the P2P feature doesn't compromise any of the strong security properties of the info-beamer hosted operating system: Devices still only trust downloaded content if it has been signed by the info-beamer hosted backend. Just as before, encryption and digital signatures ensure that it is never possible to inject arbitrary content on your devices. They only play what is configured through the web dashboard. Using P2P doesn't change any of that. It's just a new optional way to retrieve that content.

All content downloads are always encrypted to make sure that confidentiality is ensured. A passive local observer or man in the middle can't learn anything useful from just listening or even modifying traffic. If P2P transfers fail for any reason, the devices will fall back to using the internet instead.

Will this slow down my devices?

No. The P2P service is running at the lowest priority and its maximum memory usage is limited. It will never interfer with the content shown on screen. You can even use the P2P feature on older Raspberry Pi versions with less than 1GB memory without problems.

How do devices find each other?

The devices have to be in the same broadcast domain. For usual ethernet network setups this means that they have to be connected to the same switch. For WiFi they probably have to use the same access point and clients on that WiFi must be allowed to see each other. If your WiFi uses client isolation, P2P won't work.

From the technical point of view, UDP broadcast packets to 255.255.255.255 sent from one device must reach your other devices. info-beamer hosted OS is using port 11111 on both UDP and TCP for P2P communication. UDP is used for peer discovery while TCP is used for content query and transfer.

I have devices in multiple different locations. Is there anything I have to consider?

No. Peer-to-peer communication only happens between devices that share the same network. They detect this automatically and you don't have to configure anything. Peer-to-peer traffic never leaves your local network.

Is content really only downloaded once?

That's the optimal case: One of your devices would download the content from the info-beamer content distribution network while the others use P2P. In the real world this will not always happen. Devices might not yet know about each other, run into timeouts or other problems that prevent them from successfully using P2P to retrieve the content. In that case they will fall back to using the internet. You can see how much content was downloaded through P2P on the device detail page for each of your devices.

There are devices from different accounts in the same network. Is that a problem?

Not at all. Even better: If the same content is used across accounts, devices will even share that content between each other. Note that this doesn't reveal any information that devices from each of the accounts don't already know: Only bitwise identical files are shared and it's not possible to learn anything about content that isn't used across accounts.

Can P2P downloads be resumed?

Yes. Just like with normal content downloads using the internet, peer to peer downloads can be interrupted and resumed later. Your devices might even start an internet download, interrupt it due to, for example, a timeout and then download the rest of the file through P2P.

I don't want it. How do I disable P2P support?

Updated in 2021: For the first 3 years since P2P support was introduced in 2018 it has been an opt-in feature. Since then a lot of experience has been gathered from devices having the P2P feature enabled. We have not observed a single issue from having P2P enabled. As a result from info-beamer hosted OS 12 onwards, P2P is now automatically enabled on devices with multiple cores. This includes Pi2 and later devices.

You can explicitly disable it by creating the /config/no-p2p file (see here) or by using the configuration editor on the device dashboard page.

I have a question that isn't answered here. Help?

Feel free to contact support. We'll answer all questions and expand this FAQ.

Technical details

This section is intended for those of you that want to learn more in-depth details about how the P2P feature in implemented. The in-depth security discussion is already available here.

If P2P is enabled, info-beamer hosted OS will open inbound UDP port 11111 for peer discovery packets. Each device will broadcast discovery packets to 255.255.255.255 every 3 seconds. The packet contains the OS version number, a random nonce and the local device time.

If a device receives such a packet, it will respond with a packet containing the received information and the local time. The device that initially sent out the discovery packet can check the bounced nonce to make sure that it's a proper response (and not one that has been blindly sent to the device) and use the received timestamps (its own send time as well as the remote time) to find out the network latency to the peer as well as an estimated peer local time. This time information allows all peers to detect time differences that can be corrected by restarting the NTP client service. This feature alone if pretty useful if you're running any kind of video wall installation as those depend on a synchronized clock.

A side effect of these discovery packets is that each device can find out the IP addresses of all other devices just by looking at the source address of valid response packets. This list is used to initiate peer to peer downloads.

If a device wishes to download a content file using P2P, the syncing process that normally reaches out to the internet instead contacts the local P2P service. info-beamer hosted uses content based addressing for all files and the device submits the MD5 checksum (content_md5) for the piece of content it want to download from its peers to the locally running P2P service. This content_md5 value isn't directly used to query the other devices as it would allow a passive observer to use this value to directly download the content from the info-beamer content distribution network. Instead a derived value (public_id) produced using an HMAC is used for all queries. Other devices that already have the same content available locally can calculate the same public_id and therefore know which file was requested. An outside observer can't use this information as there is no way to invert an HMAC.

The transfer query is sent to all detected peers in parallel using HTTP on port 11111. The device then waits for a response (or timeout) from all peers to detect which peers can provide the content. The device initiating the P2P transfer always uses a peer with the least number of already active transfers. It then directly contacts that peer to start the transfer. All transferred data will be AES encrypted using yet another value content_key also derived from the shared secret content_md5 value.

Selecting the peer with the least amount of alreay active transfers will automatically load balance P2P transfers between all local devices. It also prevents a single device from becoming overloaded. There is an upper limit of 20 transfers that a single device is willing to handle. Additional transfer requests will be rejected. The P2P process is single threaded and uses a process with the lowest priority so it never interferes with the running visualization on screen. The peer to peer services itself only relays the transferred content back to the syncing service. It never writes to the SD card directly and has only limited sandboxed read-only access to files on the device.