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.
