[SPIKE] Separate client from server task list

[erikquinn]

From @erikquinn on December 15, 2016 17:5

Divisions will need to be made on which tasks are to be done locally in the user's browser, and which tasks will be done by the server.

Divisions of Responsibilities

Client-Side

• all canvas operations
• all data block manipulations
• all projected positional information (limited)
• all conflict detection (but not collision detection)

Server-Side

• all position/physics calculations
• all fms manipulations
• all collision detection (but not conflict detection)
• all tracking of game events and score

---

Exchanges of Information

Server-Side

• send updated positional information to clients each cycle
  • note that this is literally just the Position, altitude, and heading that is needed by the clients.
• send updated flightplan information to clients when it changes
  • includes each aircraft's flight plan route and filed altitude.
• send voice audio to appropriate clients when received (see n8rzz/atc#203)

Client-Side

• send user's commands to server
  • normal comands, plus changes in airport, pausing, etc.
• send voice audio to server when the PTT key is depressed (see n8rzz/atc#203)

Copied from original issue: n8rzz/atc#212

[erikquinn]

From @n8rzz on December 20, 2016 3:59

There will be a lot of pieces that will need to change, be created, or moved in order to successfully accomplish this split. Here are a few major ones, that could be tackled now(ish):

• Restructure departure in airport.json - Zube n8rzz/atc#229
• separate running of commands from AircraftInstanceModel Zube nr8zz/atc#181
• move airport load to endpoint that returns completed airport model built by server
  • create AirportCollection and AirportModel on the server that loads each json file into memory
• Abstract arrivals and departures to be independent of the airport model. their only job is create aircraft with the specifications spelled out in the airport.json.
• create arrivalCollection and departureCollection to manage creating arriving and departing aircraft.
• create SpawnScheduler to createAircraft at a specific interval for a specific route Zube nr8zz/atc#235
• Implement toJSON/fromJSON methods for AirportModel, AircraftCollection and AircraftModel
• create way for client to obtain updated aircraft information from server every n seconds depends on nr8zz/atc#214
• create way for commands to be issued and correct aircraft to respond to them, while also informing other clients of the change

The endgame with the aircraft is to have a single collection of all the aircraft models in the sim that is portable and easy to work with on both the server and the client.

This list will be added to and issues will be created from this list soon.

[erikquinn]

From @n8rzz on December 20, 2016 4:4

@erikquinn I propose that this issue be treated as a placeholder for thoughts and ideas pertaining to the split of client and server. From here we can then create actionable issues that are of manageable size. We can use this issue as a sounding board and note pad.

[erikquinn]

From @n8rzz on December 21, 2016 5:2

@erikquinn I am beginning to think that Redux may be a solution for transfer of data, history, replay, and overall state management. I've been toying with the idea of using it for a while and now my mind just keeps coming back to it.

If you are unfamiliar, Redux provides a way to predictably change the application state. It's typically lumped in with React (which is how I have come to know it) but it can be used on its own without React.

It just makes sense. It checks several boxes:

• allows for the server to assemble data that can be consumed by the client on load
• allows for a re-playable app history
• allows for a connecting client to load with a current (in progress) simulation
• provides a lighter weight way to express changes in the application state

Thats really what we have here: a state that gets updated in a predictable way.

• create aircraft (arrival/departure)
• remove aircraft (landing/airspace exit/crash)
• update aircraft position
• issue command

---

I'm mostly typing out loud here to share where my head is at. This may not be the best solution, but I think it's something to thin about for sure. I'm a fan of Redux and I've used it a lot with React. It's a little weird to start with, just because it is so different to work with for a lot of Javascript developers. But, after a little while, it clicks and you realize why it is so powerful.

At any rate, I think this might deserve a POC so I can get in and get my hands dirty n8rzz/atc#234.

[erikquinn]

@n8rzz That does sound incredibly promising... just reading their own description of it sounds like exactly what we would want.

[erikquinn]

From @n8rzz on December 22, 2016 1:21

• Load happens, well, on load. we obtain the current airport and assemble arriving and departing aircraft based on the airport.json specifications.

• Update is where positions (and other stuff) are updated. This happens at a set interval and, possibly independent of that interval, this data is shared with the client(s). either via GET http api request/response or via socket connection.

• Command happens when a command is issued. the server receives it and broadcasts is to connected clients. It also acts on that command, if possible, with the available list of aircraft.

[erikquinn]

Reference the "update" phase in the above, depending on the role of the Player needing an udpate for its aircraft, it may only need a very limited amount of information to get by. There's two options:

1. Send all AircraftInstanceModels as they exist in AircraftController.aircraft.list Note: Requires less processing by the server, but requires more bandwidth due to the excess data

2. Extract only the pertinent information from each AircraftInstanceModel, and send that (when role='controller', as little as {callsign, position, flightplan_route} may be sufficient) Note: Requires more processing by the server, but requires far less bandwidth due to the minimal data

Depending on which is the limiting factor performance-wise for the server operations, which we have still yet to determine, one option may prove significantly better than the other.