- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] UDP Broadcast message

by Esteban A. Maringolo

2013/12/19 Sven Van Caekenberghe <sven(a)stfx.eu>: > On 19 Dec 2013, at 17:09, jannik.laval <jannik.laval(a)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

Dec. 19, 2013

files.pharo.org maintenance

by Christophe Demarey

Hello, A maintenance operation will be performed on files.pharo.org to add more storage. It will be performed Monday, December 23rd 2013 between 3:00 pm and 3:30 pm. Zero conf scripts and CI jobs will fail if used at this time. Regards, Christophe.

Dec. 19, 2013

NativeBoost and standard out

by Emilio Oca

Hi Is it possible to get the stdout results when running WinProcess createAndWaitForProcess: aCommand?. If it is not, any alternative? Best Emilio

Dec. 19, 2013

Re: [Pharo-dev] UDP Broadcast message

by Sven Van Caekenberghe

On 19 Dec 2013, at 17:09, jannik.laval <jannik.laval(a)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(a)stfx.eu> wrote: > >> You also have to set a port with #setPort: no ? >> >> On 19 Dec 2013, at 16:39, jannik.laval <jannik.laval(a)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(a)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(a)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

Dec. 19, 2013

Re: [Pharo-dev] UDP Broadcast message

by jannik.laval

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(a)stfx.eu> wrote: > You also have to set a port with #setPort: no ? > > On 19 Dec 2013, at 16:39, jannik.laval <jannik.laval(a)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(a)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(a)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 >>> >> > >

Dec. 19, 2013

Re: [Pharo-dev] UDP Broadcast message

by Norbert Hartl

Am 19.12.2013 um 16:39 schrieb jannik.laval <jannik.laval(a)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(a)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(a)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 >> >

Dec. 19, 2013

Re: [Pharo-dev] UDP Broadcast message

by Sven Van Caekenberghe

You also have to set a port with #setPort: no ? On 19 Dec 2013, at 16:39, jannik.laval <jannik.laval(a)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(a)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(a)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 >> >

Dec. 19, 2013

Re: [Pharo-dev] UDP Broadcast message

by jannik.laval

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(a)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(a)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 >

Dec. 19, 2013

Re: [Pharo-dev] UDP Broadcast message

by Norbert Hartl

Am 19.12.2013 um 16:29 schrieb jannik.laval <jannik.laval(a)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(a)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 >

Dec. 19, 2013

Re: [Pharo-dev] UDP Broadcast message

by Norbert Hartl

Am 19.12.2013 um 16:14 schrieb Stephan Eggermont <stephan(a)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

Dec. 19, 2013