Networked communication

OCESS / orbitx

Rewrite of OrbitV, maintained by Patrick, Gavin, and contributors

MIT License

10 stars 18 forks source link

Networked communication #3

Closed pmelanson closed 5 years ago

pmelanson commented 6 years ago

We'll have to figure out what method we'll want to communicate with. For example, have a networked mySQL database, or have the cnc server send updates or a full state by sockets.

We should be able to have a client do absolutely zero simulation, but still get frequent updates from a lead server about what the physical state is.

pmelanson commented 5 years ago

We decided on GRPC for this, since it makes writing RPC calls very simple, integrates well with our protobufs, and is light on code.

See src/networking.py for this implementation.

pmelanson commented 5 years ago

We kind of ignored networked communication for CS 493 and 494, but now that I'm finishing OrbitX up, we should finish and polish this up.

I'm thinking that a proper mirroring setup will have the following:

an intuitive distinction between what programs are doing the simulating and what programs are read-only copies (basically, come up with a consistent terminology, and maybe package two distinct binaries and have distinct CLI flags)
a way of changing between the two or three telemetry modes present in OrbitV (network-only, network and physics engine interpolation, and physics engine-only with no network communication)

pmelanson commented 5 years ago

I'd say this is closed with c081a88b7b2eab8390aa1474c75cdeb7faa98961 (the last commit in the network-topo branch).

We now have a launcher that shows users what programs they can launch, and an explanation of what they do.

Currently, we have a non-networked program for local training, a headless server, and HAB/MC flight clients.