A bit of archeology. I could not find message sends quickly in https://github.com/NikolaySuslov/croquet-squeak and in 5.2 squeak image.
Code by Johh MacIntosh of 2000 in squeak 5.2�� is below, for the primitiveOnlySupportsOneSemaphore=true it relies on #setPeer:port which in turn does a linux syscall to connect(2)�� restricting socket to send/receive only to/from a single peer.
in 2011 it was changed by 'ul' (I don't know whom the initials belong to) setPeer:port was dropped and this is how it stays since then both in squeak and pharo - purely image side logic to filter incoming datagrams.

= JMM =
receiveDataInto: aStringOrByteArray fromHost: hostAddress port: portNumber
| datagram |
"Receive a UDP packet from the given hostAddress/portNumber, storing the data in the given buffer, and return the number of bytes received. Note the given buffer may be only partially filled by the received data."

primitiveOnlySupportsOneSemaphore ifTrue:
[self setPeer: hostAddress port: portNumber.
^self receiveDataInto: aStringOrByteArray].
[true] whileTrue:
[datagram := self receiveUDPDataInto: aStringOrByteArray.
((datagram at: 2) = hostAddress and: [(datagram at: 3) = portNumber])
ifTrue: [^datagram at: 1]
ifFalse: [^0]]


= ul =
receiveDataInto: aStringOrByteArray fromHost: hostAddress port: portNumber
| datagram |
"Receive a UDP packet from the given hostAddress/portNumber, storing the data in the given buffer, and return the number of bytes received. Note the given buffer may be only partially filled by the received data."

[
datagram := self receiveUDPDataInto: aStringOrByteArray.
((datagram at: 2) = hostAddress and: [(datagram at: 3) = portNumber])
ifTrue: [^datagram at: 1]
ifFalse: [^0]] repeat

����, 26 ������. 2020 ��. �� 13:14, Danil Osipchuk <danil.osipchuk@gmail.com>:
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