Le 06/05/2018 à 13:31, Norbert Hartl a écrit :

If it is on a single network this should be doable by using UDP broadcast announcements. The share server can announce some information and its IP in a UDP packet being broadcasted. Every client receives that and then knows the address of the server to connect to

Hope this helps, Norbert

Yep, then I can I set up a FTP server to run on the Pharo teacher instance. I already wrote a facade for user friendly FTP client. Does any one know about FTP server on Pharo, for example this one[1]? Thanks Hilaire [1] http://map.squeak.org/package/f84afa9e-c2ea-4d4c-bc65-aea93701753d -- Dr. Geo http://drgeo.eu

As described previously, students may also upload their work at the end of a teaching session. Hilaire Le 07/05/2018 à 18:57, Norbert Hartl a écrit :

For what do you need an FTP server? For browsing and downloading usually a HTTP server is as good as. You implement a handler that returns a directory list for directories and the file content for files. Can be used with every web browser and zinc you have already in the image,

Norbert

-- Dr. Geo http://drgeo.eu

I have been reading and learning about your Zinc HTTP framework, on the client side for now. It looks fantastic with all the needed pieces. I guess the server part has all the needed part of the teacher share counter part. Thanks Hilaire Le 07/05/2018 à 20:05, Sven Van Caekenberghe a écrit :

Uploading can be done using an HTTP POST or PUT, just like Playground does its Remote Publish, or Monticello its Save operation.

-- Dr. Geo http://drgeo.eu

HilaireFernandes wrote

Computer should be on a same network, however not sure about swtich in between.

Does UDP broadcast required particular privilege on the host?

Thanks

Hilaire

Le 06/05/2018 à 13:31, Norbert Hartl a écrit :

...

If it is on a single network this should be doable by using UDP broadcast announcements. The share server can announce some information and its IP in a UDP packet being broadcasted. Every client receives that and then knows the address of the server to connect to

-- Dr. Geo http://drgeo.eu

No, but it does involve setting certain options on the socket, etc. You could check if http://smalltalkhub.com/#!/~henriksp/SSDP is appropriate/works for you. Cheers, Henry -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Le 8 mai 2018 à 08:28, Henrik Sperre Johansen < henrik.s.johansen@veloxit.no> a écrit :

HilaireFernandes wrote

Computer should be on a same network, however not sure about swtich in between.

Does UDP broadcast required particular privilege on the host?

Thanks

Hilaire

Le 06/05/2018 à 13:31, Norbert Hartl a écrit :

If it is on a single network this should be doable by using UDP broadcast announcements. The share server can announce some information and its IP in a UDP packet being broadcasted. Every client receives that and then knows the address of the server to connect to

-- Dr. Geo http://drgeo.eu

No, but it does involve setting certain options on the socket, etc. You could check if http://smalltalkhub.com/#!/~henriksp/SSDP is appropriate/works for you.

Cheers, Henry

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

On 8 May 2018 at 15:32, Cédrick Béler <cdrick65@gmail.com> wrote:

Hi, FYI, Noury did this package (Network-Extra). I will test for my lecture. It has UDP Multicast/broadcast and may help for the discovery phase (I’m interested in that either).

He said that about it:

- UDP support : mutlicast + broadcast - fragment a (large) data et assemble it over UDP -la possibilité de fragmenter une donnée trop grande et la reconstruire au-dessus d'UDP

Gofer it smalltalkhubUser: 'CAR' project: 'ReusableBricks'; configurationOf: 'ReusableBricks'; loadBleedingEdge

Hope this help,

See you,

Cédrick

Ps: tell me if you use it.

If we've got multicast support for Pharo, perhaps its not a long jump to implementing mDNS. Then the teacher could share out their machine as "teacher.local" to let student machines connect to it. https://www.trustwave.com/Resources/SpiderLabs-Blog/mDNS---Telling-the-world... https://tools.ietf.org/html/rfc6762 The most basic kind of Multicast DNS client may simply send standard DNS queries blindly to 224.0.0.251:5353, without necessarily even being aware of what a multicast address is. This change can typically be implemented with just a few lines of code in an existing DNS resolver library. @Udo, did you ever find that mDNS package you lost? http://forum.world.st/Issue-with-UDP-Sockets-tp4827014p4827245.html mDNS would be an interesting facility to include in the main Pharo release image, perhaps making it very easy for our "live" systems to locate each other on a local network without external infrastructure. cheers -ben

Am 08.05.2018 um 15:05 schrieb Ben Coman <btc@openinworld.com>:

...

Le 8 mai 2018 à 08:28, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no <mailto:henrik.s.johansen@veloxit.no>> a écrit :

HilaireFernandes wrote

...

Computer should be on a same network, however not sure about swtich in between.

Does UDP broadcast required particular privilege on the host?

Thanks

Hilaire

Le 06/05/2018 à 13:31, Norbert Hartl a écrit :

...

If it is on a single network this should be doable by using UDP broadcast announcements. The share server can announce some information and its IP in a UDP packet being broadcasted. Every client receives that and then knows the address of the server to connect to

