> On 21 Oct 2014, at 17:53, Annick Fron <l...@afceurope.com> wrote: > > > I think the following code does polling : >>> [ result := socket receiveUDPDataInto: buffer. >>> result first > 0 ] whileFalse: [ (Delay forMilliseconds: 10) wait ]. > > and it is preferable to use semaphores, which are more efficient. > Is it possible to replace it by : > > socket waitForData. > result :- socket receiveUDPDataInto: buffer ??? > > Annick
Good idea, I somehow always thought that #waitForData was only for TCP, but apparently it is not. https://pharo.fogbugz.com/f/cases/14276/Add-UDPSocketEchoTest-test-example == Name: SLICE-Issue-14276-Add-UDPSocketEchoTest-testexample-SvenVanCaekenberghe.2 Author: SvenVanCaekenberghe Time: 21 October 2014, 8:58:15.37026 pm UUID: 5c97ef33-ccff-4cab-9981-d4284d60e162 Ancestors: SLICE-Issue-14276-Add-UDPSocketEchoTest-testexample-SvenVanCaekenberghe.1 Dependencies: NetworkTests-SvenVanCaekenberghe.100 Use #waitForData instead of a busy wait loop (thx Annick From) === > PS : I have successfully used broadcast UDP on Raspberry Feel free to share whatever you learned. > Le 21 oct. 2014 à 16:08, Henrik Johansen <henrik.s.johan...@veloxit.no> a > écrit : > >> >>> On 21 Oct 2014, at 3:52 , Luc Fabresse <luc.fabre...@gmail.com> wrote: >>> >>> >>> >>> 2014-10-21 15:40 GMT+02:00 Sven Van Caekenberghe <s...@stfx.eu>: >>> >>> > On 21 Oct 2014, at 15:29, Luc Fabresse <luc.fabre...@gmail.com> wrote: >>> > >>> > >>> > yes examples are good. >>> > but I also suggest to use a stream on a UDPSocket instead of manipulating >>> > the socket directly in the model code. >>> > Usually, it lowers the code complexity. >>> >>> Hmm, are you sure that is even possible with UDP sockets ? >>> >>> I was thinking of using a stream on the data part of the datagram packets. >>> If you have structured data it simpler to use #next or #nextImage, ... >>> >>> And if the data part is bigger than one datagram packet (65535 IIRC), you >>> can append to the stream as soon as you receive the next packet. >>> >>> Does it sounds good? >>> >>> Cheers, >>> >>> Luc >> >> UDP delivery isn't ordered, nor reliable. >> Build those into a Stream wrapper in order to reliably reconstruct a data >> stream from the sender, and you're almost back to TCP... >> >> Cheers, >> Henry >
