Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 3 Nov 2000 15:20:19 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 3 Nov 2000 15:20:09 -0500 Received: from tantale.fifi.org ([216.15.47.52]:5256 "EHLO tantale.fifi.org") by vger.kernel.org with ESMTP id ; Fri, 3 Nov 2000 15:20:00 -0500 To: Rob Landley Cc: Jeff Garzik , linux-kernel@vger.kernel.org Subject: Re: 255.255.255.255 won't broadcast to multiple NICs In-Reply-To: <20001103173316.17356.qmail@web5201.mail.yahoo.com> MIME-Version: 1.0 (generated by SEMI 1.12.1 - "[JR] Nonoichi") Content-Type: text/plain; charset=US-ASCII From: Philippe Troin Date: 03 Nov 2000 12:19:53 -0800 In-Reply-To: <20001103173316.17356.qmail@web5201.mail.yahoo.com> (Rob Landley's message of "Fri, 3 Nov 2000 09:33:16 -0800 (PST)") Message-ID: <87zojgvmdy.fsf@tantale.fifi.org> Lines: 86 User-Agent: Semi-gnus/6.10.12 SEMI/1.12.1 ([JR] Nonoichi) FLIM/1.12.7 (Y?zaki) Emacs/20.7 (i386-debian-linux-gnu) MULE/4.0 (HANANOEN) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Rob Landley writes: > --- Philippe Troin 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/