Sven, I have put a halt in your sync method, but receiveUDPData comes with 64 bytes in your app, whereas you have provisioned 48 bytes. So since you start data at 33, I guess what you receive is the usual datagram IP header on 16 bytes, then the UDP header on 16 bytes. http://fr.wikipedia.org/wiki/Internet_Protocol#mediaviewer/File:Ipv4_header.svg http://fr.wikipedia.org/wiki/User_Datagram_Protocol
If this is correct, I should see the source IP address on 4 bytes starting at byte 9, and the total length should be on 4 bytes starting at byte 5, and not at byte 1. Annick Le 20 oct. 2014 à 17:29, Sven Van Caekenberghe <s...@stfx.eu> a écrit : > Annick, > >> On 20 Oct 2014, at 17:12, Annick Fron <l...@afceurope.com> wrote: >> >> Thank you but your explanation does not explain what is the type (signed >> unsigned) and the size of each header component. >> Thus it is impossible to work with that. > > I think you are making this way more difficult than it is. > > ZTimestampSNTPClient>>#sync contains a simple, runnable example of using > datagrams (with a busy wait blocking the calling thread, which is only good > for something simple, because normally datagrams are asynchronous, but that > is another story). > > What you get back from #receiveUDPDataInto: is an Array with 4 elements: > > - number of bytes received, Integer > - address of sender, ByteArray (use NetNameResolver if necessary) > - port of sender, Integer > - whether more datagrams are available for reading, Boolean > > The data is in the reallocated buffer that you supplied, aStringOrByteArray. > > This is all perfectly useable at the Pharo level. > > The question about signed/unsigned sounds like a C question, for which this > is the wrong list, no ? I am sure it is quite easy to find C code that works > with datagrams on your platform. A byte array is an unsigned char array as > far as I remember ... > > What you put inside the datagram, is up to you and your application. > > HTH, > > Sven > >> Annick >> >> Le 17 oct. 2014 à 19:09, Sven Van Caekenberghe <s...@stfx.eu> a écrit : >> >>> Yes, you have to use the methods in the protocol 'datagrams' of Socket. >>> >>> When you receive a datagram, the IP:PORT of the other party is included, >>> see #receiveUDPDataInto:'c comment. >>> >>> It is all a bit low level, but it works well. >>> >>> On 17 Oct 2014, at 18:15, Annick Fron <l...@afceurope.com> wrote: >>> >>>> Thank you, but I am confused. >>>> I have checked your NTP code, and it uses >>>> sendUDPData and not sendData. Same for receiveUDPData. >>>> Besides how is it possible to know where the message comes from in a >>>> broadcast mode ?? >>>> Annick >>>> Le 17 oct. 2014 à 17:35, Sven Van Caekenberghe <s...@stfx.eu> a écrit : >>>> >>>>> UDP is pretty easy, just send and receive byte arrays basically, mostly >>>>> non-blocking. >>>>> >>>>> http://forum.world.st/UDP-Listener-example-td4362851.html >>>>> http://forum.world.st/SysLogSender-UDP-td4745862.html >>>>> >>>>> The API is all in Socket. >>>>> >>>>> On 17 Oct 2014, at 17:09, Annick Fron <l...@afceurope.com> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I was not able to find a UDP example in pharo. >>>>>> >>>>>> There are only TCP examples. >>>>>> >>>>>> Any pointer ? >>>>>> >>>>>> Annick >>>>>> >>>>> >>>>> >>>> >>> >> >
