Julián Maestri-2 wrote >> >> (impossible without the added networking prims, and still unreliable >> whether it will find the correct ones with...) >> > > The problem seems to be here: he->h_addr_list[0] its a list of addresses > and only the first one is used.
That's the "old" ipv4 primitive. The "new" ipv4/ipv6 primitive (sqResolverGetAddressInfoHostSizeServiceSizeFlagsFamilyTypeProtocol) uses getaddrinfo instead, and lets you interate over the results; this is what the SSDP package tries to do when you specify allLocalV4Addresses. It's unreliable because: 1) Finding the correct hostname can be difficult (iirc, some vm's fail the hostname prim, and always returns the fallback 'localhost') 2) It uses DNS lookups, which can both be slow, and depend on network configuration. 3) The correct domain to use when you want aggregated results over multiple interfaces (.local? nothing?) differs from platform to platform. (iirc, OSX only ever returns a single entry if adding .local) "However when I activate a second network interface, this last one returns an empty collection" I just tested on a Windows 10 machine with 6.1 release (Pharo 6.1 stable\Pharo.exe CoInterpreter VMMaker.oscog-eem.2254 uuid: 4f2c2cce-f4a2-469a-93f1-97ed941df0ad Jul 20 2017), for me the statement part := SSDPParticipant new. part allLocalV4Addresses. correctly returns 1/2/1 addresses when connecting/disconnecting to a wireless network :/ Why lookup would start to fail when you activate an interface, and stay failing after you remove it, I couldn't say, but I can say that SSDPParticipant >> hostName returning names that DNS won't resolve properly for some or another reason has been a problem I've encountered before. Cheers, Henry -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
