Skip to content

Conversation

@heilhead
Copy link
Collaborator

@heilhead heilhead commented Dec 3, 2025

Description

Resolves WCN2-110.

Adds wc_websocket crate with serialization, heartbeat (keep-alive) support, idle timeout (detect disconnects), and observer support for integrating with metrics etc. Includes adapters for warp, axum and tungstenite.

The Observer and DataCodec interfaces 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

  • Breaking change
  • Requires a documentation update
  • Requires a e2e/integration test update

@heilhead heilhead force-pushed the feat/websocket branch 2 times, most recently from fb816d2 to 96ae206 Compare December 4, 2025 06:38
@heilhead heilhead marked this pull request as ready for review December 5, 2025 10:16
@linear
Copy link

linear bot commented Dec 5, 2025

///
/// The only two useful implementations for consumers are [`BinaryMessage`]
/// and [`TextMessage`].
pub trait MessageCodec {
Copy link
Member

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?

Copy link
Collaborator Author

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,
Copy link
Member

@xDarksome xDarksome Dec 5, 2025

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?

Copy link
Collaborator Author

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants