-
Notifications
You must be signed in to change notification settings - Fork 1
feat: websocket crate #28
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
base: main
Are you sure you want to change the base?
Conversation
fb816d2 to
96ae206
Compare
96ae206 to
461187c
Compare
| /// | ||
| /// The only two useful implementations for consumers are [`BinaryMessage`] | ||
| /// and [`TextMessage`]. | ||
| pub trait MessageCodec { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need both DataCodec and MessageCodec?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not that we need it as a separate trait, but I like having it to simplify consumer implementations, and for composability in general.
There's only two MessageCodec implementations that would ever be used in practice - BinaryMessage and TextMessage.
| /// Set the [`Adapter`] for the WebSocket. | ||
| pub fn adapter<T>(self, adapter: T) -> Builder<T, C, O> | ||
| where | ||
| T: Adapter, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
websocket::Adapter doesn't seem to represent what it actually is, as it's implemented for different external websocket implementations.
Transport maybe? or Backend?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't like Transport, as it's too generic, and would prefer to leave it for a trait e.g. trait Transport: Sink<...> + Stream<...> {}. As for Backend vs Adapter I'm not really sure if one is better than the other. But I don't mind renaming it to Backend.
Any other options to consider?
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