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 <[email protected]>: > > > > On 26 Jan 2020, at 09:42, HilaireFernandes <[email protected]> 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 > > > >
