Network Control Architecture

The first prototype of the Rendez-vous Point (RDVP) Server and Client was completed today.

This is a network communication scheme that aims to answer some of the basic questions that come up about communication between different devices.  Namely how do they find one another and communicate?

Objectives include:

• Minimal or no configuration
• Maximize discovery of services and capabilities
• Common protocol
• Easily extensible
• Interface available to wide variety of devices
• Agnostic as to whether operating on local network or internet

Some of the first uses intended include:

• Discovery mechanism for purposes of WebRTC
• Signalling mechanism for purposes of WebRTC
• Remote control of Pi locally or over internet

The basic principles are:

• There is a centralized server (the RDVP Server)
• Everything connects to it
• Password protected
• Primary functions include:
• Act as a transparent bridge between clients who want to communicate directly.
• Allow Admin control
• Present web interface
• Enforce tightly-defined roles
• Three tightly-defined roles for systems connecting in:
• Admin Client
• Speaks RDVP protocol (JSON over WebSockets)
• Can monitor and control activities and state of Server
• Likely spawned from web interface, but also possibly from other system such as those implemented in Python in the first prototype client.
• Server Client
• States ID and waits for messages to be sent to it, which it will respond to as-appropriate.
• No messages will be sent to the Server Client unless a Client Client indicates a desire to connect to it, and the RDVP Server bridges them.
• Client Client
• States ID and intended Server Client to connect to.
• Connection to Server Client will immediately be bridged or this client will be rejected and closed.

The expected use of the above is:

• Server Clients might be anything "dumb" (like a Pi program) which is waiting to be controlled but doesn't know by who.  Simply announce itself and wait.  This also makes internet communication and control possible since the RDVP Server can easily live on the internet.
• Client Clients are expected to be initiated from more knowledgeable control mechanisms.  This might be from a web interface, or other purpose-built mechanism.
• Admin Clients are meant for systems which want to discover Server Clients to connect to, or otherwise observe state.

Having a central server which brokers communication also allows for snooping of communication as well as control over systems connecting in.

Future projects should be able to make use of this scheme as well.

A very specific first-use-case will be attempting to initiate WebRTC with the UV4L server.

This UV4L server is a bit opaque but does have a webserver which also responds to WebSocket connections leading to a WebRTC connection.

I don't want the webpage, I just want it to give up its video stream.  In the diagram which follows, there is a bridge between the UV4L server and the RDVP server.  This is essentially a male-to-male connection which itself is a bridge, making connection to the UV4L server possible remotely.

Here is a rough architecture diagram: