On Tue, May 21, 2019 at 5:57 PM Mark Thomas <ma...@apache.org> wrote:
> On 21/05/2019 14:57, Rémy Maucherat wrote: > > Hi, > > > > In preparation for HTTPx in the future, I was looking at how to start > > adding UDP, and: > > - NIO2 and APR don't have datagram support, the first one is hopeless > > and the second one is legacy. > > - It would be better to avoid duplicating the whole NIO connector, but > > rather add a datagram mode to it. > > - I think the "best" way is to change NioChannel.sc to be a > > SelectableChannel, and then use casts (to ByteChannel, etc). The class > > hierarchy between SocketChannel and DatagramChannel is otherwise rather > > annoying. > > - Many of the methods are identical between SocketChannel and > > DatagramChannel (socket properties, address access, etc etc), but > > unfortunately they are only on the concrete class. Since I don't think > > reflection should be used, this means some amount of duplication and > > casting. > > - Along the way, I noticed NioChannel.close does sc.socket.close() then > > sc.close(). Normally that's useless. I'm pretty sure this was done to > > workaround old bugs that are most likely fixed now (I found references > > online for Java 4, 5 and 6, but nothing since then). So this could be > > simplified to just close the SelectableChannel. > > > > Any ideas ? > > To be brutally honest I wouldn't do too much work on this at this point. > There are several reasons for this. > > 1. The API in Java for UDP is not a good match to what you'd need to do > for QUIC. > > 2. QUIC requires access to what is currently internal TLS state. It > isn't available in Java. There is a patch to expose this for OpenSSL. If > the UDP parts are implemented in Java there will be a LOT of JNI calls > required which is likely to hamper performance. > Ok, thanks for the info. I was looking at the basics, but that's clearly a showstopper for now. I have to suppose QUIC is our only use case for UDP, so I'll skip the topic for now. > > 3. Just going by the length of the multiple draft RFCs, QUIC looks to be > complex to implement. Roughly, I'd say several times more complex than > HTTP/2. > > My recommendation is to wait and use a QUIC native library in much the > same way as we currently use OpenSSL. A review of the current > implementations and their licensing might be worthwhile. > > An alternative approach would be to lobby for OpenJDK to implement QUIC > (I don't know if that is on the roadmap) and/or start contributing to > that effort. > +1 Rémy
