I think he means you can not discover all interfaces from Pharo. I have 2 network interfaces with addresses 192.168.0.4 and 192.168.56.1 Pharo only returns the first one.
NetNameResolver localHostName "'thepc'". NetNameResolver localHostAddress. "#[192 168 0 4]" NetNameResolver nameForAddress: #[192 168 0 4] timeout: 60. "'thepc'" NetNameResolver nameForAddress: #[192 168 56 1] timeout: 60. "'thepc'" If you need to broadcast something on the second one, you have no way to automatically discover it. (eg if you wanted to prompt the user which one to broadcast to, or to broadcast on them all) On 13 May 2018 at 14:50, Hilaire <hila...@drgeo.eu> wrote: > Hi Norbert, > > Just to be sure I understood correctly what you wrote regarding network > interface: Do you mean it is impossible to discover the network interface > IP address from the image? It is this IP the teacher Dr. Geo server needs > to broadcast over UDP. > > Hilaire > > > Le 08/05/2018 à 16:22, Henrik Sperre Johansen a écrit : > >> mDNS and SSDP are pretty much interchangeable, implementation wise;) >> >> The main problem; most computers these days come with multiple networking >> interfaces, and are usually connected to separate subnets. >> So when you connect a socket to the broadcast address, you have no idea >> which interface it will actually send the request over, and whether you >> can >> communicate with other entities is sort if hit or miss. >> >> Pharos netresolver is blissfully unaware/unable to tell you which >> interfaces >> are available, >> most of the work in the SSDP implementation went into trying to detect all >> the different ones (impossible without the added networking prims, and >> still >> unreliable whether it will find the correct ones with...), and bind:'ing a >> socket to each specifically. >> >> IIRC, the default server/client instantiation exemplified in class >> comments >> now simply binds to 0:0:0:0 and hopes the default interface is what you >> wanted, SSDPServer>>onAllInterfacesOfferServiceType:atLocation: runs >> through the more extensive setup. >> >> Cheers, >> Henry >> >> P.S. In second place; a listener loop capable of error handling a spotty >> wifi connection/machine sleep cycles... >> > > -- > Dr. Geo > http://drgeo.eu > > > >
