From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.66.187.209 with SMTP id fu17mr1519973pac.24.1461604296118; Mon, 25 Apr 2016 10:11:36 -0700 (PDT) X-Received: by 10.182.88.129 with SMTP id bg1mr351190obb.3.1461604296066; Mon, 25 Apr 2016 10:11:36 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!peer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!g8no6273557igr.0!news-out.google.com!k10ni288igv.0!nntp.google.com!sq19no531088igc.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Mon, 25 Apr 2016 10:11:35 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=2a02:1205:c68c:9d90:e106:d714:e71e:63b4; posting-account=Pm0FhgoAAAAiPscNT3etSZ15tHNZGXm_ NNTP-Posting-Host: 2a02:1205:c68c:9d90:e106:d714:e71e:63b4 References: <276b8c43-7280-48ad-94be-c8324c6ae326@googlegroups.com> <0ea06785-65e5-4c33-b8b1-1fc6e7e66740@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <9e724e15-9566-4405-89f7-ec5a49406593@googlegroups.com> Subject: Re: Broadcasting UDP From: ahlan.marriott@gmail.com Injection-Date: Mon, 25 Apr 2016 17:11:36 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Received-Bytes: 3610 X-Received-Body-CRC: 4257702025 Xref: news.eternal-september.org comp.lang.ada:30282 Date: 2016-04-25T10:11:35-07:00 List-Id: On Monday, 25 April 2016 16:51:36 UTC+2, Dmitry A. Kazakov wrote: > On 25/04/2016 16:18, ahlan@marriott.org wrote: > > > This of course works but by using Broadcast_Inet_Addr > > (255.255.255.255) then we actually transmit more UDP messages than is > > strictly necessary. > > > > For example if I have two adapters one with 100.13.5.200 and the > > other 169.254.7.7 and I send a UDP broadcast on each adapter then four UDP > > messages are actually transmitted. > > 1) Src=100.13.5.200 Dest=255.255.255.255 on adapter 1 > > 2) Src=100.13.5.200 Dest=255.255.255.255 on adapter 2 > > 3) Src=169.254.7.7 Dest=255.255.255.255 on adapter 1 > > 4) Src=169.254.7.7 Dest=255.255.255.255 on adapter 2 > > > > This is because the destination address 255.255.255.255 is for all adapters. > > But the socket is bound to the address of a concrete adapter. > Send_Socket should not leak through another adapter. It does not look right. > > > If I could find out the subnet masks I could derive the subnet > > directed broadcast addresses and use these as the destination addresses > > and thereby reduce the traffic. > > AFAIK there is no means for that in the Berkeley sockets. > > > Not by much I grant you but every little helps and besides it would > > be a little more elegant than using the crude broadcast to all on all > > adapters approach. > > Broadcasts with alien source address is not a big problem. I hope you > are not doing anything but network discovery over broadcast. > > > Any ideas? > > Maybe, there is something with network settings (bridging etc). > Broadcast packets should not cross segment boundaries. > > -- > Regards, > Dmitry A. Kazakov > http://www.dmitry-kazakov.de Dear Dmitry, We are indeed only doing network discovery so these superfluous broadcasts with alien source addresses shouldn't be a problem - just not very nice ;-) It seems that under Windows-Xp (my test machines) the adapter is selected according to the destination address and adapter subnet mask and not on source address. I'll try it out on a Win10 machine tomorrow to check whether this is a Windows issue or a legacy issue. Either way it isn't terribly important especially if there isn't an easy way to get the adapter subnet masks. I just thought I'd ask the experts before giving up. Many thanks, MfG Ahlan