Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SPIKE] Separate client from server task list #212

Closed
erikquinn opened this issue Dec 15, 2016 · 7 comments
Closed

[SPIKE] Separate client from server task list #212

erikquinn opened this issue Dec 15, 2016 · 7 comments

Comments

@erikquinn
Copy link
Collaborator

erikquinn commented Dec 15, 2016

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 VoIP PTT Audio #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 VoIP PTT Audio #203)
@n8rzz
Copy link
Owner

n8rzz commented Dec 20, 2016

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.

@n8rzz n8rzz changed the title Separate client from server Separate client from server task list Dec 20, 2016
@n8rzz
Copy link
Owner

n8rzz commented Dec 20, 2016

@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.

@n8rzz
Copy link
Owner

n8rzz commented Dec 21, 2016

@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
Copy link
Collaborator Author

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

@n8rzz
Copy link
Owner

n8rzz commented Dec 22, 2016

Slack for iOS Upload.jpg

  • 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
Copy link
Collaborator Author

erikquinn commented Dec 22, 2016

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.

@n8rzz n8rzz changed the title Separate client from server task list [SPIKE] Separate client from server task list Jan 15, 2017
@erikquinn
Copy link
Collaborator Author

This issue was moved to openscope/openscope#124

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants