Inets http2 support

Loïc Hoguin essen@REDACTED
Thu Nov 21 17:50:39 CET 2019

Mind you I also change my mind on the complexity every other week... 
Ultimately it's just something that has to be done so it doesn't really 
matter how big the task is. Gotta get started first. From what I've seen 
of the progress June 2020 or so would be a good time to start as the 
protocol should be close to completion by then.

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.

That's what I want for RabbitMQ and based on experiments emulating some 
aspects of QUIC, this is an insanely promising prospect. I expect QUIC 
to triple the throughput for mirrored RabbitMQ queues *at the very least*.

Some aspects of the distribution do not play well with QUIC though, like 
`monitor(process, {Name, Node})`. This is the one thing in the 
distribution protocol for which you can't guarantee ordering over 
multiple QUIC streams because you don't have the pid that you have for 
all other messages. Right now you also must parse the message in order 
to figure out on which stream you have to send it, it would probably be 
better to have this info readily available. Of course you could always 
use a single QUIC channel but then what's the point. :-)

> We were thinking about re-using the ssl applications TLS 1.3 
> implementation. It is not trivial as transport and TLS are upsidedown 
> for QUIC, but should be doable sais Ingela and Peter :p

If we can have a good interface that has TLS return the 
encrypted/decrypted binary data rather than write it directly to the 
socket, I could also use it in Gun to support TLS connections over TLS 
proxies. Right now it uses the callback module and while it works it's 
fairly complex.

Loïc Hoguin

More information about the erlang-questions mailing list