Yes, each UDP packet always contains both the sender and receiver IP (and port). But remember UDP is asynchronous and unreliable, as well as limited in payload size.
> On 24 May 2018, at 15:48, Hilaire <hila...@drgeo.eu> wrote: > > 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 > > >
