Peer-to-Peer support default setting in the next OS update

Announcements
1

image
image1024×512 94.3 KB

(image created using stable diffusion)

A new minor update to the stable release of the info-beamer OS will be available soon. One of the changes that’s worth its own post here is the new default setting for the Peer-to-Peer feature. With the new release, the peer-to-peer feature will be enabled by default for newly set up devices.

What’s the peer-to-peer feature

  • It allows a device to retrieve assigned content from other local devices in the same network. This results in reduced external bandwidth usage, and as a result faster downloads if multiple devices have the same content assigned to them.

  • Since the last OS release, system updates can also use the peer-to-peer mechanism. That way multiple devices within the same network will most likely only have to download a new operating system update from the internet once as they can then locally share it. Of course updates are cryptographically signed to ensure they have not been tampered with.

  • Devices can calculate how synchronized they are and auto-correct clock related problems automatically. They do this by periodically sending small messages to other local devices and taking measurements on how long those take to respond. This is an important feature for any video wall (or otherwise synchronized) installation as it allows devices to check on each other.

  • The transfer of data among local devices is fully encrypted. Additionally, just like with content downloads over the internet, all data is checksummed before being used.

  • The Peer-to-peer feature is purely additive. If a device cannot download content from any other local device it will fall back to downloading content over the internet instead.

  • Additional minor features, see below.

What the peer-to-peer feature is not

  • It does not make your content available to anyone outside of your local network.

    • A device with the peer-to-peer feature enabled broadcasts its presence to other local devices within the same broadcast domain by sending broadcasts to 255.255.255.255. Such broadcasts do not cross routers. In a typical small network setup with a WiFi router acting as an internet uplink, pakets will only be seen by other devices connected to the same router.
    • Any communication targeting the peer-to-peer related services on a device are firewalled (starting with the next release) in such a way that they are not reachable from outside the assigned subnet. So if your device has been assigned the IP 192.168.1.101 with a subnet mask of 255.255.255.0, anything outside of that network (192.168.1.0/24) will not be able to reach peer-to-peer related services on a device.

  • It does not allow anyone with network access to your device to see what content is assigned to the device.

    • The sharing of content requires the requesting device to already know exactly what content it wants. So without the exact cryptographic checksum of a file an outsider cannot request or decrypt the content.

  • It does not allow other devices within the same to control what a device is showing on its screen. Assigning content is done by the info-beamer backend. It also does not change the trust relationship between the device and the local network: The device does not trust other peers and the peer-to-peer feature cannot be used to push content to a device. It’s only used by a device to pull content from other devices. Of course all content is cryptographically verified before being used.

  • While it opens up a two new ports (UDP 11111 and TCP 111111), they are only reachable from within the local network. Additionally the service implementing the peer-to-peer content transfer is written in Python and sandboxed. So a lot of bug classes caused by use of unsafe implementation languages can be ruled out.

  • It’s not (and never will be) a required feature. You can set up devices without peer-to-peer support or disable peer-to-peer using the device configuration editor.

Why enable by default?

With the next release, any newly set up device (so one where you just unzipped the install.zip or wrote install.img.gz to a fresh SD card) will enable peer-to-peer by default. Nothing will change for existing devices.

  • The peer-to-peer feature was introduced 3 years ago. Since then one third of all devices have the feature enabled. The feature has been used millions of times to accelerate downloads for content assigned to such devices. Here’s a small snapshot from a device that heavily benefitted from using the peer-to-peer feature:
    image

  • There have been zero issues within the last 3 years resulting from the peer-to-peer feature. Its usage is completely transparent as it is purely additive and if devices with peer-to-peer enabled cannot reach each other, all content retrieval seamlessly falls back to using the internet.

  • A lot of video wall installations do not have the peer-to-peer feature enabled, despite adding lots of benefits like automatic time synchronization checks and sharing downloads. This resulted in quite a few support mails to help with enabling peer-to-peer in such cases.

  • Additional minor features enabled by having the peer-to-peer service running on a device:

    • local registration allows you to add a newly started device within your local network to your account by simply selecting it within the device registration dialog. Behind the scenes your browser directly contacts the device to ensure it is indeed locally reachable. This allows you to add devices in your local network quicker, even if you cannot see the registration PIN and you didn’t enable the auto-add feature already.
    • A local device can soon act as one type of second factor for authentication. This can help you protect your account: Even if a third party get access to your account email and password, they would still have to issue the login request from within the network used by your devices. There will be an additional announcement post once this feature is available.

  • In the near future, new scheduling capabilities will be available for packages across info-beamer. Due to how video walls work right now (each device only uses the local time to derive which content to play when), scheduling is pretty much impossible for video walls. The synchronization and discovery of other local devices offered by the peer-to-peer service will allow setups to seamlessly discover other local devices running the same setup and help them work together. This can be used, for example, to make synchronized scheduling decisions for videos walls. A new p2plib.py library will be released soon that offers an easy way to implement leader/follower logic with encrypted communication across multiple devices. Stay tuned.

To summarize: There are no downsides and only advantages. Having peer-to-peer enabled for new devices makes sense as the feature had more than 3 years to mature and proof its usefulness. Existing devices remain unchanged, but you can of course manually enable peer-to-peer support on them as well.

Feedback welcome.