To the left you can see the interface for a prototype video viewer. This viewer provides content that has been made available from a custom blockchain implementation that we helped create with CableLabs in 2016.

Working Bits Consulting developed the REST server used by this interface. The server provided interfaces for Content Producers, who made their videos available to distributors. The distributors also had an interface to make the Content Producers' available to their own end users. And then there is this interface that allowed end users to rent, purchase, and share content with other users. All of these steps were stored on the blockchain, providing the various actors the ability to monitor the activity on their content.

Working Bits Consulting also contributed to the blockchain implementation backing the server. We provided the Rhino-based transaction validation engine, which limited validation runtime and memory usage, while providing access to the relevant blockchain data. We also wrote the consensus engine that allowed multiple contributors to the blockchain to agree on the next block to be added to the chain via a voting mechanism. Finally, we wrote an object store for the blockchain's internal persistence.

To the right you can see the EBaD interface, as shown at the CableLabs Summer Conference in 2013. This was a follow-on project to the CableLabs EARS project. Working Bits Consulting wrote the EARS Server code, written in Java, consisting of multiple binary interfaces supported by a MySQL database.

The server could either directly monitor multicast video streams, or support UDP receipt of a subset of the stream packets as seen from various parts of the network by EARS Agents. The Agents reduced the stream volume by removing the audio and video data that was not required for the EARS system analysis.

The EARS Server also supported an alerting interface that allowed external processes to gain up-to-date visibility on the information the EARS Server collected.

A substantial part of the system was supported by a Generic Server model written by Working Bits Consulting. This model can be used to create a server that handles network communications in a generic manner, whether the communications are in TCP, UDP, Multicast, or even as an internal memory-based message queue. Each communications protocol interface manages the concept of a "client", and creates a developer-supplied class that parses messages from the client, and then processes them. This processing is also customizable in terms of threading model. The server can run as a single thread (most useful in initial development), a thread-per-client model, or a thread pool model, where each request processes in its own worker thread based on a developer-supplied policy.