Inets http2 support

[Adam Lindberg]

@Eric: It can have upsides for Erlang distribution as well (security considerations aside). For example, quick reconnection in case of net splits and changing network environments (e.g. cloud servers getting new IPs because of some network issue). Perhaps even the possibility to mask some network issues that would tear down a TCP connection. Or just roaming Erlang nodes on mobile devices :-D

@Lukas, @Loïc: Working on QUIC separately would still be beneficial though, right? Or is there something in HTTP/3 that requires tighter integration with QUIC that a separate implementation would not provide?

Cheers,
Adam

> On 23. Nov 2019, at 13:38, Eric Pailleau <eric.pailleau@REDACTED> wrote:
> 
> QUIC :
> "To solve this problem, QUIC includes a connection identifier which uniquely identifies the connection to the server regardless of source. This allows the connection to be re-established simply by sending a packet, which always contains this ID, as the original connection ID will still be valid even if the user's IP address changes."
> 
> Wow... Nice security issues in perspective!
> 
> 
> Envoyé depuis mon mobile
> 
> 
> ---- Loïc Hoguin a écrit ----
> 
> On 22/11/2019 21:03, Dave Cottlehuber wrote:
> 
> >> On 21/11/2019 17:22, Lukas Larsson wrote:
> 
> >>> One of the use-cases (besides the obvious HTTP/3 use-case) that we have
> 
> >>> been thinking about would be to allow the Erlang distribution to run
> 
> >>> over QUIC.
> 
> > 
> 
> > Had you considered something like nng instead of HTTP/3 for this?
> 
> 
> 
> You mean QUIC, no need for HTTP/3 for the distribution.
> 
> 
> 
> > - already available[1]
> 
> > - much much simpler than HTTP/3/QUIC (I would hate to count the lines of code)
> 
> > - the survey pattern[2] looks ideal for maintaining heartbeats
> 
> > 
> 
> > I've fiddled with enm[3] https://github.com/basho/enm which is wire compatible,
> 
> > and it's very fast indeed.
> 
> > 
> 
> > [1]: https://github.com/nanomsg/nng
> 
> > [2]: https://nanomsg.org/gettingstarted/nng/survey.html
> 
> > [3]: https://github.com/basho/enm
> 
> 
> 
> From what I understand it's still built on top of TCP. The main 
> 
> advantage of QUIC is that you can map messages onto different streams. 
> 
> Each stream's messages are ordered but the whole connection is not. 
> 
> Streams don't block each other. Different streams may have different 
> 
> priorities (we could have a process_flag that indicates this for very 
> 
> important processes and the distribution driver would send their 
> 
> messages before others).
> 
> 
> 
> Cheers,
> 
> 
> 
> -- 
> 
> Loïc Hoguin
> 
> https://ninenines.eu
>