4212324: Packets sent to broadcast address not received on servers bound to specific addr

[Michael McMahon]

Alan, Damjan,

The following new API was approved by the CCC to deal with this
request.

Add new methods to java.net.DatagramPacket
 
    /**
     * Returns the destination IP address that the packet
     * was sent to, assuming this contains a received datagram, and
     * that the underlying implementation is able to provide the 
information.
     * Returns <code>null</code> otherwise.
     *
     * @return  the destination IP address of this datagram.
     */
    public InetAddress getDestinationAddress()
 
    /**
     * Returns the {@link NetworkInterace} that the packet was received
     * through, assuming this contains a received datagram, and
     * that the underlying implementation is able to provide the 
information.
     * Returns <code>null</code> otherwise.
     *
     * @return  the NetworkInterface that received the datagram
     */
 
    public NetworkInterface getReceivedInterface ()
 
An implementation was done, but was not completed. If anyone would
like to take the code, and finish it off, please let me know.

Thanks
Michael.

Alan Bateman wrote:
> Damjan Jovanovic wrote:
>> Hi
>>
>> Is this the right place to discuss/post patches for Java 1.7? If not,
>> what is? Sun's websites are so confusing...
>>   
> Yes, this is right place.
>
>> Has there been any work on the bug I referred to in the subject? If
>> not, read on.
>>   
> Michael McMahon is probably the best person to reply to you on this. 
> Last year he had a proposal and implementation that updated 
> DatagramPacket with methods to obtain the datagram destination address 
> and the network interface that it was received on. I believe he parked 
> it temporarily to work on some higher priority tasks with a view to 
> coming back to it later. [ Michael - can you give an updated status on 
> this? ]
>
>
>> :
>>
>> Also java.nio.channels.DatagramChannel seems very limited compared to
>> java.net.DatagramSocket, is it worth patching?
>>   
> DatagramChannel is more suited to applications where the socket is 
> connected or where non-blocking is required. Aside a DHCP server, I 
> haven't come across many applications needing access to the ancillary 
> data. If required then it would be possible to have DatagramChannel 
> define a new receive method that returns this information but it may 
> not be worth it.
>
>> >From what I've observed in Java 1.6 on Linux,
>> java.net.NetworkInterface.getNetworkInterfaces() doesn't list
>> interfaces without an IP address, even if they are up. The
>> documentation says it will list all interfaces, so is this a bug?
>>   
> The specification should probably be clarified here as that assertion 
> may be too strong or ambiguous. On Linux, the interfaces are 
> enumerated using the SIOCGIFCONF ioctl which, if I recall, is tied to 
> the socket protocol and so only returns address with IPv4 addresses 
> (to check this I would suggest stepping through in the debugger to see 
> the names and index of the interfaces that are returned). When this 
> was implemented back in 1.4 I recall the equivalent ioctl to get 
> interfaces with IPv6 addresses wasn't implemented on Linux so we had 
> to pull this from /proc.
>
> -Alan.
>