NetPeer establish connection is 2 way handshake instead of 3?

[HiddenMonk]

Not sure how big of an issue this is, but it seems that the way connections are established is...

Client1 - Send connect request with connectionID generated from tick time. Client2 - Receive connect request, set connectionState to connected, send connect accept with received connectionID Client1 - Receive connect accept, if connectionID is same we set connectionState to connected.

Shouldnt it be more so like how tcp 3 way handshake does it? (Possibly for security reasons such as helping avoid spoofed ip address?)

Client1 - Send connect request with randomly generated long value. Client2 - Receive connect request, send connect accept with received long value as well as send our own randomly generated long value. Client1 - Receive connect accept, if sent long value is same we set connectionState to connected and we send a ConnectAcceptFinal message with received long value. Client2 - Receive connect accept final, if sent long value is same we set connectionState to connected.

Maybe even then just keep connectionID a int that we just increment every new connection?

[proepkes]

If two clients connect simultaneously the current behaviour leads to two identical connectionIDs. The server should generate an ID and tell it to the client.

The connectionID should be random instead of a simple increment so it cannot be guessed by other clients that easily (as a small step towards security). In my project I always overwrite the connectionID on the server and tell the client, see here

[RevenantX]

@proepkes connectionID is not simple increment. This is current UTC time in ticks. This is not for security.

In my project I always overwrite the connectionID on the server and tell the client,

For now biggest connectionID will be selected. This made for Peer2Peer connections, where 2 peers can call connect almost simultaneously, and in that situation there is no "client" and "server".