Re: [Pharo-dev] UDP Broadcast message
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
Ok, here is my situation: - I have a Lego Mindstorm that broadcast a UDP message every 10 seconds. - With Wireshark I can see the UDP message, so no problem with that. - I tried to set the option SO_BROADCAST, it does not work anymore. Any other idea ? Jannik On Dec 19, 2013, at 4:14 PM, Stephan Eggermont <stephan@stack.nl> wrote:
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
Am 19.12.2013 um 16:29 schrieb jannik.laval <jannik.laval@gmail.com>:
Ok, here is my situation:
- I have a Lego Mindstorm that broadcast a UDP message every 10 seconds. - With Wireshark I can see the UDP message, so no problem with that. - I tried to set the option SO_BROADCAST, it does not work anymore.
Any other idea ?
What operating system are you using? Norbert
Jannik
On Dec 19, 2013, at 4:14 PM, Stephan Eggermont <stephan@stack.nl> wrote:
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
And here is my small example code: udpSocket := Socket newUDP. udpSocket setOption: 'SO_BROADCAST' value: true. udpSocket getOption: 'SO_BROADCAST'. udpSocket receiveDataTimeout: 15. Jannik On Dec 19, 2013, at 4:29 PM, jannik.laval <jannik.laval@gmail.com> wrote:
Ok, here is my situation:
- I have a Lego Mindstorm that broadcast a UDP message every 10 seconds. - With Wireshark I can see the UDP message, so no problem with that. - I tried to set the option SO_BROADCAST, it does not work anymore.
Any other idea ?
Jannik
On Dec 19, 2013, at 4:14 PM, Stephan Eggermont <stephan@stack.nl> wrote:
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
You also have to set a port with #setPort: no ? On 19 Dec 2013, at 16:39, jannik.laval <jannik.laval@gmail.com> wrote:
And here is my small example code:
udpSocket := Socket newUDP. udpSocket setOption: 'SO_BROADCAST' value: true. udpSocket getOption: 'SO_BROADCAST'. udpSocket receiveDataTimeout: 15.
Jannik
On Dec 19, 2013, at 4:29 PM, jannik.laval <jannik.laval@gmail.com> wrote:
Ok, here is my situation:
- I have a Lego Mindstorm that broadcast a UDP message every 10 seconds. - With Wireshark I can see the UDP message, so no problem with that. - I tried to set the option SO_BROADCAST, it does not work anymore.
Any other idea ?
Jannik
On Dec 19, 2013, at 4:14 PM, Stephan Eggermont <stephan@stack.nl> wrote:
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
Ohhhhhh yessss ! Thank you, It works fine ! No more need of Wireshark. Thank you again. Jannik On Dec 19, 2013, at 4:40 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
You also have to set a port with #setPort: no ?
On 19 Dec 2013, at 16:39, jannik.laval <jannik.laval@gmail.com> wrote:
And here is my small example code:
udpSocket := Socket newUDP. udpSocket setOption: 'SO_BROADCAST' value: true. udpSocket getOption: 'SO_BROADCAST'. udpSocket receiveDataTimeout: 15.
Jannik
On Dec 19, 2013, at 4:29 PM, jannik.laval <jannik.laval@gmail.com> wrote:
Ok, here is my situation:
- I have a Lego Mindstorm that broadcast a UDP message every 10 seconds. - With Wireshark I can see the UDP message, so no problem with that. - I tried to set the option SO_BROADCAST, it does not work anymore.
Any other idea ?
Jannik
On Dec 19, 2013, at 4:14 PM, Stephan Eggermont <stephan@stack.nl> wrote:
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
On 19 Dec 2013, at 17:09, jannik.laval <jannik.laval@gmail.com> wrote:
Ohhhhhh yessss ! Thank you, It works fine !
No more need of Wireshark.
Great ! When it works (and one way or another is usually does), Pharo is a great/excellent tool for doing all sorts of network, binary and bit hacking. A thousand times more practical and useful than low level languages: you have great interactivity, discoverability and debug capabilities in a super environment where you can really work with objects (and thus bytes, bits and byte arrays). You still have to know what you are doing, of course ;-) Sven
Thank you again. Jannik
On Dec 19, 2013, at 4:40 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
You also have to set a port with #setPort: no ?
On 19 Dec 2013, at 16:39, jannik.laval <jannik.laval@gmail.com> wrote:
And here is my small example code:
udpSocket := Socket newUDP. udpSocket setOption: 'SO_BROADCAST' value: true. udpSocket getOption: 'SO_BROADCAST'. udpSocket receiveDataTimeout: 15.
Jannik
On Dec 19, 2013, at 4:29 PM, jannik.laval <jannik.laval@gmail.com> wrote:
Ok, here is my situation:
- I have a Lego Mindstorm that broadcast a UDP message every 10 seconds. - With Wireshark I can see the UDP message, so no problem with that. - I tried to set the option SO_BROADCAST, it does not work anymore.
Any other idea ?
Jannik
On Dec 19, 2013, at 4:14 PM, Stephan Eggermont <stephan@stack.nl> wrote:
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
-- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org
2013/12/19 Sven Van Caekenberghe <sven@stfx.eu>:
On 19 Dec 2013, at 17:09, jannik.laval <jannik.laval@gmail.com> wrote:
No more need of Wireshark. Great ! When it works (and one way or another is usually does), Pharo is a great/excellent tool for doing all sorts of network, binary and bit hacking. A thousand times more practical and useful than low level languages: you have great interactivity, discoverability and debug capabilities in a super environment where you can really work with objects (and thus bytes, bits and byte arrays).
+1 Years ago I implemented a client (in VB6) for a proprietary binary feed, but because I didn't have the server available, I was able to implement the interface with Smalltalk. Being able to inspect the contents of a socket, and iterate as you like is a true advantage. Regards! Esteban A. Maringolo
Am 19.12.2013 um 16:39 schrieb jannik.laval <jannik.laval@gmail.com>:
And here is my small example code:
udpSocket := Socket newUDP. udpSocket setOption: 'SO_BROADCAST' value: true. udpSocket getOption: 'SO_BROADCAST'. udpSocket receiveDataTimeout: 15.
There are operating system specific problems. You need to check if you need specific priviledges even for receiving packets. On linux systems there was once something about the binding interface you use. You need either specific (IP address) or wildcard (0.0.0.0) to make it operate. But can not recall which it was. Norbert
Jannik
On Dec 19, 2013, at 4:29 PM, jannik.laval <jannik.laval@gmail.com> wrote:
Ok, here is my situation:
- I have a Lego Mindstorm that broadcast a UDP message every 10 seconds. - With Wireshark I can see the UDP message, so no problem with that. - I tried to set the option SO_BROADCAST, it does not work anymore.
Any other idea ?
Jannik
On Dec 19, 2013, at 4:14 PM, Stephan Eggermont <stephan@stack.nl> wrote:
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
Am 19.12.2013 um 16:14 schrieb Stephan Eggermont <stephan@stack.nl>:
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
participants (5)
-
Esteban A. Maringolo -
jannik.laval -
Norbert Hartl -
Stephan Eggermont -
Sven Van Caekenberghe