As soon as you start listening on udp port every host having connectivity will be able to send you a datagram which will hit a smalltalk handler. It is a concern both from performance and security pov. You may be willing to implement your own protocol suit on top of udp to have a tcp like endpoint pairing and session managment, but without buffering/windowing and reliable transmission to meet realtime requirements of gaming etc. For that you will need this. Probably it was used by multiuser collaboration project croquet https://en.m.wikipedia.org/wiki/Croquet_Proje Regards Danil вÑ, 26 Ñнв. 2020 г., 12:08 Sven Van Caekenberghe <sven@stfx.eu>:
On 26 Jan 2020, at 09:42, HilaireFernandes <hilaire@drgeo.eu> wrote:
Sven Van Caekenberghe wrote
Sounds nice, and indeed a (more) fun way to teach programming.
But I still fail to see why you have to filter incoming UDP packets on their origin address.
If third party software on the workstation are connected to other network services, don't you want to filter out? Or am I missing something?
I think so: you listen on an UDP socket on a specific port (and optionally bound to a specific network interface on your machine), then you get only datagrams directed to you - this happens at the OS level.
A (at host:port) sends a datagram to B (at host:port), to reply, B looks at the datagram to figure out the sender's info and replies.
You can study the example UDPSocketEchoTest to see how this works.
HTH,
Sven