You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Rémy Maucherat <re...@apache.org> on 2019/05/21 13:57:21 UTC
NIO changes
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 ?
Rémy
Re: NIO changes
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Rémy,
On 5/21/19 09: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.
Can you avoid large numbers of casts by using a wrapper
interface/class and thin subclasses for dispatch?
> - 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.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlzkE+0ACgkQHPApP6U8
pFiKFA/9ENX8vNeYGoRubX+3YWmwQYXE23kRVMsBQtp8dtdpPGveVd/6Z0P6rFrn
INg4vOIU9SAez4BvxWcRycjlk3FNubi/G8Dt9K8ceJw+HUknCkZ/c60P8JxAw0A9
IrDdARX6W8f+p0chAp91ta89rUHpu50ty4IsjH5xKcko5/sfshEJIZ3ZGBy1vquQ
XVBUYk/SiLZVAKtmlLYNpzrVp/dW8fsrwS6c51P/9DdMWMfhzRYziZxs3lj8b3n9
LygR2K0Jao3msSebml2WgMfLsbWA8xoUzRLjjBFIWIu1eKP2+S7m9am45jrpZQrI
2bgIncTW3ODfyTSVHZ2/JrLlHimyWWuzmgMMBafB+msMQfQQ0LUZh7pPwcz4RduN
Jb+B0rIgoT47PkvI1XG6yjhkT3ayoBnaVtr1cm3hdHGFaPMidxeLPGdxLkrl7K17
V5hi7HC9335BmIfWKM4rioaJzJAxI4oHbJmzd6Q591P6Kslevol/1hI0iO1zfnyE
TBv0JQMFN5ZUguhfpdA3++SmflWxce9KwJlnmXvb7x5EyuTEX28zCtBWyeL7+8Z4
nDFqzT9mUrtacdOb+oAbuN/livxQoqB7Lz35Gf1+KrefoeaIpws7kSU7c4uoyRpC
3Cx95Q660iGpnbjpJA3NXItYCNySGhUu9PVe3jBiz2CzTR4DDtY=
=+HIq
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: NIO changes
Posted by Rémy Maucherat <re...@apache.org>.
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
Re: NIO changes
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org