Re: suggestions for improvement in java.net APIs
On 05/05/2013 12:19, Dmitry Samersoff wrote: 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. The use-case is where an application wants to control the network or source address. -Alan.
Re: suggestions for improvement in java.net APIs
Alan, Not sure what is real usecase for this requirements for ipv4. For ipv6 it should be done by sendmsg() and msg_control. -Dmitry On 2013-05-06 11:28, Alan Bateman wrote: On 05/05/2013 12:19, Dmitry Samersoff wrote: 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. The use-case is where an application wants to control the network or source address. -Alan. -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer
Re: suggestions for improvement in java.net APIs
SO_BINDTODEVICE can be used in cases where an IP network application doesn't want the existing routing table entries to determine the interface that packets are transmitted from. This is often the case when one is writing a router that needs to do neighbor discovery. I used this extensively a few years back to create a link aggregator that dynamically and adaptively distributed traffic to a particular destination across multiple interfaces. (They were PPP interfaces that were created by unreliable unpredictable CDMA data cards, and we had to do the best with what mother nature gave us for sending high-bandwidth video. Even one good card couldn't support the video stream and the product looked like a porcupine studded with data cards.) An other reason for binding a socket to a device, is when Ethernet is used as a control plane inside a product. Packets intended to go between cards within a chassis cannot be allowed to leave the chassis, ever. You don't want bugs or misconfiguration to result in leaking control traffic. People who build network appliances use SO_BINDTODEVICE. And I can also imagine android developers wanting it for applications that want to use multiple interfaces intelligently (maybe to divert traffic from cellular data to WiFi when WiFi is available to save money and get better performance. You could write an App that will ONLY use the WiFi interface, regardless of what the routing table says.) I've used SO_BINDTODEVICE for years and when I started using Java last year, I was stunned that it wasn't available. I guess the question is whether or not there is a reason to support network appliance developers. - Original Message - From: dmitry.samers...@oracle.com To: alan.bate...@oracle.com Cc: mk...@cs.hut.fi, net-dev@openjdk.java.net Sent: Monday, May 6, 2013 5:50:06 PM GMT -05:00 US/Canada Eastern Subject: Re: suggestions for improvement in java.net APIs Alan, Not sure what is real usecase for this requirements for ipv4. For ipv6 it should be done by sendmsg() and msg_control. -Dmitry On 2013-05-06 11:28, Alan Bateman wrote: On 05/05/2013 12:19, Dmitry Samersoff wrote: 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. The use-case is where an application wants to control the network or source address. -Alan. -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer
Re: suggestions for improvement in java.net APIs
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
Re: suggestions for improvement in java.net APIs
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.
