Repository navigation
feat: websocket crate - #28
Conversation
fb816d2 to
96ae206
Compare
96ae206 to
461187c
Compare
|
I don't understand why relay needs an abstraction layer for this. Doesn't the relay just use 1 library at a time? |
The point of having this abstraction is not multiple backends supoprt. It's to extract the common logic of serialization, observers, heartbeats and idle timeout. All of these are hard to test and ensure correctness with the current relay websocket handling code. Lately, every minor feature that touches the transport layer in the relay (e.g. binary encoding support, request in query, batch requests etc) is impossible to integrate in a clean and testable way. It's time to refactor the transport layer, and while doing it, extract common logic like heartbeats and properly cover it with tests. |
|
@xDarksome I've updated the PR with what we've discussed. Additionally:
|
Description
Resolves WCN2-110.
Adds
wc_websocketcrate with serialization, heartbeat (keep-alive) support, idle timeout (detect disconnects), and observer support for integrating with metrics etc. Includes adapters forwarp,axumandtungstenite.The
ObserverandDataCodecinterfaces are designed around the primary use case (server side of the Relay) to be able to integrate various inbound, outbound and latency metrics.How Has This Been Tested?
Tests covering serialization, transport disconnect, message codecs, heartbeats and timeouts.
Due Diligence