Oh, for the record, regarding the issue discussed bellow about determining the NIC IP. When a server broadcast an UDP message, the client receiving it can fetch the server NIC IP from the result returned by the #receiveUDPDataInto: message. I only tested it on the same workstation, but I guess it work as the UDP datagram is encapsulated in an IP packet. Hilaire Le 14/05/2018 à 11:28, Henrik Sperre Johansen a écrit :
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.
-- Dr. Geo http://drgeo.eu