Rob Landley <[EMAIL PROTECTED]> writes:
> --- Philippe Troin <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
