How to LAN feature
Locked
12
12
 
|
Hi,
I am looking for advices on a feature I want to develop for Dr. Geo. The need takes place in a LAN, for example in a School computer lab. A teacher and students each run their own instance of Dr. Geo. I want the teacher to be able to share with her students some sketches. Then the students,from their Dr. Geo running instance, can browse and open the sketches shared by the teacher. The user scenario will be like this: - Teacher copies the sketches she wants to share with her students in her DrGeo.app/myShare folder. Then she activates the Dr. Geo share service (from the setting browser for example). - Students start their own instances of Dr. Geo. It automatically scans (in the background preferably) the LAN for any available LAN shares. When a student goes to File>open she can also browse and open the discovered shares. - Ideally students could also save their work on the teacher share. The constraints: there is no such things as fixed IP. So the scan is over a subnetwork range. Any advices, reference reading, traps to avoid? Thanks Hilaire -- Dr. Geo http://drgeo.eu |
|
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 > Am 06.05.2018 um 12:47 schrieb Hilaire <[hidden email]>: > > Hi, > > I am looking for advices on a feature I want to develop for Dr. Geo. > > The need takes place in a LAN, for example in a School computer lab. A teacher and students each run their own instance of Dr. Geo. I want the teacher to be able to share with her students some sketches. Then the students,from their Dr. Geo running instance, can browse and open the sketches shared by the teacher. > > The user scenario will be like this: > > - Teacher copies the sketches she wants to share with her students in her DrGeo.app/myShare folder. Then she activates the Dr. Geo share service (from the setting browser for example). > > - Students start their own instances of Dr. Geo. It automatically scans (in the background preferably) the LAN for any available LAN shares. When a student goes to File>open she can also browse and open the discovered shares. > > - Ideally students could also save their work on the teacher share. > > The constraints: there is no such things as fixed IP. So the scan is over a subnetwork range. > > Any advices, reference reading, traps to avoid? > > Thanks > > Hilaire > > -- > Dr. Geo > http://drgeo.eu > > > |
|
|
On Sun, May 6, 2018 at 1:31 PM, Norbert Hartl <[hidden email]> wrote: 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 Not really for Pharo itself but PirateBox is a handy tool for gatherings like you mention (especially since there are often lots of network problems taking away valuable time). Phil > Thanks |
|
|
In reply to this post by NorbertHartl
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 |
|
|
> Am 07.05.2018 um 18:08 schrieb Hilaire <[hidden email]>: > >> 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]? > Norbert > 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 |
Re: How to LAN feature
|
|
Uploading can be done using an HTTP POST or PUT, just like Playground does its Remote Publish, or Monticello its Save operation.
> On 7 May 2018, at 19:15, Hilaire <[hidden email]> wrote: > > 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 > > > |
|
|
In reply to this post by NorbertHartl
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 |
Re: How to LAN feature
|
|
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 |
|
|
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.
|
|
|
On 8 May 2018 at 15:32, Cédrick Béler <[hidden email]> wrote:
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. 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? 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 |
Re: How to LAN feature
|
|
> On 8 May 2018, at 15:05, Ben Coman <[hidden email]> wrote: > >> Le 8 mai 2018 à 08:28, Henrik Sperre Johansen <[hidden email]> 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 <[hidden email]> 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-about-you-(and-your-device)/ > > 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. I am interested in this and will read a bit about it, if I find time. > @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 |
|
|
In reply to this post by Ben Coman
If they all have Macs that would work. For the rest I doubt it will be that easy. Norbert
|
Re: How to LAN feature
|
|
In reply to this post by Ben Coman
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 |
|
|
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 <[hidden email]> wrote: Ben Coman wrote |
|
|
That is mDNS being used. Bonjour is the MacOS service and Avahi the linux one. Norbert
|
|
|
In reply to this post by NorbertHartl
Hi,
Just want to point that I did some work late 2017 on UDP sockets including multicast and broadcast. The package named 'NetworkExtras' is part of the ReusableBricks repo of my team. It has some dependencies on other packages. I tested it in Pharo 6, but not 7. Noury PS. Since I can't keep up with the mailing-list traffic, don't forget to keep me in CC so I can react
|
|
In reply to this post by HilaireFernandes
On Sun, May 6, 2018 at 1:48 PM Hilaire <[hidden email]> wrote: Hi, I think that even in the case of a LAN you can still do it via internet using something like github or dropbox. Many of those online tools work on an account basis and Pharo already offers some support for Github. If it has to be a LAN and the internet is a no go then another choice would be to have the "server" which probably will be the teacher access to the truter and retriever the IPs directly, even if the ip changes the connection can be identified by name and of course the router will provide the ips and names of all connections to it. I have not tried from Pharo but I am assuming it should be doable because the router can be access via an internet browser for their setup and settings. Format wise you could use something like STON , or if you rely of raster graphics (JPEG, PNG) , fuel could be a better choice for binary formats and eliminate any loss of performance while loading scetches remotely. Nowdays it has become the norm to identify people through popular accounts like Google (gmail), Facebook, iCloud, Microsoft Account, Twitter etc. In the case of dropbox you get also synchronisation for free which will give students immediate access not only to sceteches by teachers but all other students too because dropbox supports shared folders and you wont have to actively share each individual folder because those folder do this automagically for you. Dropbox also stores the version of the files for up to 30 days and of course its free, unless the scetches demand much more than 2 GBs which if they are anything like SVG they should not. |
|
|
In reply to this post by Sven Van Caekenberghe-2
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 |
|
|
In reply to this post by Henrik Sperre Johansen
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 |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |