Issue with UDP Sockets
Locked
12
12
Re: Issue with UDP Sockets
 
|
> On 19 May 2015, at 10:30, Udo Schneider <[hidden email]> wrote: > > Hi Sven, > > you got me :-) > > I had this as a package sometime ago for my own purposes (mDNS). So I knew it does work and how to do it. It's just I can't find that damned package anymore... Did you look in all your package caches ? > > I do think making all this cross platform could be a bit harder, we'll see. > It's not that hard. The socket API is the same on all supported platforms. No surprises on *nix based OS. The only exception is Windows where the API is the same but where you might run into some packet drops due to strange personal FW products and "value-add" NDIS drivers for NICs. The situation has gotten much better though since Windows Vista/7 are using multicast for some of their services out of the box. > > I will recreate it though. Should I simply publish a package or add this as a slice? Thanks a lot, Udo, a good multicast example would be super cool. If it is just a small example, like one class, maybe it could be added to the image, in which case it should indeed be a slice. If it is larger and more application/framework oriented, then maybe a standalone package is more interesting. We try to keep the image as modular as possible. This route would be a bit more work for you, but might make more sense if you also see it possibly growing in the future. > Best Regards, > > Udo > > > On 19/05/15 10:20, Sven Van Caekenberghe wrote: >> Hi Udo, >> >> It would be good if some of this knowledge could be added inside the image, as class comment or methods comments. Even better would be an example combined with a unit test, like UDPSocketEchoTest and TCPSocketEchoTest - the unit test would then actively ensure this functionality is protected. >> >> I do think making all this cross platform could be a bit harder, we'll see. >> >> Sven >> >>> On 19 May 2015, at 00:17, Udo Schneider <[hidden email]> wrote: >>> >>> This should have been 'IP_ADD_MEMBERSHIP' of course: >>> >>> imrMultiaddr := #[239 255 255 250]. >>> imrInterface := #[0 0 0 0]. >>> ipMreq := imrMultiaddr , imrInterface. >>> socket setOption: 'IP_ADD_MEMBERSHIP' value: ipMreq. >>> >>> >>> The "server" could be something like this (execute in first playground). I used another IP address (#[239 255 255 251]) because #[239 255 255 250] might already be part of the multicast group because of other processes and this shows the "whole" process of subscribing to a multicast group: >>> >>> [ >>> | udpSocket | >>> udpSocket := Socket newUDP. >>> udpSocket setPort: 1900. >>> imrMultiaddr := #[239 255 255 251]. >>> imrInterface := #[0 0 0 0]. >>> ipMreq := imrMultiaddr , imrInterface. >>> udpSocket setOption: 'IP_ADD_MEMBERSHIP' value: ipMreq. >>> udpSocket setOption: 'IP_MULTICAST_LOOP' value: 1. >>> "udpSocket setOption: 'SO_REUSEADDR' value: 1." >>> udpSocket waitForData. >>> buffer := ByteArray new: 256. >>> data := udpSocket receiveUDPDataInto: buffer. >>> bytesRead := data at: 1. >>> sender := data at: 2. >>> senderPort := data at: 3. >>> more := data at: 4. >>> result := buffer copyFrom: 1 to: bytesRead. >>> udpSocket closeAndDestroy. >>> result asString inspect. >>> ] fork. >>> >>> >>> >>> The "client" (execute in different playground): >>> | message udpSocket | >>> message := String crlf join: #( >>> 'M-SEARCH * HTTP/1.1' >>> 'HOST:239.255.255.250:1900' >>> 'MAN:"ssdp:discover' >>> 'ST:ssdp:all' >>> 'MX:1' >>> ''). >>> >>> udpSocket := Socket newUDP. >>> udpSocket sendData: message toHost: #[239 255 255 251] port: 1900. >>> (udpSocket waitForSendDoneFor: 5). >>> udpSocket closeAndDestroy. >>> >>> Hope this helps. >>> >>> CU, >>> >>> Udo >>> >>> >>> >>> >>> >>> >>> On 18/05/15 23:29, Udo Schneider wrote: >>>> Hi Manfred, >>>> >>>> I just stumbled over the IP address you are using (239.255.255.250). If >>>> I remember correctly this is a IPv4 Class D Multicast address. >>>> (224.0.0.0-239.255.255.255). >>>> >>>> So if you want to transmit datagrams to this IP address or recieve >>>> datagrams sent to this multicast groups you have to set appropriate IP >>>> Options. >>>> >>>> You can set this options using Socket>>#setOption:value: and read them >>>> using Socket>>#getOption:. Please note that both methods expect the >>>> option to set as a name - not as constant. E.g. >>>> >>>> socket setOption: 'IP_MULTICAST_IF' value: multicastInterface. >>>> >>>> If I do remember correctly you have to set the following options for >>>> sending/receiving: >>>> >>>> Sending: >>>> IP_MULTICAST_IF >>>> (IP_MULTICAST_LOOP) >>>> (IP_MULTICAST_TTL) >>>> >>>> Sending should AFAIK work w/o setting any option - although >>>> IP_MULTICAST_IF is highly recommended. >>>> >>>> Receiving: >>>> (SO_REUSEADDR) >>>> IP_ADD_MEMBERSHIP >>>> (IP_DROP_MEMBERSHIP) >>>> >>>> Receiving only works if you joined the multicast group previously. So I >>>> assume that you need to do something like this (not tested). >>>> >>>> imrMultiaddr := #[239 255 255 250]. >>>> imrInterface := #[0 0 0 0]. >>>> ipMreq := imrMultiaddr , imrInterface. >>>> socket setOption: 'MEMBERSHIP' value: ipMreq. >>>> >>>> Hope this helps. >>>> >>>> CU, >>>> >>>> Udo >>>> >>>> >>>> >>>> On 18/05/15 16:34, Manfred Kröhnert wrote: >>>>> Hi Sven, >>>>> >>>>> On Mon, May 18, 2015 at 4:14 PM, Sven Van Caekenberghe >>>>> <[hidden email] >>>>> <mailto:[hidden email]>> wrote: >>>>> >>>>> >>>>> > On 18 May 2015, at 15:47, Manfred Kröhnert >>>>> <[hidden email] >>>>> <mailto:[hidden email]>> wrote: >>>>> > >>>>> > Hi, >>>>> > apparently I am missing something else. >>>>> > >>>>> > I can find devices when connected to a 'regular' LAN. >>>>> > >>>>> > However, I have a camera that creates a Wifi accesspoint and >>>>> makes itself discoverable via SSDP. >>>>> > Once I connect to this accesspoint my computer gets a valid IP >>>>> address assigned and the NodeJS code is able to discover the device. >>>>> > Unfortunately, the Pharo snippet I posted before does not give me >>>>> any results and hangs in Socket>>waitForDataIfClosed: . >>>>> > >>>>> > Any further ideas? >>>>> >>>>> Are you sure you restarted the image and your code after switching >>>>> networks ? >>>>> >>>>> >>>>> I did not check this before. >>>>> But I just downloaded a fresh 40613 image with PharoLauncher and started >>>>> it after connecting to the camera accesspoint. >>>>> The code snippet freezes there as well. >>>>> >>>>> Manfred >>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > > > |
|
|
> Did you look in all your package caches ?
I did. Must have been a victim of cleaning ... but maybe TimeMachine has something ... thanks for the reminder. > If it is just a small example, like one class, maybe it could be > added to the image, in which case it should indeed be a slice. The package was pretty simple. Basically only adding a few convenience methods around Socket>>#setOption:value: . Still I think a usage example in form of a class comment and test case might be appropriate. So unless Multicast should be part of the base image I'll start with a separate package first. CU, udo On 19/05/15 10:38, Sven Van Caekenberghe wrote: > >> On 19 May 2015, at 10:30, Udo Schneider <[hidden email]> wrote: >> >> Hi Sven, >> >> you got me :-) >> >> I had this as a package sometime ago for my own purposes (mDNS). So I knew it does work and how to do it. It's just I can't find that damned package anymore... > > Did you look in all your package caches ? > >>> I do think making all this cross platform could be a bit harder, we'll see. >> It's not that hard. The socket API is the same on all supported platforms. No surprises on *nix based OS. The only exception is Windows where the API is the same but where you might run into some packet drops due to strange personal FW products and "value-add" NDIS drivers for NICs. The situation has gotten much better though since Windows Vista/7 are using multicast for some of their services out of the box. >> >> I will recreate it though. Should I simply publish a package or add this as a slice? > > Thanks a lot, Udo, a good multicast example would be super cool. > > If it is just a small example, like one class, maybe it could be added to the image, in which case it should indeed be a slice. > > If it is larger and more application/framework oriented, then maybe a standalone package is more interesting. We try to keep the image as modular as possible. This route would be a bit more work for you, but might make more sense if you also see it possibly growing in the future. > >> Best Regards, >> >> Udo >> >> >> On 19/05/15 10:20, Sven Van Caekenberghe wrote: >>> Hi Udo, >>> >>> It would be good if some of this knowledge could be added inside the image, as class comment or methods comments. Even better would be an example combined with a unit test, like UDPSocketEchoTest and TCPSocketEchoTest - the unit test would then actively ensure this functionality is protected. >>> >>> I do think making all this cross platform could be a bit harder, we'll see. >>> >>> Sven >>> >>>> On 19 May 2015, at 00:17, Udo Schneider <[hidden email]> wrote: >>>> >>>> This should have been 'IP_ADD_MEMBERSHIP' of course: >>>> >>>> imrMultiaddr := #[239 255 255 250]. >>>> imrInterface := #[0 0 0 0]. >>>> ipMreq := imrMultiaddr , imrInterface. >>>> socket setOption: 'IP_ADD_MEMBERSHIP' value: ipMreq. >>>> >>>> >>>> The "server" could be something like this (execute in first playground). I used another IP address (#[239 255 255 251]) because #[239 255 255 250] might already be part of the multicast group because of other processes and this shows the "whole" process of subscribing to a multicast group: >>>> >>>> [ >>>> | udpSocket | >>>> udpSocket := Socket newUDP. >>>> udpSocket setPort: 1900. >>>> imrMultiaddr := #[239 255 255 251]. >>>> imrInterface := #[0 0 0 0]. >>>> ipMreq := imrMultiaddr , imrInterface. >>>> udpSocket setOption: 'IP_ADD_MEMBERSHIP' value: ipMreq. >>>> udpSocket setOption: 'IP_MULTICAST_LOOP' value: 1. >>>> "udpSocket setOption: 'SO_REUSEADDR' value: 1." >>>> udpSocket waitForData. >>>> buffer := ByteArray new: 256. >>>> data := udpSocket receiveUDPDataInto: buffer. >>>> bytesRead := data at: 1. >>>> sender := data at: 2. >>>> senderPort := data at: 3. >>>> more := data at: 4. >>>> result := buffer copyFrom: 1 to: bytesRead. >>>> udpSocket closeAndDestroy. >>>> result asString inspect. >>>> ] fork. >>>> >>>> >>>> >>>> The "client" (execute in different playground): >>>> | message udpSocket | >>>> message := String crlf join: #( >>>> 'M-SEARCH * HTTP/1.1' >>>> 'HOST:239.255.255.250:1900' >>>> 'MAN:"ssdp:discover' >>>> 'ST:ssdp:all' >>>> 'MX:1' >>>> ''). >>>> >>>> udpSocket := Socket newUDP. >>>> udpSocket sendData: message toHost: #[239 255 255 251] port: 1900. >>>> (udpSocket waitForSendDoneFor: 5). >>>> udpSocket closeAndDestroy. >>>> >>>> Hope this helps. >>>> >>>> CU, >>>> >>>> Udo >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 18/05/15 23:29, Udo Schneider wrote: >>>>> Hi Manfred, >>>>> >>>>> I just stumbled over the IP address you are using (239.255.255.250). If >>>>> I remember correctly this is a IPv4 Class D Multicast address. >>>>> (224.0.0.0-239.255.255.255). >>>>> >>>>> So if you want to transmit datagrams to this IP address or recieve >>>>> datagrams sent to this multicast groups you have to set appropriate IP >>>>> Options. >>>>> >>>>> You can set this options using Socket>>#setOption:value: and read them >>>>> using Socket>>#getOption:. Please note that both methods expect the >>>>> option to set as a name - not as constant. E.g. >>>>> >>>>> socket setOption: 'IP_MULTICAST_IF' value: multicastInterface. >>>>> >>>>> If I do remember correctly you have to set the following options for >>>>> sending/receiving: >>>>> >>>>> Sending: >>>>> IP_MULTICAST_IF >>>>> (IP_MULTICAST_LOOP) >>>>> (IP_MULTICAST_TTL) >>>>> >>>>> Sending should AFAIK work w/o setting any option - although >>>>> IP_MULTICAST_IF is highly recommended. >>>>> >>>>> Receiving: >>>>> (SO_REUSEADDR) >>>>> IP_ADD_MEMBERSHIP >>>>> (IP_DROP_MEMBERSHIP) >>>>> >>>>> Receiving only works if you joined the multicast group previously. So I >>>>> assume that you need to do something like this (not tested). >>>>> >>>>> imrMultiaddr := #[239 255 255 250]. >>>>> imrInterface := #[0 0 0 0]. >>>>> ipMreq := imrMultiaddr , imrInterface. >>>>> socket setOption: 'MEMBERSHIP' value: ipMreq. >>>>> >>>>> Hope this helps. >>>>> >>>>> CU, >>>>> >>>>> Udo >>>>> >>>>> >>>>> >>>>> On 18/05/15 16:34, Manfred Kröhnert wrote: >>>>>> Hi Sven, >>>>>> >>>>>> On Mon, May 18, 2015 at 4:14 PM, Sven Van Caekenberghe >>>>>> <[hidden email] >>>>>> <mailto:[hidden email]>> wrote: >>>>>> >>>>>> >>>>>> > On 18 May 2015, at 15:47, Manfred Kröhnert >>>>>> <[hidden email] >>>>>> <mailto:[hidden email]>> wrote: >>>>>> > >>>>>> > Hi, >>>>>> > apparently I am missing something else. >>>>>> > >>>>>> > I can find devices when connected to a 'regular' LAN. >>>>>> > >>>>>> > However, I have a camera that creates a Wifi accesspoint and >>>>>> makes itself discoverable via SSDP. >>>>>> > Once I connect to this accesspoint my computer gets a valid IP >>>>>> address assigned and the NodeJS code is able to discover the device. >>>>>> > Unfortunately, the Pharo snippet I posted before does not give me >>>>>> any results and hangs in Socket>>waitForDataIfClosed: . >>>>>> > >>>>>> > Any further ideas? >>>>>> >>>>>> Are you sure you restarted the image and your code after switching >>>>>> networks ? >>>>>> >>>>>> >>>>>> I did not check this before. >>>>>> But I just downloaded a fresh 40613 image with PharoLauncher and started >>>>>> it after connecting to the camera accesspoint. >>>>>> The code snippet freezes there as well. >>>>>> >>>>>> Manfred >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > > > |
Re: Issue with UDP Sockets
|
|
> On 19 May 2015, at 10:53, Udo Schneider <[hidden email]> wrote: > > > Did you look in all your package caches ? > I did. Must have been a victim of cleaning ... but maybe TimeMachine has something ... thanks for the reminder. > > > If it is just a small example, like one class, maybe it could be > > added to the image, in which case it should indeed be a slice. > The package was pretty simple. Basically only adding a few convenience methods around Socket>>#setOption:value: . Still I think a usage example in form of a class comment and test case might be appropriate. So unless Multicast should be part of the base image I'll start with a separate package first. Since Socket is a fundamental part, and multicast is a key feature, I think it would logical to move it to the image itself, with a test case. > CU, > > udo > > > On 19/05/15 10:38, Sven Van Caekenberghe wrote: >> >>> On 19 May 2015, at 10:30, Udo Schneider <[hidden email]> wrote: >>> >>> Hi Sven, >>> >>> you got me :-) >>> >>> I had this as a package sometime ago for my own purposes (mDNS). So I knew it does work and how to do it. It's just I can't find that damned package anymore... >> >> Did you look in all your package caches ? >> >>>> I do think making all this cross platform could be a bit harder, we'll see. >>> It's not that hard. The socket API is the same on all supported platforms. No surprises on *nix based OS. The only exception is Windows where the API is the same but where you might run into some packet drops due to strange personal FW products and "value-add" NDIS drivers for NICs. The situation has gotten much better though since Windows Vista/7 are using multicast for some of their services out of the box. >>> >>> I will recreate it though. Should I simply publish a package or add this as a slice? >> >> Thanks a lot, Udo, a good multicast example would be super cool. >> >> If it is just a small example, like one class, maybe it could be added to the image, in which case it should indeed be a slice. >> >> If it is larger and more application/framework oriented, then maybe a standalone package is more interesting. We try to keep the image as modular as possible. This route would be a bit more work for you, but might make more sense if you also see it possibly growing in the future. >> >>> Best Regards, >>> >>> Udo >>> >>> >>> On 19/05/15 10:20, Sven Van Caekenberghe wrote: >>>> Hi Udo, >>>> >>>> It would be good if some of this knowledge could be added inside the image, as class comment or methods comments. Even better would be an example combined with a unit test, like UDPSocketEchoTest and TCPSocketEchoTest - the unit test would then actively ensure this functionality is protected. >>>> >>>> I do think making all this cross platform could be a bit harder, we'll see. >>>> >>>> Sven >>>> >>>>> On 19 May 2015, at 00:17, Udo Schneider <[hidden email]> wrote: >>>>> >>>>> This should have been 'IP_ADD_MEMBERSHIP' of course: >>>>> >>>>> imrMultiaddr := #[239 255 255 250]. >>>>> imrInterface := #[0 0 0 0]. >>>>> ipMreq := imrMultiaddr , imrInterface. >>>>> socket setOption: 'IP_ADD_MEMBERSHIP' value: ipMreq. >>>>> >>>>> >>>>> The "server" could be something like this (execute in first playground). I used another IP address (#[239 255 255 251]) because #[239 255 255 250] might already be part of the multicast group because of other processes and this shows the "whole" process of subscribing to a multicast group: >>>>> >>>>> [ >>>>> | udpSocket | >>>>> udpSocket := Socket newUDP. >>>>> udpSocket setPort: 1900. >>>>> imrMultiaddr := #[239 255 255 251]. >>>>> imrInterface := #[0 0 0 0]. >>>>> ipMreq := imrMultiaddr , imrInterface. >>>>> udpSocket setOption: 'IP_ADD_MEMBERSHIP' value: ipMreq. >>>>> udpSocket setOption: 'IP_MULTICAST_LOOP' value: 1. >>>>> "udpSocket setOption: 'SO_REUSEADDR' value: 1." >>>>> udpSocket waitForData. >>>>> buffer := ByteArray new: 256. >>>>> data := udpSocket receiveUDPDataInto: buffer. >>>>> bytesRead := data at: 1. >>>>> sender := data at: 2. >>>>> senderPort := data at: 3. >>>>> more := data at: 4. >>>>> result := buffer copyFrom: 1 to: bytesRead. >>>>> udpSocket closeAndDestroy. >>>>> result asString inspect. >>>>> ] fork. >>>>> >>>>> >>>>> >>>>> The "client" (execute in different playground): >>>>> | message udpSocket | >>>>> message := String crlf join: #( >>>>> 'M-SEARCH * HTTP/1.1' >>>>> 'HOST:239.255.255.250:1900' >>>>> 'MAN:"ssdp:discover' >>>>> 'ST:ssdp:all' >>>>> 'MX:1' >>>>> ''). >>>>> >>>>> udpSocket := Socket newUDP. >>>>> udpSocket sendData: message toHost: #[239 255 255 251] port: 1900. >>>>> (udpSocket waitForSendDoneFor: 5). >>>>> udpSocket closeAndDestroy. >>>>> >>>>> Hope this helps. >>>>> >>>>> CU, >>>>> >>>>> Udo >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 18/05/15 23:29, Udo Schneider wrote: >>>>>> Hi Manfred, >>>>>> >>>>>> I just stumbled over the IP address you are using (239.255.255.250). If >>>>>> I remember correctly this is a IPv4 Class D Multicast address. >>>>>> (224.0.0.0-239.255.255.255). >>>>>> >>>>>> So if you want to transmit datagrams to this IP address or recieve >>>>>> datagrams sent to this multicast groups you have to set appropriate IP >>>>>> Options. >>>>>> >>>>>> You can set this options using Socket>>#setOption:value: and read them >>>>>> using Socket>>#getOption:. Please note that both methods expect the >>>>>> option to set as a name - not as constant. E.g. >>>>>> >>>>>> socket setOption: 'IP_MULTICAST_IF' value: multicastInterface. >>>>>> >>>>>> If I do remember correctly you have to set the following options for >>>>>> sending/receiving: >>>>>> >>>>>> Sending: >>>>>> IP_MULTICAST_IF >>>>>> (IP_MULTICAST_LOOP) >>>>>> (IP_MULTICAST_TTL) >>>>>> >>>>>> Sending should AFAIK work w/o setting any option - although >>>>>> IP_MULTICAST_IF is highly recommended. >>>>>> >>>>>> Receiving: >>>>>> (SO_REUSEADDR) >>>>>> IP_ADD_MEMBERSHIP >>>>>> (IP_DROP_MEMBERSHIP) >>>>>> >>>>>> Receiving only works if you joined the multicast group previously. So I >>>>>> assume that you need to do something like this (not tested). >>>>>> >>>>>> imrMultiaddr := #[239 255 255 250]. >>>>>> imrInterface := #[0 0 0 0]. >>>>>> ipMreq := imrMultiaddr , imrInterface. >>>>>> socket setOption: 'MEMBERSHIP' value: ipMreq. >>>>>> >>>>>> Hope this helps. >>>>>> >>>>>> CU, >>>>>> >>>>>> Udo >>>>>> >>>>>> >>>>>> >>>>>> On 18/05/15 16:34, Manfred Kröhnert wrote: >>>>>>> Hi Sven, >>>>>>> >>>>>>> On Mon, May 18, 2015 at 4:14 PM, Sven Van Caekenberghe >>>>>>> <[hidden email] >>>>>>> <mailto:[hidden email]>> wrote: >>>>>>> >>>>>>> >>>>>>> > On 18 May 2015, at 15:47, Manfred Kröhnert >>>>>>> <[hidden email] >>>>>>> <mailto:[hidden email]>> wrote: >>>>>>> > >>>>>>> > Hi, >>>>>>> > apparently I am missing something else. >>>>>>> > >>>>>>> > I can find devices when connected to a 'regular' LAN. >>>>>>> > >>>>>>> > However, I have a camera that creates a Wifi accesspoint and >>>>>>> makes itself discoverable via SSDP. >>>>>>> > Once I connect to this accesspoint my computer gets a valid IP >>>>>>> address assigned and the NodeJS code is able to discover the device. >>>>>>> > Unfortunately, the Pharo snippet I posted before does not give me >>>>>>> any results and hangs in Socket>>waitForDataIfClosed: . >>>>>>> > >>>>>>> > Any further ideas? >>>>>>> >>>>>>> Are you sure you restarted the image and your code after switching >>>>>>> networks ? >>>>>>> >>>>>>> >>>>>>> I did not check this before. >>>>>>> But I just downloaded a fresh 40613 image with PharoLauncher and started >>>>>>> it after connecting to the camera accesspoint. >>>>>>> The code snippet freezes there as well. >>>>>>> >>>>>>> Manfred >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > > > |
|
|
In reply to this post by Udo Schneider
Hi Udo,
is your mDNS code available somewhere? I thought about that some time ago that it could be a nice way to announce a pharo service to the network. Or in my case using it as a foundation for orchestrating images. Norbert > Am 19.05.2015 um 10:30 schrieb Udo Schneider <[hidden email]>: > > Hi Sven, > > you got me :-) > > I had this as a package sometime ago for my own purposes (mDNS). So I knew it does work and how to do it. It's just I can't find that damned package anymore... > > > I do think making all this cross platform could be a bit harder, we'll see. > It's not that hard. The socket API is the same on all supported platforms. No surprises on *nix based OS. The only exception is Windows where the API is the same but where you might run into some packet drops due to strange personal FW products and "value-add" NDIS drivers for NICs. The situation has gotten much better though since Windows Vista/7 are using multicast for some of their services out of the box. > > I will recreate it though. Should I simply publish a package or add this as a slice? > > Best Regards, > > Udo > > > On 19/05/15 10:20, Sven Van Caekenberghe wrote: >> Hi Udo, >> >> It would be good if some of this knowledge could be added inside the image, as class comment or methods comments. Even better would be an example combined with a unit test, like UDPSocketEchoTest and TCPSocketEchoTest - the unit test would then actively ensure this functionality is protected. >> >> I do think making all this cross platform could be a bit harder, we'll see. >> >> Sven >> >>> On 19 May 2015, at 00:17, Udo Schneider <[hidden email]> wrote: >>> >>> This should have been 'IP_ADD_MEMBERSHIP' of course: >>> >>> imrMultiaddr := #[239 255 255 250]. >>> imrInterface := #[0 0 0 0]. >>> ipMreq := imrMultiaddr , imrInterface. >>> socket setOption: 'IP_ADD_MEMBERSHIP' value: ipMreq. >>> >>> >>> The "server" could be something like this (execute in first playground). I used another IP address (#[239 255 255 251]) because #[239 255 255 250] might already be part of the multicast group because of other processes and this shows the "whole" process of subscribing to a multicast group: >>> >>> [ >>> | udpSocket | >>> udpSocket := Socket newUDP. >>> udpSocket setPort: 1900. >>> imrMultiaddr := #[239 255 255 251]. >>> imrInterface := #[0 0 0 0]. >>> ipMreq := imrMultiaddr , imrInterface. >>> udpSocket setOption: 'IP_ADD_MEMBERSHIP' value: ipMreq. >>> udpSocket setOption: 'IP_MULTICAST_LOOP' value: 1. >>> "udpSocket setOption: 'SO_REUSEADDR' value: 1." >>> udpSocket waitForData. >>> buffer := ByteArray new: 256. >>> data := udpSocket receiveUDPDataInto: buffer. >>> bytesRead := data at: 1. >>> sender := data at: 2. >>> senderPort := data at: 3. >>> more := data at: 4. >>> result := buffer copyFrom: 1 to: bytesRead. >>> udpSocket closeAndDestroy. >>> result asString inspect. >>> ] fork. >>> >>> >>> >>> The "client" (execute in different playground): >>> | message udpSocket | >>> message := String crlf join: #( >>> 'M-SEARCH * HTTP/1.1' >>> 'HOST:239.255.255.250:1900' >>> 'MAN:"ssdp:discover' >>> 'ST:ssdp:all' >>> 'MX:1' >>> ''). >>> >>> udpSocket := Socket newUDP. >>> udpSocket sendData: message toHost: #[239 255 255 251] port: 1900. >>> (udpSocket waitForSendDoneFor: 5). >>> udpSocket closeAndDestroy. >>> >>> Hope this helps. >>> >>> CU, >>> >>> Udo >>> >>> >>> >>> >>> >>> >>> On 18/05/15 23:29, Udo Schneider wrote: >>>> Hi Manfred, >>>> >>>> I just stumbled over the IP address you are using (239.255.255.250). If >>>> I remember correctly this is a IPv4 Class D Multicast address. >>>> (224.0.0.0-239.255.255.255). >>>> >>>> So if you want to transmit datagrams to this IP address or recieve >>>> datagrams sent to this multicast groups you have to set appropriate IP >>>> Options. >>>> >>>> You can set this options using Socket>>#setOption:value: and read them >>>> using Socket>>#getOption:. Please note that both methods expect the >>>> option to set as a name - not as constant. E.g. >>>> >>>> socket setOption: 'IP_MULTICAST_IF' value: multicastInterface. >>>> >>>> If I do remember correctly you have to set the following options for >>>> sending/receiving: >>>> >>>> Sending: >>>> IP_MULTICAST_IF >>>> (IP_MULTICAST_LOOP) >>>> (IP_MULTICAST_TTL) >>>> >>>> Sending should AFAIK work w/o setting any option - although >>>> IP_MULTICAST_IF is highly recommended. >>>> >>>> Receiving: >>>> (SO_REUSEADDR) >>>> IP_ADD_MEMBERSHIP >>>> (IP_DROP_MEMBERSHIP) >>>> >>>> Receiving only works if you joined the multicast group previously. So I >>>> assume that you need to do something like this (not tested). >>>> >>>> imrMultiaddr := #[239 255 255 250]. >>>> imrInterface := #[0 0 0 0]. >>>> ipMreq := imrMultiaddr , imrInterface. >>>> socket setOption: 'MEMBERSHIP' value: ipMreq. >>>> >>>> Hope this helps. >>>> >>>> CU, >>>> >>>> Udo >>>> >>>> >>>> >>>> On 18/05/15 16:34, Manfred Kröhnert wrote: >>>>> Hi Sven, >>>>> >>>>> On Mon, May 18, 2015 at 4:14 PM, Sven Van Caekenberghe >>>>> <[hidden email] >>>>> <mailto:[hidden email]>> wrote: >>>>> >>>>> >>>>> > On 18 May 2015, at 15:47, Manfred Kröhnert >>>>> <[hidden email] >>>>> <mailto:[hidden email]>> wrote: >>>>> > >>>>> > Hi, >>>>> > apparently I am missing something else. >>>>> > >>>>> > I can find devices when connected to a 'regular' LAN. >>>>> > >>>>> > However, I have a camera that creates a Wifi accesspoint and >>>>> makes itself discoverable via SSDP. >>>>> > Once I connect to this accesspoint my computer gets a valid IP >>>>> address assigned and the NodeJS code is able to discover the device. >>>>> > Unfortunately, the Pharo snippet I posted before does not give me >>>>> any results and hangs in Socket>>waitForDataIfClosed: . >>>>> > >>>>> > Any further ideas? >>>>> >>>>> Are you sure you restarted the image and your code after switching >>>>> networks ? >>>>> >>>>> >>>>> I did not check this before. >>>>> But I just downloaded a fresh 40613 image with PharoLauncher and started >>>>> it after connecting to the camera accesspoint. >>>>> The code snippet freezes there as well. >>>>> >>>>> Manfred >>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > > > |
|
|
> is your mDNS code available somewhere? I thought about that some time
ago that it could be a nice way to announce a pharo service to the network. Or in my case using it as a foundation for orchestrating images. No it's not in form a ready to go package. I'd have to check whether I saved the Workspace somewhere. Getting the multicast stuff to work was easy. But getting further basically meant implementing a complete name resolver with an understanding of most DNS payloads. Wasn't worth the effort. CU, Udo On 19.05.2015 11:54, Norbert Hartl wrote: > Hi Udo, > > is your mDNS code available somewhere? I thought about that some time ago that it could be a nice way to announce a pharo service to the network. Or in my case using it as a foundation for orchestrating images. > > Norbert > >> Am 19.05.2015 um 10:30 schrieb Udo Schneider <[hidden email]>: >> >> Hi Sven, >> >> you got me :-) >> >> I had this as a package sometime ago for my own purposes (mDNS). So I knew it does work and how to do it. It's just I can't find that damned package anymore... >> >>> I do think making all this cross platform could be a bit harder, we'll see. >> It's not that hard. The socket API is the same on all supported platforms. No surprises on *nix based OS. The only exception is Windows where the API is the same but where you might run into some packet drops due to strange personal FW products and "value-add" NDIS drivers for NICs. The situation has gotten much better though since Windows Vista/7 are using multicast for some of their services out of the box. >> >> I will recreate it though. Should I simply publish a package or add this as a slice? >> >> Best Regards, >> >> Udo >> >> >> On 19/05/15 10:20, Sven Van Caekenberghe wrote: >>> Hi Udo, >>> >>> It would be good if some of this knowledge could be added inside the image, as class comment or methods comments. Even better would be an example combined with a unit test, like UDPSocketEchoTest and TCPSocketEchoTest - the unit test would then actively ensure this functionality is protected. >>> >>> I do think making all this cross platform could be a bit harder, we'll see. >>> >>> Sven >>> >>>> On 19 May 2015, at 00:17, Udo Schneider <[hidden email]> wrote: >>>> >>>> This should have been 'IP_ADD_MEMBERSHIP' of course: >>>> >>>> imrMultiaddr := #[239 255 255 250]. >>>> imrInterface := #[0 0 0 0]. >>>> ipMreq := imrMultiaddr , imrInterface. >>>> socket setOption: 'IP_ADD_MEMBERSHIP' value: ipMreq. >>>> >>>> >>>> The "server" could be something like this (execute in first playground). I used another IP address (#[239 255 255 251]) because #[239 255 255 250] might already be part of the multicast group because of other processes and this shows the "whole" process of subscribing to a multicast group: >>>> >>>> [ >>>> | udpSocket | >>>> udpSocket := Socket newUDP. >>>> udpSocket setPort: 1900. >>>> imrMultiaddr := #[239 255 255 251]. >>>> imrInterface := #[0 0 0 0]. >>>> ipMreq := imrMultiaddr , imrInterface. >>>> udpSocket setOption: 'IP_ADD_MEMBERSHIP' value: ipMreq. >>>> udpSocket setOption: 'IP_MULTICAST_LOOP' value: 1. >>>> "udpSocket setOption: 'SO_REUSEADDR' value: 1." >>>> udpSocket waitForData. >>>> buffer := ByteArray new: 256. >>>> data := udpSocket receiveUDPDataInto: buffer. >>>> bytesRead := data at: 1. >>>> sender := data at: 2. >>>> senderPort := data at: 3. >>>> more := data at: 4. >>>> result := buffer copyFrom: 1 to: bytesRead. >>>> udpSocket closeAndDestroy. >>>> result asString inspect. >>>> ] fork. >>>> >>>> >>>> >>>> The "client" (execute in different playground): >>>> | message udpSocket | >>>> message := String crlf join: #( >>>> 'M-SEARCH * HTTP/1.1' >>>> 'HOST:239.255.255.250:1900' >>>> 'MAN:"ssdp:discover' >>>> 'ST:ssdp:all' >>>> 'MX:1' >>>> ''). >>>> >>>> udpSocket := Socket newUDP. >>>> udpSocket sendData: message toHost: #[239 255 255 251] port: 1900. >>>> (udpSocket waitForSendDoneFor: 5). >>>> udpSocket closeAndDestroy. >>>> >>>> Hope this helps. >>>> >>>> CU, >>>> >>>> Udo >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 18/05/15 23:29, Udo Schneider wrote: >>>>> Hi Manfred, >>>>> >>>>> I just stumbled over the IP address you are using (239.255.255.250). If >>>>> I remember correctly this is a IPv4 Class D Multicast address. >>>>> (224.0.0.0-239.255.255.255). >>>>> >>>>> So if you want to transmit datagrams to this IP address or recieve >>>>> datagrams sent to this multicast groups you have to set appropriate IP >>>>> Options. >>>>> >>>>> You can set this options using Socket>>#setOption:value: and read them >>>>> using Socket>>#getOption:. Please note that both methods expect the >>>>> option to set as a name - not as constant. E.g. >>>>> >>>>> socket setOption: 'IP_MULTICAST_IF' value: multicastInterface. >>>>> >>>>> If I do remember correctly you have to set the following options for >>>>> sending/receiving: >>>>> >>>>> Sending: >>>>> IP_MULTICAST_IF >>>>> (IP_MULTICAST_LOOP) >>>>> (IP_MULTICAST_TTL) >>>>> >>>>> Sending should AFAIK work w/o setting any option - although >>>>> IP_MULTICAST_IF is highly recommended. >>>>> >>>>> Receiving: >>>>> (SO_REUSEADDR) >>>>> IP_ADD_MEMBERSHIP >>>>> (IP_DROP_MEMBERSHIP) >>>>> >>>>> Receiving only works if you joined the multicast group previously. So I >>>>> assume that you need to do something like this (not tested). >>>>> >>>>> imrMultiaddr := #[239 255 255 250]. >>>>> imrInterface := #[0 0 0 0]. >>>>> ipMreq := imrMultiaddr , imrInterface. >>>>> socket setOption: 'MEMBERSHIP' value: ipMreq. >>>>> >>>>> Hope this helps. >>>>> >>>>> CU, >>>>> >>>>> Udo >>>>> >>>>> >>>>> >>>>> On 18/05/15 16:34, Manfred Kröhnert wrote: >>>>>> Hi Sven, >>>>>> >>>>>> On Mon, May 18, 2015 at 4:14 PM, Sven Van Caekenberghe >>>>>> <[hidden email] >>>>>> <mailto:[hidden email]>> wrote: >>>>>> >>>>>> >>>>>> > On 18 May 2015, at 15:47, Manfred Kröhnert >>>>>> <[hidden email] >>>>>> <mailto:[hidden email]>> wrote: >>>>>> > >>>>>> > Hi, >>>>>> > apparently I am missing something else. >>>>>> > >>>>>> > I can find devices when connected to a 'regular' LAN. >>>>>> > >>>>>> > However, I have a camera that creates a Wifi accesspoint and >>>>>> makes itself discoverable via SSDP. >>>>>> > Once I connect to this accesspoint my computer gets a valid IP >>>>>> address assigned and the NodeJS code is able to discover the device. >>>>>> > Unfortunately, the Pharo snippet I posted before does not give me >>>>>> any results and hangs in Socket>>waitForDataIfClosed: . >>>>>> > >>>>>> > Any further ideas? >>>>>> >>>>>> Are you sure you restarted the image and your code after switching >>>>>> networks ? >>>>>> >>>>>> >>>>>> I did not check this before. >>>>>> But I just downloaded a fresh 40613 image with PharoLauncher and started >>>>>> it after connecting to the camera accesspoint. >>>>>> The code snippet freezes there as well. >>>>>> >>>>>> Manfred >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > > > |
Re: Issue with UDP Sockets
|
|
In reply to this post by Sven Van Caekenberghe-2
> On 19 May 2015, at 11:01 , Sven Van Caekenberghe <[hidden email]> wrote: > > >> On 19 May 2015, at 10:53, Udo Schneider <[hidden email]> wrote: >> >>> Did you look in all your package caches ? >> I did. Must have been a victim of cleaning ... but maybe TimeMachine has something ... thanks for the reminder. >> >>> If it is just a small example, like one class, maybe it could be >>> added to the image, in which case it should indeed be a slice. >> The package was pretty simple. Basically only adding a few convenience methods around Socket>>#setOption:value: . Still I think a usage example in form of a class comment and test case might be appropriate. So unless Multicast should be part of the base image I'll start with a separate package first. > > Since Socket is a fundamental part, and multicast is a key feature, I think it would logical to move it to the image itself, with a test case. It's not just multicast... As a Socket newbie I recently spent longer than I care to admit learning you need to set SO_BROADCAST to true to not get a primitive failure when sending to a broadcast address. At least the comments in sqUnixSocket were entertaining! Though I realize which options are actually supported depends on the VM, moving the list of potentially available cross-platform options (and a description of what they're used for) to a comment in the image (setOption: value: being the obvious location) might be a nice first step. Cheers, Henry P.S. On the plus side, I'm now able to turn my PC into a better remote for multi-cam GoPro setups than the GoPro remote itself is :) |
Re: Issue with UDP Sockets
|
|
> On 29 May 2015, at 18:23, Henrik Johansen <[hidden email]> wrote: > >> >> On 19 May 2015, at 11:01 , Sven Van Caekenberghe <[hidden email]> wrote: >> >> >>> On 19 May 2015, at 10:53, Udo Schneider <[hidden email]> wrote: >>> >>>> Did you look in all your package caches ? >>> I did. Must have been a victim of cleaning ... but maybe TimeMachine has something ... thanks for the reminder. >>> >>>> If it is just a small example, like one class, maybe it could be >>>> added to the image, in which case it should indeed be a slice. >>> The package was pretty simple. Basically only adding a few convenience methods around Socket>>#setOption:value: . Still I think a usage example in form of a class comment and test case might be appropriate. So unless Multicast should be part of the base image I'll start with a separate package first. >> >> Since Socket is a fundamental part, and multicast is a key feature, I think it would logical to move it to the image itself, with a test case. > > It's not just multicast... > As a Socket newbie I recently spent longer than I care to admit learning you need to set SO_BROADCAST to true to not get a primitive failure when sending to a broadcast address. > At least the comments in sqUnixSocket were entertaining! > > Though I realize which options are actually supported depends on the VM, moving the list of potentially available cross-platform options (and a description of what they're used for) to a comment in the image (setOption: value: being the obvious location) might be a nice first step. Please help in the documentation effort. > Cheers, > Henry > > P.S. On the plus side, I'm now able to turn my PC into a better remote for multi-cam GoPro setups than the GoPro remote itself is :) I am sure you will blog about this ! |
|
Administrator
|
Yes, pleeeeeeease!!
Cheers,
Sean |
|
|
In reply to this post by Henrik Sperre Johansen
On Sat, May 30, 2015 at 12:23 AM, Henrik Johansen
<[hidden email]> wrote: > P.S. On the plus side, I'm now able to turn my PC into a better remote for multi-cam GoPro setups than the GoPro remote itself is :) That is cool to hear. Now as much as frameworks are important, I think cool little end-user apps like this are important to hook people into Pharo. You really need only *one* feature that people find compelling. Do you need any community support to polish it, then push it on GoPro sites? (not that I have a GoPro, but maybe I'll need to get one) cheers -ben |
Re: Issue with UDP Sockets
|
|
In reply to this post by Sven Van Caekenberghe-2
> On 29 May 2015, at 7:24 , Sven Van Caekenberghe <[hidden email]> wrote: > > >> On 29 May 2015, at 18:23, Henrik Johansen <[hidden email]> wrote: >> >>> >>> On 19 May 2015, at 11:01 , Sven Van Caekenberghe <[hidden email]> wrote: >>> >>> >>>> On 19 May 2015, at 10:53, Udo Schneider <[hidden email]> wrote: >>>> >>>>> Did you look in all your package caches ? >>>> I did. Must have been a victim of cleaning ... but maybe TimeMachine has something ... thanks for the reminder. >>>> >>>>> If it is just a small example, like one class, maybe it could be >>>>> added to the image, in which case it should indeed be a slice. >>>> The package was pretty simple. Basically only adding a few convenience methods around Socket>>#setOption:value: . Still I think a usage example in form of a class comment and test case might be appropriate. So unless Multicast should be part of the base image I'll start with a separate package first. >>> >>> Since Socket is a fundamental part, and multicast is a key feature, I think it would logical to move it to the image itself, with a test case. >> >> It's not just multicast... >> As a Socket newbie I recently spent longer than I care to admit learning you need to set SO_BROADCAST to true to not get a primitive failure when sending to a broadcast address. >> At least the comments in sqUnixSocket were entertaining! >> >> Though I realize which options are actually supported depends on the VM, moving the list of potentially available cross-platform options (and a description of what they're used for) to a comment in the image (setOption: value: being the obvious location) might be a nice first step. > > Please help in the documentation effort. I later found the option names are already documented in getOption:, but since that wasn't of much help (at least to me), I suggest introducing a more specific error than primitiveFailure. Implementing that, the new test revealed a bug; empty UDP payloads will not be sent. A suggested fix for both these issues can be found in SLICE-Issue-15657-Empty-UDP-packets-are-not-sent-HenrikSperreJohansen.1 Cheers, Henry |
|
|
In reply to this post by Sven Van Caekenberghe-2
oh yes!
+ 1000000000 Le 19/5/15 10:20, Sven Van Caekenberghe a écrit : > Hi Udo, > > It would be good if some of this knowledge could be added inside the image, as class comment or methods comments. Even better would be an example combined with a unit test, like UDPSocketEchoTest and TCPSocketEchoTest - the unit test would then actively ensure this functionality is protected. > > I do think making all this cross platform could be a bit harder, we'll see. > > Sven > >> On 19 May 2015, at 00:17, Udo Schneider <[hidden email]> wrote: >> >> This should have been 'IP_ADD_MEMBERSHIP' of course: >> >> imrMultiaddr := #[239 255 255 250]. >> imrInterface := #[0 0 0 0]. >> ipMreq := imrMultiaddr , imrInterface. >> socket setOption: 'IP_ADD_MEMBERSHIP' value: ipMreq. >> >> >> The "server" could be something like this (execute in first playground). I used another IP address (#[239 255 255 251]) because #[239 255 255 250] might already be part of the multicast group because of other processes and this shows the "whole" process of subscribing to a multicast group: >> >> [ >> | udpSocket | >> udpSocket := Socket newUDP. >> udpSocket setPort: 1900. >> imrMultiaddr := #[239 255 255 251]. >> imrInterface := #[0 0 0 0]. >> ipMreq := imrMultiaddr , imrInterface. >> udpSocket setOption: 'IP_ADD_MEMBERSHIP' value: ipMreq. >> udpSocket setOption: 'IP_MULTICAST_LOOP' value: 1. >> "udpSocket setOption: 'SO_REUSEADDR' value: 1." >> udpSocket waitForData. >> buffer := ByteArray new: 256. >> data := udpSocket receiveUDPDataInto: buffer. >> bytesRead := data at: 1. >> sender := data at: 2. >> senderPort := data at: 3. >> more := data at: 4. >> result := buffer copyFrom: 1 to: bytesRead. >> udpSocket closeAndDestroy. >> result asString inspect. >> ] fork. >> >> >> >> The "client" (execute in different playground): >> | message udpSocket | >> message := String crlf join: #( >> 'M-SEARCH * HTTP/1.1' >> 'HOST:239.255.255.250:1900' >> 'MAN:"ssdp:discover' >> 'ST:ssdp:all' >> 'MX:1' >> ''). >> >> udpSocket := Socket newUDP. >> udpSocket sendData: message toHost: #[239 255 255 251] port: 1900. >> (udpSocket waitForSendDoneFor: 5). >> udpSocket closeAndDestroy. >> >> Hope this helps. >> >> CU, >> >> Udo >> >> >> >> >> >> >> On 18/05/15 23:29, Udo Schneider wrote: >>> Hi Manfred, >>> >>> I just stumbled over the IP address you are using (239.255.255.250). If >>> I remember correctly this is a IPv4 Class D Multicast address. >>> (224.0.0.0-239.255.255.255). >>> >>> So if you want to transmit datagrams to this IP address or recieve >>> datagrams sent to this multicast groups you have to set appropriate IP >>> Options. >>> >>> You can set this options using Socket>>#setOption:value: and read them >>> using Socket>>#getOption:. Please note that both methods expect the >>> option to set as a name - not as constant. E.g. >>> >>> socket setOption: 'IP_MULTICAST_IF' value: multicastInterface. >>> >>> If I do remember correctly you have to set the following options for >>> sending/receiving: >>> >>> Sending: >>> IP_MULTICAST_IF >>> (IP_MULTICAST_LOOP) >>> (IP_MULTICAST_TTL) >>> >>> Sending should AFAIK work w/o setting any option - although >>> IP_MULTICAST_IF is highly recommended. >>> >>> Receiving: >>> (SO_REUSEADDR) >>> IP_ADD_MEMBERSHIP >>> (IP_DROP_MEMBERSHIP) >>> >>> Receiving only works if you joined the multicast group previously. So I >>> assume that you need to do something like this (not tested). >>> >>> imrMultiaddr := #[239 255 255 250]. >>> imrInterface := #[0 0 0 0]. >>> ipMreq := imrMultiaddr , imrInterface. >>> socket setOption: 'MEMBERSHIP' value: ipMreq. >>> >>> Hope this helps. >>> >>> CU, >>> >>> Udo >>> >>> >>> >>> On 18/05/15 16:34, Manfred Kröhnert wrote: >>>> Hi Sven, >>>> >>>> On Mon, May 18, 2015 at 4:14 PM, Sven Van Caekenberghe >>>> <[hidden email] >>>> <mailto:[hidden email]>> wrote: >>>> >>>> >>>> > On 18 May 2015, at 15:47, Manfred Kröhnert >>>> <[hidden email] >>>> <mailto:[hidden email]>> wrote: >>>> > >>>> > Hi, >>>> > apparently I am missing something else. >>>> > >>>> > I can find devices when connected to a 'regular' LAN. >>>> > >>>> > However, I have a camera that creates a Wifi accesspoint and >>>> makes itself discoverable via SSDP. >>>> > Once I connect to this accesspoint my computer gets a valid IP >>>> address assigned and the NodeJS code is able to discover the device. >>>> > Unfortunately, the Pharo snippet I posted before does not give me >>>> any results and hangs in Socket>>waitForDataIfClosed: . >>>> > >>>> > Any further ideas? >>>> >>>> Are you sure you restarted the image and your code after switching >>>> networks ? >>>> >>>> >>>> I did not check this before. >>>> But I just downloaded a fresh 40613 image with PharoLauncher and started >>>> it after connecting to the camera accesspoint. >>>> The code snippet freezes there as well. >>>> >>>> Manfred >>> >>> >>> >> >> > > |
|
|
In reply to this post by Henrik Sperre Johansen
Thanks henrik
A better API would be so great. Stef Le 1/6/15 15:18, Henrik Johansen a écrit : >> On 29 May 2015, at 7:24 , Sven Van Caekenberghe <[hidden email]> wrote: >> >> >>> On 29 May 2015, at 18:23, Henrik Johansen <[hidden email]> wrote: >>> >>>> On 19 May 2015, at 11:01 , Sven Van Caekenberghe <[hidden email]> wrote: >>>> >>>> >>>>> On 19 May 2015, at 10:53, Udo Schneider <[hidden email]> wrote: >>>>> >>>>>> Did you look in all your package caches ? >>>>> I did. Must have been a victim of cleaning ... but maybe TimeMachine has something ... thanks for the reminder. >>>>> >>>>>> If it is just a small example, like one class, maybe it could be >>>>>> added to the image, in which case it should indeed be a slice. >>>>> The package was pretty simple. Basically only adding a few convenience methods around Socket>>#setOption:value: . Still I think a usage example in form of a class comment and test case might be appropriate. So unless Multicast should be part of the base image I'll start with a separate package first. >>>> Since Socket is a fundamental part, and multicast is a key feature, I think it would logical to move it to the image itself, with a test case. >>> It's not just multicast... >>> As a Socket newbie I recently spent longer than I care to admit learning you need to set SO_BROADCAST to true to not get a primitive failure when sending to a broadcast address. >>> At least the comments in sqUnixSocket were entertaining! >>> >>> Though I realize which options are actually supported depends on the VM, moving the list of potentially available cross-platform options (and a description of what they're used for) to a comment in the image (setOption: value: being the obvious location) might be a nice first step. >> Please help in the documentation effort. > I later found the option names are already documented in getOption:, but since that wasn't of much help (at least to me), I suggest introducing a more specific error than primitiveFailure. > Implementing that, the new test revealed a bug; empty UDP payloads will not be sent. > > A suggested fix for both these issues can be found in SLICE-Issue-15657-Empty-UDP-packets-are-not-sent-HenrikSperreJohansen.1 > > Cheers, > Henry > |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |