Cloud SR140 Remote Module

Initial exploration from Nathan on a remote SR140 or Cloud module.

We would need two different modes of operation. One for a cloud module user (client), one for a cloud module provider (server).

Cloud module client

A cloud module client would make itself look like a remote module.It would be a virtual module that registers with the driver as a module with a different machine number. Perhaps a single client should be able to look like multiple remote modules with a single machine number. Not sure that this is possible.

Upon startup, it would do whatever licensing is required, contact the cloud module server for the remote system in question, and perform authentication.

Once this is done, it would pass millennium packets received by doing a millennium packet receive from the driver through the remote network connection to the cloud module server. And it would pass millennium packets
received from the cloud module server through the remote network connection to the driver by doing a millennium packet send. Would it need to interpret some packets? Would it need to create packets?

Cloud module server

A cloud module server would make itself look like remote a driver. It would be a virtual module that registers with the driver as a module with a an address which is a driver address with different machine number. A single single server will need to be able to handle multiple clients with a single machine number (therefore on a single system). Upon startup, it would do whatever licensing is required, and wait for connections.

When it is contacted by a cloud module client, it would perform authentication. It will create a new process or thread for handling this connection. The new process will be a virtual module that makes itself look like a driver with a different machine number. The original process/thread will continue waiting for new connections.

Once this is done, it would pass millennium packets received by doing a millennium packet receive from the driver through the remote network connection to the cloud module client. And it would pass millennium packets
received from the cloud module client through the remote network connection to the driver by doing a millennium packet send.

Would it need to interpret some packets? Would it need to create packets?

Open issues, future items:

Way to specify a machine number when starting virtual module? For shared library version via Bostsrv and command-line version?

Way to look for remote modules? Something that advertises available modules on specific sites?

Originally planning on one gutted virtual module (GVM) per remote module. Can a single GVM handle packets for multiple remote modules with the same machine number? Can it handle many remote modules and machines?

Licensing for starting up GVM?

Authentication and security for contacting a remote module server and for connection? SRTP?

Decide whether to use conditional compilation to produce cloud firmware, or whether to use startup/command line options that enable different modes of operation.

In root.h, most of the items would not be needed. Possible ways to deal with this are
1) Have an alternate list used for the cloud firmware only.
2) Have each of the startup functions check some global variables that will allow it to determine that it is cloud firmware and not actually start.
3) Add another field to the table that indicates what type of firmware the task is for.
#3 is the most flexible.

The ones I believe would be required are:

BCD_InitStart
PH_InitStart

Unsure about:

DsInit (for debugging?)
fvlist_Init (for linked lists, if necessary)
UDP_Init (If exiting UDP code will be used)
OBP_StaticInit (If OBP is required)
Admin_InitStart - (May be required for handling setup?)

Goals

Background and strategic fit

Assumptions

Requirements

User interaction and design

Questions

Below is a list of questions to be addressed as a result of this requirements document:

Not Doing