Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 13 Next »

Presently the components of OpenVisualizer operate within a single process. We wish to experiment with extending this operation across processes and machines, as shown in the diagram below.

Messaging

Presently we implement EventBus messaging with PyDispatch, which provides communication between threads in a single process.

Between Processes

On an embedded LBR, we plan to use the native POSIX message queue due to its built-in availability. The posix_ipc module for Python provides access to this functionality.

Remote GUI host and LBR

We wish to minimize the processing required by the LBR due to its limited resources, particularly for a sub-Linux implementation. Therefore, the LBR pushes information to the Remote GUI. However, the GUI also may signal to the LBR, for example to toggle DAGroot status.

Although the LBR is the messaging client, the GUI must make the initial contact to the LBR to establish a tunnel for communication. It simply is not feasible to expect a PC user to open a port for access, even ports 80/443. However, we plan to use a reverse SSH tunnel, as shown in the diagram above. The reverse nature of the tunnel allows the LBR to access the server port on the GUI host.

WebSockets (RFC 6455), as a bi-directional messaging protocol, supports our requirements. As a standard, it also supports OpenWSN's approach.

Tools

LBR

RoleToolNotes
WebSocket clientwebsocket-clientInstalled with pip.

GUI Host

RoleToolNotes
WebSocket servergevent-websocketIncludes dependencies below
WebSocket server dependencygeventPython network library
gevent dependencygreenletPython concurrency library
gevent dependencylibeventEvent library for select/poll
Tunnel to LBRPuTTY

Command line:
plink -ssh -N -T -R 8000:localhost:8000 -pw <xxx> user@lbrAddr

 

Alternative Messaging Approaches

We researched the projects below, but they are not our first choice. We may investigate further at a later date.

Nanomsg and ZeroMQ provides a common messaging API for a variety of endpoints – threads, processes, and machines. They are open source, but not standards. However, it would be efficient to use a single tool for messaging across all domains.

Nanomsg is developed by Martin Sústrik, the original author of ZeroMQ. Sústrik left ZeroMQ due to a dispute over trademarks, as described in a Linux Weekly News article.

Celery provides a distributed message queue, but is more heavy-duty and requires a message broker.

  • No labels