DatagramChannel performance issue

[Alan Bateman]

On 27/08/2018 14:47, Martin Thompson wrote:
> :
>
> With the following signature we could implement better services.
>
>      /**
>       * Receive a datagram payload with associated source address and port.
>       *
>       * @param source  bytes representing source address and port.
>       * @param payload bytes for the datagram.
>       * @return true if a datagram has been received in non-blocking mode.
>       */
>      boolean receive(ByteBuffer source, ByteBuffer payload);
>
> The source buffer could then be wrapped with a flyweight to extract
> the source address and port to decide if a InetAddress and
> InetSocketAddress need to be created, or extra methods applied to
> InetAddress. For example:
>
>      boolean matches(ByteBuffer source)
>
>      InetAddress getByAddress(ByteBuffer source)
>
> Port can be stored directly after the address in the source buffer.
>
> This implementation could be utilised internally by the existing
> receive implementation to make it more efficient and offered as a new
> API so that UDP based services can be developed which are competitive
> on performance with native implementations plus avoid unnecessary
> allocation and JNI up calls.
>
The SocketAddress type would also need to be encoded into the source 
buffer if there were to an API like this. I think it would be better to 
start out by improving the implementation of the existing receive method 
to eliminate the need to construct objects or set fields in the JNI 
code. Is this something that you would like to contribute?

-Alan