# Installation 

## Server and client

After cloning, virtual environment with python3 needs to be created.

Create virtual environment with python3 and requirements file:

```bash
virtualenv ~/venv/socket -p python3
source ~/venv/socket/bin/activate
pip install -r requirements.txt
```

## Server side

### ID associated with websockets

Normally, the designated user is `nixWorker`, and should be created if not present. `nixWorker` requires credentials to access the database (username, password) which should be provided in its `.labkey/server.json` file, refer to `labkeyInterface` documentation. Also, websockets will require `nixSuite` to be installed and pointed to by `.labkey/setup.json`.

### Firewall

Script `open_port.sh` will program the firewall on server side to limit websockets to only work for a limited number of clients. Both server and client ip need to be provided in `serviceScripts/env.sh`.

To find IP address, run

```bash
ip add show
```

Select the IP address with interface that has the highest probability that it points to a physical interface rather than a docker connection. In most systems this is eth0.

The same call can be done on all clients that will be allowed to connect.

Run `sudo open_port.sh` to modify firewall to accept connection on the designated port.

Run `serviceScripts/start.sh` to start the server. Look for output/log at `~/logs/socketServer.log`.

## Client side

No install is required. No dependencies, since all communication is text only.

## Testing

### Client side

```bash
~/software/venv/socket/bin/python send.py server:TEST:1
```
### Server side

#### Open port

To check whether packets from client reach the host, use 

```bash
sudo tcpdump -i enp68s0 'tcp port 8000' -v
```

This prints traffic to port 8000, say. Also helpful for determining actual IP address of the request; sometimes the actual source is behind a firewall and the IP could be mangled.

This address should be added to the `$IPCLIENT` address list in `env.sh` for `open_port.sh` to allow connections.

#### Allowed origins

Websockets further limits allowed connections to clients listed in `websocketServer.py`. The origin is hardcoded as a single name in `send.py` and as a list in `websocketServer.py`. For the communication to work, the name from `send.py` should be a member of the `websocketServer.py` list.

The error associated with mis-configuration of origins is:

```bash
websockets.exceptions.InvalidStatusCode: server rejected WebSocket connection: HTTP 403
```

# Features
## Concurrence

Websocket will respond to any call submitted to the server with a separate invocation of the handler. This means that submitting multiple jobs will result in concurrent execution of all jobs, which might bog down the server. Websocket itself won't deal with scheduling, but the handler in `websocketServer.py` could be rewritten to delegate job handling to scheduler such as torque or slurm, should one run on the server.