How difficult is it to integrate QUIC to asio?

[Warchant]

The question may be silly, but how difficult is it to integrate QUIC to asio?

[vinniefalco]

It is no more difficult than integrating it into any other platform-specific or portable sockets. The heavy lifting is in implementing the actual QUIC specification, which is enormous. Please close this issue.

[heretic13]

https://github.com/cbodley/nexus

[goforit22123-netizen]

@vinniefalco OpenSSL supports QUIC now. Is there a plan to add QUIC support to asio?

[vinniefalco]

its not up to me but we are exploring using quiche in beast2

[goforit22123-netizen]

@vinniefalco It would be great if they added QUIC support to Asio and HTTP2/http3 to Beast. Thanks for the library, but Boost is lagging far behind the modern internet.

[vinniefalco]

No one needs QUIC or HTTP3 except big tech companies, and they ain't using Beast. What is your use-case?

[goforit22123-netizen]

@vinniefalco I disagree with you. Suppose I want to implement an HTTP/3 client that needs to access resources provided by a major tech company over HTTP/3. How can this be done without using QUIC and HTTP/3 modules? Or.. If I want write something like sniffer or api testing software? Or... maybe i need some custom and lightweight webserver with http/3 support? All this stuff needs quic & http3.

[vinniefalco]

Every "big tech" endpoint that supports HTTP/3 also supports HTTP/1. Show me the endpoint that you are trying to use which does not allow HTTP/1 over TLS. And if you want to write a sniffer or api tester, or lightweight webserver for http/3 there are already existing libraries.

[goforit22123-netizen]

@vinniefalco

1. Yes, you can use fallback to HTTP/1, but it's not just about receiving data, but also about the advantages of HTTP/3, since data can be loaded faster using this protocol. This may be important for programs like "Download Manager"
2. Yes, there are libraries, but they are not as convenient as asio/beast. In general, almost everything that exists in boost can be replaced with other libraries, but we use boost because it is convenient and reliable.

[vinniefalco]

Are you implementing Download Manager? What is your use-case?

[goforit22123-netizen]

@vinniefalco No, I'm not developing a Download Manager, but I'd love for boost to be a library that could be used with modern protocols. That would be really cool! Moreover, it shouldn't be that difficult. OpenSSL supports QUIC on both the client and server. Boost already uses OpenSSL. As for HTTP/2 and HTTP/3, there are also MIT-licensed libraries for them. Why not add a convenient interface for them to boost/beast?

[vinniefalco]

If its not that difficult, why don't you consider submitting a pull request?

[goforit22123-netizen]

@vinniefalco At least because I'm not familiar with the internals of ASIO. However, you previously said that "The heavy lifting is in implementing the actual QUIC specification, which is enormous." Now this problem is solved, OpenSSL has already implemented QUIC, it's time to add its support to asio, but I'm just drawing your attention to this, it's up to you to decide, of course.

[vinniefalco]

I'm not the maintainer of Asio and this issue is not in the right repository. You should be asking here: chriskohlhoff/asio#1691