[Feature] Custom Socket Implementations

[zicklag]

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.

[djc]

Have a look to see if #1364 will cover your use case.

[zicklag]

Ah, actually I think that's perfect! Sorry for the noise.

I had missed the Endpoint::new_with_abstract_socket() method and only noticed the Endpoint::new method which required a UDP socket.

Thanks!

[Ralith]

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: ***@***.***>