Commit Graph

4 Commits

Author SHA1 Message Date
Andres Suarez
79023ee190 Update copyright headers from Facebook to Meta
Reviewed By: bhamodi

Differential Revision: D33331422

fbshipit-source-id: 016e8dcc0c0c7f1fc353a348b54fda0d5e2ddc01
2021-12-27 14:31:45 -08:00
Andrey Goncharov
9fc1d3cfb9 Ignore stale replies
Summary: Changelog: ignore stale replies

Reviewed By: lblasa

Differential Revision: D32829739

fbshipit-source-id: 267f43f8e8f3dea60ee86187f7a7709fea09e5af
2021-12-03 05:31:16 -08:00
Andrey Goncharov
39841292d1 Add legacy connection warning
Summary: Add legacy connection warning

Reviewed By: passy

Differential Revision: D32694056

fbshipit-source-id: e6d1c2fb5aea607d090ab45879c5a46d5fd17dab
2021-11-29 04:29:37 -08:00
Andrey Goncharov
37498ad5a9 Refactor server implementation for WebSockets
Summary:
Standardize WS implementation for JS environments.

Why do we need a separate server implementation for browsers?
Browser targets cannot authenticate via the default certificate exchange flow. For browser targets we verify the origin instead.
Moreover, for already forgotten reasons the initial implementation of the WS server for browsers used a different kind of message structure and added extra `connect`/`disconnect` messages. After examination, it seems the `connect`/`disconnect` flow is redundant.

Major changes:
1. Updated class hierarchy for WS server implementations.
2. Updated browser WS server to support the modern and the legacy protocols.
3. Now a websocket connection with the device is closed on error. The idea is it is highly unlikely to handle any subsequent messages properly once we observe an error. It is better to bail and reconnect. What do you think?

Reviewed By: mweststrate

Differential Revision: D31532172

fbshipit-source-id: f86aa63a40efe4d5263353cc124fac8c63b80e45
2021-10-21 03:34:15 -07:00