Messages in this thread |  | | From | Philippe Troin <> | Date | 03 Nov 2000 12:19:53 -0800 |
| |
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/
|  |