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
