Joel VanderWerf wrote:
> Ok, a new problem. The following program outputs "received: foo". But if
> I uncomment the s.connect line in the fork code, it hangs in #recv. Why
> should connecting a UDPSocket to _another_ broadcast port interfere with
> receiving? (I see the same behavior with 192.168.1.255 broadcasts after
> turning off my firewall.)
> 
> require 'socket'
> 
> broadcast_addr = '127.255.255.255'
> 
> fork do
>   s = UDPSocket.open
>   s.setsockopt(Socket::SOL_SOCKET, Socket::SO_BROADCAST, true)
>   s.bind(broadcast_addr, 44891)
>   #s.connect(broadcast_addr, 44890)
>   puts "received: #{s.recv(100)}"
> end
> 
> sleep 0.1
> 
> s = UDPSocket.open
> s.setsockopt(Socket::SOL_SOCKET, Socket::SO_BROADCAST, true)
> #s.bind(broadcast_addr, 44890) # this has no effect either way

                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Wrong. Binding this socket lets the packet go through, when the
s.connect line is also enabled, but only if I use a non-broadcast
address, like 127.0.0.1.

I guess #connect just doesn't mix well with broadcast UDP?

Well, fortunately, I don't need to use the combination of (broadcast,
UDP, connect) in my application code. I was just using it in a unit
test, but it's not necessary.

> s.connect(broadcast_addr, 44891)
> s.send "foo", 0
> 
> Process.wait
> 
> 
> 
> 
> 

-- 
      vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407