suggestions for improvement in java.net APIs

[Alan Bateman]

On 04/05/2013 13:22, Miika Komu wrote:
> :
>
> Multihoming bug
> ---------------
> * R3.2: Server-side multihoming for UDP does not work properly. The
> framework should use SO_BINDTODEVICE option or sendmsg()/recvmsg()
> interfaces in a proper way.
Thanks for sending the link to the survey.

On SO_BINDTODEVICE, then I think the last time that this came up (a few 
years ago) that the issue was that it wasn't supported by many operating 
systems and on Linux I thought it required privileges/root.

On sendmsg/recvmsg then there was an effort at one point to add support 
for looking at the destination address, I don't recall if setting the 
source address when sending was considered at the time.

If you are interested in working on adding this support then it would be 
good to propose a patch. The main challenges be implementing it on all 
platforms or specifying in such a way it allows for some 
implementation-specific behavior/support.

>
> Suggested improvements (for better end-user or developer experience)
> --------------------------------------------------------------------
> * R2.2: The framework does not support parallel DNS look ups over IPv4
> and IPv6 to optimize latency

InetAddress will normally delegate to the platform's resolver so it 
might be parallel (newer versions of glibc? Also I think MacOSX has been 
doing this for some time).

InetAddress can also be configured to use a pure-DNS or other provider 
so that the look ups can be controlled. I'm not aware of anyone looking 
into doing parallel look-ups over IPv4 and IPv6 but it would be an 
interesting patch for someone to work on if they are interested.

> * R3.3: The framework does not support parallel connect() over IPv4 and
> IPv6 to minimize the latency for connection set-up
>
>
While there isn't API support, it is something that can be done at the 
application level. So if InetAddress.getAllByName return several 
addresses then it is possible to initiate connections to several 
addresses using a thread pool. Another approach might be to use several 
SocketChannel configured non-blocking plus a Selector. This may not be 
what you are thinking of course.

-Alan.