Hi there,

I'm reading from a UDP socket in C# as follows:

EndPoint endPoint = new IPEndPoint(IPAddress.Any, 0);
int receivedBytes =
  this.socket.ReceiveFrom(
    this.receiveBuffer,
    this.receiveBuffer.Length,
    SocketFlags.None,
    ref endPoint);

This provides me an EndPoint of the packet's sender. Does this EndPoint object uniquely identify the sender? If not, what would be a good scheme for doing so? A naive approach would be for a connecting client to generate a random uint and include it in all of that packets (handling the very very rare chance of collision), but perhaps there's a smarter way?

That 0 isn't for binding the socket, it's just an empty initialization. TryReceive will fill out that object with both the IP and port received. The socket has already been bound by the time I call that.

In my system the first thing a new client sends to a server is a ConnectRequest packet, which it repeats at some frequency until it gives up or receives a ConnectAccept. Until it receives a ConnectAccept it won't respond to ping/heartbeat packets from the server. Similarly, if the server receives a ConnectRequest packet from a client it thinks is already connected, it will ignore it.

In the situation you describe, the client would drop and stop responding to server data or heartbeats. The server would ignore the restarted client's connect attempts until it timed out the old client connection. Then the client could re-establish and both client and server would know that this was a fresh start.

However, Is it possible for two users using the same NAT gateway to have the same IPEndpoint?

Okay. It looks like I won't need to attach an ID to my packets in this case. If/when I start looking into encrypting/checksumming my packets I'll get unique client identification anyway based on the keys used.

Right now I'm focusing on making a fun game first. I'll be worrying about malicious activity a little later. One thing I should add is I'll be using the PlayFab matchmaker, which gives you an authentication token that needs to be passed to the server anyway on connection to validate the user's identity. Of course, it would be possible to hijack a player's session if I send that matchmaker token in plaintext.

A rough sketch of what I will eventually do is as follows:

1) Client connects independently to PlayFab via HTTPS, receives token.

2) Client connects to my server via either HTTPS or TLS.

3) Server provides some sort of fast key (symmetric?) to client over HTTPS/TLS.

4) Client disconnects from HTTPS/TLS with the key.

5) Client begins sending UDP packets to the server, including the PlayFab auth token.

5a) These UDP packets begin with a 4-byte CRC of the packet's header/data bytes and the network protocol version hashed together, followed by a header and the packet data.

5b) The client uses its key to encrypt the packet+CRC and send it to the server, including one packet with the PlayFab auth token.

6) The server does the same for any replies.

I'm not exactly sure the best way to do the initial key exchange, but I'm some way away from having to worry about that. Ideally I'd just do it over UDP but I'm not so sure how easy that will be vs. HTTPS/TLS. What this scheme should give me is tamper protection (via the CRC), secure client identification (if the CRC isn't right when the packet is decrypted, the client has the wrong key), version checking (to make sure an outdated client isn't connecting), and overall encryption for just 4 bytes.