How to LAN feature
Locked
12
12
 
|
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 <[hidden email]> wrote: Hi Norbert, |
|
I already tried the one you suggested, but it returns the loopback IP on P7.
With the Henrik SSDP package, I can get the IP: SSDPParticipant new allLocalV4Addresses. However when I activate a second network interface, this last one returns an empty collection. When inactivating this second interface, it still returns an empty collection... Hilaire Le 13/05/2018 à 20:05, Julián Maestri a écrit : > NetNameResolver localHostAddress. "#[192 168 0 4]" -- Dr. Geo http://drgeo.eu |
|
|
(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. Unix: https://github.com/pharo-project/pharo-vm/blob/e0ce2d9d78c3c7b37bbc12cd8730c6a15f1f057c/opensmalltalk-vm/platforms/unix/plugins/SocketPlugin/sqUnixSocket.c#L273 Windows: https://github.com/pharo-project/pharo-vm/blob/e0ce2d9d78c3c7b37bbc12cd8730c6a15f1f057c/opensmalltalk-vm/platforms/win32/plugins/SocketPlugin/sqWin32NewNet.c#L1843 h_addr_list explanation: http://www.gnu.org/software/libc/manual/html_node/Host-Names.html On 13 May 2018 at 15:20, Hilaire <[hidden email]> wrote: I already tried the one you suggested, but it returns the loopback IP on P7. |
|
|
I don’t know if this will help, you can use OSProcess to run the ifconfig Unix (MAC OS) command, kind of like this:Use ifconfig -s to get a list of the interfaces: Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg enp2s0 1500 0 0 0 0 0 0 0 0 0 BMU lo 65536 0 1187 0 0 0 1187 0 0 0 LRU wlp3s0 1500 0 4943 0 0 0 2904 0 0 0 BMRU then: Ifconfig -a wlp3s0 and get back something like this: wlp3s0 Link encap:Ethernet HWaddr 94:53:30:14:aa:6d inet addr:192.168.0.14 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::21f3:b81d:eab3:f830/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:4998 errors:0 dropped:0 overruns:0 frame:0 TX packets:2904 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:6864552 (6.8 MB) TX bytes:295070 (295.0 KB) The second line has the host address and the broadcast address. I didn't say easy, I said possible. This works in Linux and MacOS. I dunno about MS Windows. Encrypted email at [hidden email] Web: www.objectnets.net and www.objectnets.org
|
|
|
Oops, the -s flag doesn't work on Mac OS. On Sun, May 13, 2018 at 7:41 PM, john pfersich <[hidden email]> wrote:
|
|
|
In reply to this post by John Pfersich
Hello,
Thanks for the tip. Yep, indeed it is possible to get the information from the command line. But I need a strategy that will work on Windows too (75% of the Dr. Geo user base). I have the same problem with bitmap clipboard, I have a strategy only for linux with command line[1], may be for Mac, but I don't know for Windows. Thanks Hilaire [1] https://bugs.launchpad.net/drgeo/+bug/1697418 ----- http://drgeo.eu -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html |
Re: How to LAN feature
|
|
In reply to this post by Julián Maestri-2
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 |
|
Administrator
|
In reply to this post by HilaireFernandes
HilaireFernandes wrote
> I need a strategy that will work on Windows too I assume you know about ProcessWrapper. Is there no Windows command to get similar info? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Cheers,
Sean |
|
|
No idea about what it is.
Le 14/05/2018 à 15:03, Sean P. DeNigris a écrit : > HilaireFernandes wrote >> I need a strategy that will work on Windows too > I assume you know about ProcessWrapper. Is there no Windows command to get > similar info? -- Dr. Geo http://drgeo.eu |
|
|
Might be in cmd:
ipconfig /all Cédrick > Le 14 mai 2018 à 16:56, Hilaire <[hidden email]> a écrit : > > No idea about what it is. > > >> Le 14/05/2018 à 15:03, Sean P. DeNigris a écrit : >> HilaireFernandes wrote >>> I need a strategy that will work on Windows too >> I assume you know about ProcessWrapper. Is there no Windows command to get >> similar info? > > -- > Dr. Geo > http://drgeo.eu > > > |
|
Administrator
|
In reply to this post by HilaireFernandes
HilaireFernandes wrote
> No idea about what it is. >> I assume you know about ProcessWrapper ProcessWrapper = OSProcess for Windows ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Cheers,
Sean |
|
|
In reply to this post by Henrik Sperre Johansen
Hi Henrik,
As I have very limited knowledge on network stuff, to get started, do you have simple example code to show how to use your package? Thanks Hilaire Le 08/05/2018 à 08:28, Henrik Sperre Johansen a écrit : > No, but it does involve setting certain options on the socket, etc. > You could check ifhttp://smalltalkhub.com/#!/~henriksp/SSDP is > appropriate/works for you. -- Dr. Geo http://drgeo.eu |
|
|
Oh, forget about my request, I miss some of the important comments in
your package. I should have enought to play with it. Le 18/05/2018 à 11:33, Hilaire a écrit : > > As I have very limited knowledge on network stuff, to get started, do > you have simple example code to show how to use your package? -- Dr. Geo http://drgeo.eu |
|
|
In reply to this post by Henrik Sperre Johansen
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 |
Re: How to LAN feature
|
|
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 <[hidden email]> 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 > > > |
|
|
Yes, it is only to know where is the server, then I will use your Zinc
framework for the real exchange stuff. The udp message may just be 'DrGeoShare' Le 24/05/2018 à 15:51, Sven Van Caekenberghe a écrit : > 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. -- Dr. Geo http://drgeo.eu |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |