An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071018/a54f2b61/attachment.html
On 10/19/07, Mark Zvilius <zvilius at earthlink.net> wrote:> > A while back I asked: > > >* 2. One thing I need to do is implement a discovery protocol, involving a > *>* UDP broadcast. I don''t see a way to set SO_BROADCAST on the underlying > *>* socket. Is there any way to do that? > * > Francis replied: > *> For UDP broadcasts, just sent the packet to a target address of > > 255.255.255.255 to get a broadcast on your local lan.* > > > I wrote test code (see below) to try this. > > Using the Ruby UDPSocket class: > > bc_sock ==>"hello sock world" -> 1392 at 255.255.255.255 > sent > ... and the server (running separately) gets it: > > serv ==>udp server @ 1392 > 1628 at 129.196.215.84 -> "hello sock world" > goodbye > > But using EM, it doesn''t get to the server: > > bc_evma ==>"hello evma world" -> 1392 at 255.255.255.255 > sent > serv ==>udp server @ 1392 > > > I assume that the difference is that I set the SO_BROADCAST option in the > Socket-based code. So I reiterate my original question: is there a way to > set the SO_BROADCAST option on the underlying UDP socket resulting from > EM::open_datagram_socket? > >I fixed this by setting SO_BROADCAST on all datagram sockets. Please sync to the EM head revision and try your code again. As far as I can tell, the reason that SO_BROADCAST is required on some platforms is to keep users from inadvertently sending a broadcast packet by erroneously entering an IP address that happens to be a broadcast address on that particular subnet. Rather than requiring an additional call to specifically enable broadcasting from a particular socket, I decided to just do it automatically. (Solaris does this, too.) If someone ever comes up with a good reason not to do this, then we''ll have to add in an API to specifically set the broadcast option. And of course any code that depends on having it set automatically will break at that point. So how about it, network gurus? Is it a bad idea to automatically allow broadcasting on UDP sockets? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071019/3dc45934/attachment.html
I think you hit the nail on the head: for an app that sends to an externally provided (e.g. user-supplied) IP address, SO_BROADCAST(off) saves some tedious code to prevent broadcasts. That?s a pretty small set of apps, however, so I think it?s quite sensible for the option to default ?on? rather than ?off.? If at some later point you provide an API to modify the option, it wouldn?t have to break existing apps .. just keep the default ?on.? EM has a different, presumably more generally useful, set of default socket options than most socket libraries ? as another example, I think I remember you saying that you turn off Nagle ? but ultimately I think EM does need to provide some kind of access to the lower-level socket options (not just SO_BROADCAST) if you want to support higher-performing apps that need to modify the defaults. Mark Z. On 10/19/07 2:27 AM, "Francis Cianfrocca" <garbagecat10 at gmail.com> wrote:> As far as I can tell, the reason that SO_BROADCAST is required on some > platforms is to keep users from inadvertently sending a broadcast packet by > erroneously entering an IP address that happens to be a broadcast address on > that particular subnet. Rather than requiring an additional call to > specifically enable broadcasting from a particular socket, I decided to just > do it automatically. (Solaris does this, too.) > > If someone ever comes up with a good reason not to do this, then we''ll have to > add in an API to specifically set the broadcast option. And of course any code > that depends on having it set automatically will break at that point. > > So how about it, network gurus? Is it a bad idea to automatically allow > broadcasting on UDP sockets?-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071019/a215a5e0/attachment.html
On 10/19/07, Mark Zvilius <zvilius at earthlink.net> wrote:> > I think you hit the nail on the head: for an app that sends to an > externally provided (e.g. user-supplied) IP address, SO_BROADCAST(off) > saves some tedious code to prevent broadcasts. > > That''s a pretty small set of apps, however, so I think it''s quite sensible > for the option to default "on" rather than "off." If at some later point you > provide an API to modify the option, it wouldn''t have to break existing apps > .. just keep the default "on." > > EM has a different, presumably more generally useful, set of default > socket options than most socket libraries ? as another example, I think I > remember you saying that you turn off Nagle ? but ultimately I think EM does > need to provide some kind of access to the lower-level socket options (not > just SO_BROADCAST) if you want to support higher-performing apps that need > to modify the defaults. >Ok, that''s a good thought, as of today the official behavior of EM UDP sockets is that they allow broadcasting, and we''ll someday provide an api to turn it OFF if necessary. I''ll modify the documentation accordingly when I get around to it. I''m open to your thought about eventually providing lower level socket access for people who really know what they''re doing. Modifying the kernel buffer sizes is an example. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071019/4c98ab92/attachment.html