Skip to content

Conversation

@zh4ngx
Copy link
Contributor

@zh4ngx zh4ngx commented Nov 4, 2025

Implement stream-quic-{client, server} based on streams-nats-{client, server} and hello-quic-{client, server}.

Should the handling of multiple invocation streams follow the approach in hello-quic-server or stream-nats-server?

@rvolosatovs

@zh4ngx zh4ngx requested a review from rvolosatovs as a code owner November 4, 2025 23:47
@zh4ngx zh4ngx force-pushed the streams-quic-example branch from b07a41d to 2535e9a Compare November 4, 2025 23:54
@rvolosatovs
Copy link
Member

Should the handling of multiple invocation streams follow the approach in hello-quic-server or stream-nats-server?

they seem to be identical other that the QUIC version having to abort accepts on shutdown, could you elaborate?

@rvolosatovs rvolosatovs enabled auto-merge November 5, 2025 16:15
@rvolosatovs rvolosatovs disabled auto-merge November 5, 2025 16:16
Co-authored-by: Roman Volosatovs <rvolosatovs@users.noreply.github.com>
@zh4ngx
Copy link
Contributor Author

zh4ngx commented Nov 5, 2025

Should the handling of multiple invocation streams follow the approach in hello-quic-server or stream-nats-server?

they seem to be identical other that the QUIC version having to abort accepts on shutdown, could you elaborate?

Sure, I think it might be around more general questions:

  • What is the role of the task collection here, and why does it not appear in the nats example?
  • Why is there no srv.accept(...) step in stream-nats-server like there is in hello-quic-server?
  • How does bindings::serve(...) work? In hello-quic-server it takes a wrpc_transport_quic::Server, but in stream-nats-server it takes in a wrpc_transport_nats::Client.

Thanks!

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.

2 participants