On Wednesday, 22 July 2020 at 15:26:23 UTC, Dukc wrote:
> On Wednesday, 22 July 2020 at 13:17:11 UTC, wjoe wrote:
>> - Choosing a port which isn't in use right now isn't good enough because a few minutes later there may be another program using it, too, and for the same reason.
>
> But doesn't the UDP header include the sender IP address? So together with the magic number, shouldn't it be good enough? I know it definitely is not going to hold against jamming or a man in the middle, but it isn't supposed to, at this stage. It's used only for simulations that have the criticality of a casual Tetris server.
>
> I do acknowledge that the needs may rise later on. And if so, I understand that I'm much better off switching the protocol than trying to hardening the UDP.

No, the UDP header includes the source and destination ports only.
For transmission over the internet the Internet Protocol (IP) is used, which contains, among other things, the source and destination addresses.

The anatomy looks like this:

[ -------- IP - Datagram ------ ]
[IP-Header][UDP-Header][UDP-Data]
           [ - UDP - Datagram - ]

But keep in mind that the destination address can be a broadcast address, like e.g. 255.255.255.255, which you would use to announce your server to every PC in the network.
If you send a UDP datagram to a single address, however, it will still be delivered to every program on that PC which receives UDP datagrams from that port.

Also if you send UDP datagrams to multiple specific addresses, you need to send the same packet multiple times losing the major benefit of UDP - broadcast.
And packets with a broadcast address sent over the internet are dropped, as that would affect every connected PC.

If you are behind a router and send over the internet, your router will modify the IP-header, namely the sender address and replace that with your public address.
When receiving packets, the IP header contains the destination address of your public IP (the router), which it will translate to the local address according to the port forwarding setup.
That process is called network address translation (NAT) and is not only relevant for UDP.

On Wednesday, 22 July 2020 at 16:14:24 UTC, wjoe wrote:
> When receiving packets, the IP header contains the destination address of your public IP (the router), which it will translate to the local address according to the port forwarding setup.

Pardon me, I meant to say according to the current routing table rules.
Port Forwarding forwards all packets that match the defined criteria to the specified PC in the network.
A port forwarding rule isn't required for NAT to work. Sender and receiver both need to send a packet to each other. This will cause the router to add a rule and expect an answer on that port from the destination address.
When this packet arrives before the rule has been made it will be dropped (unless a port forwarding rule exists), so several packets may need to be sent for a successful punch-through.

On Wednesday, 22 July 2020 at 16:14:24 UTC, wjoe wrote:
> If you send a UDP datagram to a single address, however, it will still be delivered to every program on that PC which receives UDP datagrams from that port.

Normally binding two sockets to the same port is not allowed.

On Thursday, 23 July 2020 at 13:29:47 UTC, Kagamin wrote:
> On Wednesday, 22 July 2020 at 16:14:24 UTC, wjoe wrote:
>> If you send a UDP datagram to a single address, however, it will still be delivered to every program on that PC which receives UDP datagrams from that port.
>
> Normally binding two sockets to the same port is not allowed.

But it's possible when bound with the socket option SO_REUSEPORT (at least that's the name of the flag on linux since 3.9).

On Monday, 27 July 2020 at 09:41:44 UTC, wjoe wrote:
> But it's possible when bound with the socket option SO_REUSEPORT (at least that's the name of the flag on linux since 3.9).

The docs say it can't be used to hijack an address.
>This option must be set on each socket (including the first socket) prior to calling bind(2) on the socket.

On Tuesday, 28 July 2020 at 15:01:08 UTC, Kagamin wrote:
> On Monday, 27 July 2020 at 09:41:44 UTC, wjoe wrote:
>> But it's possible when bound with the socket option SO_REUSEPORT (at least that's the name of the flag on linux since 3.9).
>
> The docs say it can't be used to hijack an address.
>>This option must be set on each socket (including the first socket) prior to calling bind(2) on the socket.

Nowhere did I claim that you could hijack a bound port but that it's possible to reuse a port.

Nothing prevents a UDP library from setting that option automatically or by default.
Nothing prevents any program to bind to a port with that option set.

Normal behavior doesn't matter - what matters is what the library you're using and other programs are doing.

All of this doesn't change the fact that every program that has a socket bound to the same port on the same address at the same time will get the datagrams deliverd.

One way to handle this scenario is to bind your socket with the reuse option unset.
That would be first come first served.
Problem not solved - you still need to consider the fact that another program or server on a different PC/address in the network can assume that their corresponding client is up and running and wants to receive on that very port.
Due to the nature of UDP communication, the server needn't care if this assumption is true  and send datagrams to it which you will receive instead.