problems using magic "<broadcast>" socket address on different platforms

[Irmen de Jong]

Dennis Lee Bieber wrote:
>         I see that your sendto has the options mentioned in the MSDN documents 
> for broadcast... Didn't check the receive side -- setsockopt only says 
> "allow transmission" for SO_BROADCAST; one could interpret that to be 
> not applicable to "reception" (pardon the convoluted sentence).

Hmm, yes. But it doesn't matter; with or without the setsockopt, I can't
bind on "<broadcast>" on windows.

Perhaps the setsockopt is not needed on the server.
But it doesn't make a difference...

>>When running this on Linux, everything works as expected.
>>When running the server code on Windows, Python fails to bind
>>the socket on the magic "<broadcast>" address:
>>socket.error: (10049, "Can't assign requested address")
>>
> 
>         Hmmm, doesn't UDP broadcast imply that it goes out to all addresses on 
> the net -- that would imply that a receiver should just be using its 
> normal IP address, not some special "broadcast" address.

No it doesn't, there is UDP Unicast, where you just send to a single
destination IP/port, and there is UDP broadcast which sends to a
specific port on all hosts on the segment.

>>To get my code to work on windows, I had to use the magic "" address
>>(INADDR_ANY). But I don't think that's right, "<broadcast>" should
>>work, shouldn't it?
>>
> 
>         Not sure -- I'd have to dig my books out of storage (now that I'm 
> re-employed and won't be moving across country I can unpack <G>). My 
> current belief is that the broadcast address is meant to be "output 
> only", and you'd bind to your normal network connection IP.

That would work if you only have *one* IP address.
If your machine has multiple IP addresses, and you bind on
only one, you will not receive packets from the other
network adapters. I can't verify this (I haven't got a machine
with multiple network adapters) but a user of Pyro reported
this problem, back when Pyro was binding on the/a IP address
instead of "<broadcast>". Using "<broadcast>" fixed his problem,
and seems to work nicely under Linux at least.

Interesting enough, I just got an email that the so-called
"framework" build of Python 2.3b on Mac OS X works fine again
with "<broadcast>". I can't explain this-- I thought this issue
was in the underlying BSD socket API, and *not in Python*.
(my C test programs confirmed this)... I'm really confused now.

--Irmen de Jong