-- Dr. Geo http://drgeo.eu <http://drgeo.eu/>

No, but it does involve setting certain options on the socket, etc. You could check if http://smalltalkhub.com/#!/~henriksp/SSDP <http://smalltalkhub.com/#!/~henriksp/SSDP> is appropriate/works for you.

Cheers, Henry

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html>

On 8 May 2018 at 15:32, Cédrick Béler <cdrick65@gmail.com <mailto:cdrick65@gmail.com>> wrote: Hi, FYI, Noury did this package (Network-Extra). I will test for my lecture. It has UDP Multicast/broadcast and may help for the discovery phase (I’m interested in that either).

He said that about it:

- UDP support : mutlicast + broadcast - fragment a (large) data et assemble it over UDP -la possibilité de fragmenter une donnée trop grande et la reconstruire au-dessus d'UDP

Gofer it smalltalkhubUser: 'CAR' project: 'ReusableBricks'; configurationOf: 'ReusableBricks'; loadBleedingEdge

Hope this help,

See you,

Cédrick

Ps: tell me if you use it.

If we've got multicast support for Pharo, perhaps its not a long jump to implementing mDNS. Then the teacher could share out their machine as "teacher.local" to let student machines connect to it.

If they all have Macs that would work. For the rest I doubt it will be that easy. Norbert

https://www.trustwave.com/Resources/SpiderLabs-Blog/mDNS---Telling-the-world... <https://www.trustwave.com/Resources/SpiderLabs-Blog/mDNS---Telling-the-world...>

https://tools.ietf.org/html/rfc6762 <https://tools.ietf.org/html/rfc6762> The most basic kind of Multicast DNS client may simply send standard DNS queries blindly to 224.0.0.251:5353 <http://224.0.0.251:5353/>, without necessarily even being aware of what a multicast address is. This change can typically be implemented with just a few lines of code in an existing DNS resolver library.

@Udo, did you ever find that mDNS package you lost? http://forum.world.st/Issue-with-UDP-Sockets-tp4827014p4827245.html <http://forum.world.st/Issue-with-UDP-Sockets-tp4827014p4827245.html>

mDNS would be an interesting facility to include in the main Pharo release image, perhaps making it very easy for our "live" systems to locate each other on a local network without external infrastructure.

cheers -ben

Ben Coman wrote

mDNS would be an interesting facility to include in the main Pharo release image, perhaps making it very easy for our "live" systems to locate each other on a local network without external infrastructure.

cheers -ben

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... -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

That is mDNS being used. Bonjour is the MacOS service and Avahi the linux one. Norbert

Am 09.05.2018 um 02:25 schrieb Julián Maestri <serpi90@gmail.com>:

You could also publish on a zeroconf service (Bonjour/Avahi) https://en.wikipedia.org/wiki/Zero-configuration_networking

...

On 8 May 2018 at 11:22, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> wrote: Ben Coman wrote

...

mDNS would be an interesting facility to include in the main Pharo release image, perhaps making it very easy for our "live" systems to locate each other on a local network without external infrastructure.

cheers -ben

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...

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

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 <hilaire@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

(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/e0ce2d9d78c3c7b37bbc12cd8730c... Windows: https://github.com/pharo-project/pharo-vm/blob/e0ce2d9d78c3c7b37bbc12cd8730c... h_addr_list explanation: http://www.gnu.org/software/libc/manual/html_node/Host-Names.html But changing that might affect the whole networking package, so i don't think it's going to be changed soon. On 13 May 2018 at 15:20, Hilaire <hilaire@drgeo.eu> wrote:

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

Oops, the -s flag doesn't work on Mac OS. On Sun, May 13, 2018 at 7:41 PM, john pfersich <jpfersich@gmail.com> wrote:

​ ​ 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 jgpfersich@protonmail.com Web: www.objectnets.net and www.objectnets.org

On May 13, 2018, at 11:27, Julián Maestri <serpi90@gmail.com> 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.

Unix: https://github.com/pharo-project/pharo-vm/blob/e0ce2d9d78c3c 7b37bbc12cd8730c6a15f1f057c/opensmalltalk-vm/platforms/unix/ plugins/SocketPlugin/sqUnixSocket.c#L273 Windows: https://github.com/pharo-project/pharo-vm/blob/e0ce2d9d78c3c 7b37bbc12cd8730c6a15f1f057c/opensmalltalk-vm/platforms/win32 /plugins/SocketPlugin/sqWin32NewNet.c#L1843 h_addr_list explanation: http://www.gnu.org/software/li bc/manual/html_node/Host-Names.html

But changing that might affect the whole networking package, so i don't think it's going to be changed soon.

On 13 May 2018 at 15:20, Hilaire <hilaire@drgeo.eu> wrote:

...

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

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

Might be in cmd: ipconfig /all Cédrick

Le 14 mai 2018 à 16:56, Hilaire <hilaire@drgeo.eu> 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

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

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 <hilaire@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

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