Am 19.12.2013 um 16:14 schrieb Stephan Eggermont <[email protected]>:
> Norbert wrote: > >To send or receive a broadcast packet you need to put special options on the > >socket on the native side (setsockopt). You need to >look if the > >SO_BROADCAST option is mentioned anywhere. If not it won’t work without > >adding them. And for sending them you >need almost special privileges on the > >system. This is not a „user feature“. > > And even though it is "the right thing" for lots of situations, your network > is also very likely to not do the right thing > with broadcast packets. Etsy decided on using bittorrent protocol to update > their production servers indexes, because they > found it too difficult to get their network to do the right thing. They found > that their switches were basically livelocked > while dealing with broadcast packets. > > http://codeascraft.com/2012/01/23/solr-bittorrent-index-replication/ > > If you want the broadcast to travel a little further, the routers need to be > configured not to drop the packets. > > Stephan I don’t think broadcast is „the right thing“ in most use cases. It is just a lot less cumbersome to use instead of multicast which is supposed to be the right thing for a broader use. So you can overuse broadcast very easy. In an environment with a lot of cascaded switches broadcast is something that makes the whole thing inoperable. A switch tries to use the smallest number of physical ports to route packets. It decides that based on internal tables recorded from MAC addresses and such. Broadcast is a brute force attempt where every address bit is set to reach every participant in the local hardware segment. So you might see that a switch has basically no other option then to open all ports to send a broadcast packet. So having a prevent-broadcast-packets option is a last ressort option. Norbert
