Hi Henrik,
Le 22/05/2018 à 10:57, Henrik Sperre Johansen a écrit :
With UDP, there is no connection concept, so I'd reckon
waitForConnectionFor: is what gives you a TimeOut error...
The #waitForConnectionFor: message seems not to be the issue. I was
doing something apparently stupid: I started first the broadcast from
the shell, then the listener in Pharo. Funnily I was doing it the other
way when using nc to listen. Any way I will still discard
#waitForConnectionFor:
Delete that, only use waitForDataFor: n , put it in a loop (so it won't stop
listening until it receives a request), and you should be fine.
ok
Doesn't quite look like neither server nor client yet, the workflow should
be something like:
1) server (you) starts, listening to port you're using and waitsForData: in
an infinite loop.
2) client (student) starts, sends request to broadcast address/port, then
waitsForData: on the socket it created.
3) broadcast server reads request, generates reply, and sends it to the
originIP/port of the request
4) client receives reply, handles it, and closes socket.
If I understand correctly what you suggest, student workstations
initiate the broadcast to manifest interest to access
My scenario initial idea was a bit more like:
1) server, teacher workstation, continuously broadcast its IP to a
specific port.
2) student workstation, when they want to access teacher shares, listen
to this port to get the teacher workstation IP
3) once student workstation got the ip, it stops listen for broadcast,
and it connects to the to the teacher workstation http server to access
the shares.
Your scenario does not need a continuously broadcast...
PS. Why use nc when you already have a working broadcast client in pharo?;)
Oh, just to play with one variable at a time. But seems I introduced a
human factor.
Thanks
Hilaire
--
Dr. Geo
http://drgeo.eu
