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. 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. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
