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