-
-
Notifications
You must be signed in to change notification settings - Fork 383
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
[Feature] Custom Socket Implementations #1432
Comments
Have a look to see if #1364 will cover your use case. |
Ah, actually I think that's perfect! Sorry for the noise. I had missed the Thanks! |
Also keep an eye out for WebTransport coming natively to browsers in the
future. With some effort, it should be usable to communicate directly from
a browser to a native Quinn server.
…On Wed, Oct 26, 2022, 4:53 AM Zicklag ***@***.***> wrote:
Closed #1432 <#1432> as completed.
—
Reply to this email directly, view it on GitHub
<#1432 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAZQ3XQHIQYKI5RK27S2UDWFELU5ANCNFSM6AAAAAARO43N7Q>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
ghost
mentioned this issue
Aug 2, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Do you think that custom socket implementations would be something you would be open to in the
quinn
crate?Right now you must have an
std::net::UdpSocket
to create an endpoint, but I was thinking about trying to run in the browser using WebRTC for the unreliable transport.Do you think this something we'd like to support, or would it be better to create a custom Web-specific API built on
quinn-proto
?I'd have to look into it more, but I think that the existing
quinn
API would work fine if we created some kind of a transport abstraction. The executor shouldn't be a problem, because we can still spawn async tasks in WASM.The text was updated successfully, but these errors were encountered: