Because we gate a lot of things off this.foo?, leaving the closed
websocket/pc/etc in-place was causing a noisy log, and mucking with
reestablishing a broken connection.
While I was in here, I fixed a style nit from yarn.
Signed-off-by: Paul R. Tagliamonte <paul@kittycad.io>
* Build out EngineConnection's retry and timeout logic
* Migrate the EngineConnection to be an EventTarget for other parts of the
code (mostly the EngineManager, but maybe others?) to listen to, rather
than having a boolean 'done' promise, and remove callbacks in favor of
the eventListeners.
* When a WebRTC connection is online, send a 'ping' command every 10 seconds.
The UDP stream likely needs something similar, but the connection is
maintained by the WebRTC video stream for now.
* Begin to migrate code to use a more generic object "send" helper
which can handle the JSON encoding, as well as connection retry logic
in the future.
* Add a watchdog to trigger 5 seconds after a connection is initiated
to cancel and retry the connection if it's not become ready by the
time it wakes up. This won't watch an established connection yet.
Signed-off-by: Paul R. Tagliamonte <paul@kittycad.io>
The front-end and the back-end communicate with three channels. The
first is the WebSocket connection to the Engine API. Once that
connection is online, a WebRTC connection is negotiated, which contains
one video stream from the server to us for the GUI, and a second, which
is a binary data channel from us to the server, which we send JSON over
for real-time events like mouse positioning.
The lifecycle of the WebRTC connection and the WebSocket connection are
tied, since if the WebSocket connection breaks down, the WebRTC
connection must get restarted (to get a connection to the *same* backend
that we have an open WebSocket connection to).
This starts a move to split the WebRTC and WebSocket pair to be managed
by a new class (EngineConnection), which will only start and maintain
the WebSocket and WebRTC channels. Anything using the EngineConnection
will be able to communnicate commands without needing to add control
logic for the underlying data channels.
Signed-off-by: Paul R. Tagliamonte <paul@kittycad.io>
We can create a enginelessExecutor that can be used for many of the
executor tests that will be much more performant for tests that don't
need the engine to actually do any modeling work.
* Intital async of executor
The execture now sends websocket message instead of calling functions
directly from the engine, When it does so it holds onto the id.
The engine is still returning geo/polys directly but I'm working make it
so that the UI doesn't need to know about that, so that we can switch
over the streaming ui.
Things left to do:
- it is still making both direct function calls and websockets, and the former should be removed.
- It does highlighting of segments and sourceRanges not through websockets and that needs to be fixed.
- Tests have not been adjusted for these changes.
- Selecting the head of a segment is not working correctly again yet.
* Rough engine prep changes (#135)
* rough changes for engine prep
* mouse movements working again
* connect to engine for startsketch, line, close and extrude
