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.
