Re: 255.255.255.255 won't broadcast to multiple NICs

[Philippe Troin <phil@fifi.org>]

Rob Landley <telomerase@yahoo.com> writes:
> --- Philippe Troin <phil@fifi.org> wrote:
> > All the code I've encountered which actually needed
> > to perform
> > broadcast on all interfaces was sending
> > subnet-directed broadcasts by
> > hand on all interfaces.
> 
> Bind to a socket to a local port and query that
> address you say?  Nope, too easy.  The address
> returned when I query a socket (rather than a
> connection) is 0.0.0.0 on any machine with multiple
> interfaces (even loopback), since the socket is bound
> to that port on ALL the interfaces.  Each incoming or
> outgoing connection does have a valid "from" IP
> address, but I have to wait for a connection to come
> in to get that.  (Unless I explicitly specify which IP
> to bind to when I create the socket, but if I knew
> that I'd already be there.)
> 
> Nope, making my own connection to a port on the same
> machine just means 127.0.0.1 is talking to 127.0.0.1. 
> Tried it.  Didn't work.
> 
> Nope, feeding the loopback address to getAllByName()
> doesn't help either.  I tried that too, it just
> returns a length 1 array containing just the loopback
> address.

The source IP address (as returned by getsockname()) is only set when
the socket is connected... It follows the same logic: for a multihomed
machine, we know which interface will be used only when we know who
we'll be talking to...

> Now you know why I'm resorting to 255.255.255.255. 
> I'm sort of faking things: when the server broadcasts
> to clients they know who it is, and when they
> broadcast to it, it knows who THEY are (it says in the
> UDP datagram header info).  And the way I've written
> it, that's all they really need to know (although when
> we reply to each other we can each find out the info
> we don't know: who WE are.  But by that point, we no
> longer need it. :)
> 
> I may just document "if you run this on a machine with
> more than one network card, you have to specify the
> broadcast addresses on the command line".  It's
> configuration, but the only machine likely to HAVE
> multiple interfaces is the server (which could be
> serving multiple subnets in a really BIG render farm),
> so I suppose it's tolerable...

You could use SIOGIFCONF (from C) to get the address list. I'm not
sure is java has the equivalent... Or maybe a very small native
method...

> > Broadcast is ugly anyways, why don't you use
> > multicast ?
> 
> I'm only passingly familiar with it, does it map well
> to this problem?
> 
> The only data I'm trying to transmit is "where is
> everybody", or "wake up".  The broadcast packets are
> only needed for clients to find the server on bootup
> (and vice versa if the server is rebooted).  They're
> also used to wake up clients if they go to sleep
> because the server has nothing for them to do at the
> moment, but that second part's a convenience, really. 
> The server could loop through and address them
> individually instead since it knows where they are by
> that point.
> 
> The actual heavy lifting of data is done by TCP/IP
> streams.  UDP broadcast is just for figuring out where
> to open the TCP/IP connections to.

Sounds like a good job for multicast... It's fairly simple to use,
but:

  1) I'm not sure if java gives you access to the required ioctls
     (there's only five of them).

  2) You may need to run mrouted on all your gateways.

Phil.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/