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 <udo.schnei...@homeaddress.de> 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 >>> <s...@stfx.eu >>> <mailto:s...@stfx.eu>> wrote: >>> >>> >>> > On 18 May 2015, at 15:47, Manfred Kröhnert >>> <mkroehner...@googlemail.com >>> <mailto:mkroehner...@googlemail.com>> 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 >> >> >> >> > > >
