suggestions for improvement in java.net APIs

[Miika Komu]

Hi,

On 05/05/2013 12:40 PM, Alan Bateman wrote:
> 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.

I should note that this is actually a bug that we have verified manually:

"We verified the UDP multihoming problem with example software provided 
with the java.net. We managed to repeat the UDP multihoming problem with 
connected sockets. This means that the java.net library shares the
same bug as iperf, nc and nc6 as described earlier."

Maybe it should be added to the bug tracker.

> 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.

I was looking for a completely automated solution, without implementing 
this redundantly (and without repeating the mistakes) in each 
application. As IPv6 is catching up, all of the issues will become more 
interesting because IPv6 provides multiple addresses by default.

(In python Twisted, the mentioned functionality is apparently 
implemented according to the developers)

Personally, I don't have any time to work on these, but I'll let you 
know if I can find a student from our university to drill on these.