suggestions for improvement in java.net APIs

[Dmitry Samersoff]

Alan,

SO_BINDTODEVICE shouldn't be used in modern applications because it
causes more problems than solves.

e.g. prevents application from handling on-fly device changes.

Also it requires root (or be more precise RAW_SOCKET) permission and is
not supported on some embedded platforms.

-Dmitry


On 2013-05-05 13:40, 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.
> 
> 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.


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer