A GridRemote is a program running on a user device that can serve as an extension of the Grid. A GridRemote can be controlled by user programs running on GridWhale. This provides the user several benefits:
- GridWhale programs can automatically access data on the GridRemote (without forcing the user to upload them manually). Under certain conditions we might even do all processing locally (on the GridRemote) and thus never send the data to the cloud.
- GridWhale programs can take advantage of local compute resources. For example, a Luminous program could use the full power of the local computer (and thus save on cloud compute costs).
- GridWhale programs can have access to local resources, such as cameras, GPS, etc.
Installation
- The user downloads and runs a small stub program from GridWhale.com. Running this program installs GridRemote.exe on the computer as a Windows service.
- GridRemote generates an 8-digit code and sends the code to GridWhale.com. GridWhale creates a secret key for the remote, and sends it back. GridRemote stores the key somewhere safe (it will use the key to verify communications from GridWhale.
- GridRemote displays the 8-digit code to the local user and tells them to add the device in GridWhale. The user goes to GridWhale and clicks "Add Device" (or something) and then enters the 8-digit code.
- GridWhale now binds the device to the user account on GridWhale, which allows the user to control the GridRemote from their account.
Communication
On start up, the GridRemote connects to gridwhale.com to ask for commands. We connect via HTTPS and pass in a hash of the secret key (or something). We use a long-poll to wait for commands to come to us.
When a command appears, we process it and call back with a response. Then we ask for another command.
GridWhale keeps track of all commands and resends them as appropriate. For example, GridWhale sends command A. Meanwhile, a program requests command B. GridWhale waits for the GridRemote to call with the result to command A. If the remote returns a different command or asks for a command, we re-request command A. Once GridWhale receives the result to command A, it dispatches to the caller and sends command B.
Deployment and Upgrade
Most of the implementation of the GridRemote is carried out by separate programs downloaded from GridWhale.com by the GridRemote service. In general, these are invisible to the user, though we almost always confirm with the user before using one (see below).
These programs are always GridWhale programs. We do not support third-party programs being installed.
Security and Permissions
Security and permissions is controlled from GridWhale, but there are cases where we ask the local user (on the GridRemote) for confirmation. In all cases, they should just be a simple Yes/No confirmation.
By default, installing the GridRemote provides very limited access (e.g., CPU access but no file access).
When the user wants to access a file/folder on the Remote, they click on "Add External Folder" (or something). The user picks the GridRemote to access. They also one of the following security settings:
- Allow access until canceled.
- Allow access for 24 hours and prompt after that.
- Allow access for one hour only.
Whatever setting they choose, they will get a prompt on the local machine to accept or reject the request.
GridPort
We could also create a server version of this (which we call GridPort). This allows GridWhale to access resources inside the firewall.
The main difference between GridPort and GridRemote is that the former is designed to be configured by standard server configuration tools and patterns. For example, instead showing UI to ask for permissions, we require permissions to be granted in a config file on the server. This gives administrators complete control over what GridPort exposes.
GridPort would allow access to SQL stores, file shares, etc. For example, we could implement my Spotfire clinical visualization by adding a single GridPort installation that can access the raw file shares.