I have a multi-threaded test client that creates many clients to connect to my server at once. When multiple clients are created at the same time, the NetPeer.UniqueIdentifier is often the same, even though the NetPeer.Socket.LocalEndPoint is different when queried after. This of course causes the server to have a fit.
This appears to happen because the NetPeer.Socket.LocalEndPoint is not thread safe, and for a tiny moment there is a race condition where it returns the previous created socket's endpoint.
Currently, there is a local instance lock (m_initializeLock) around the InitializeNetwork() method. I think the naive fix here (without further investigation) would be to protect the BindSocket() method with a static object lock. If I do the same outside the Lidgren API when creating my peers, the race condition ceases to happen. More investigation is needed, but I wanted to put this up for anyone else who is having problems.
I have a multi-threaded test client that creates many clients to connect to my server at once. When multiple clients are created at the same time, the NetPeer.UniqueIdentifier is often the same, even though the NetPeer.Socket.LocalEndPoint is different when queried after. This of course causes the server to have a fit.
This appears to happen because the NetPeer.Socket.LocalEndPoint is not thread safe, and for a tiny moment there is a race condition where it returns the previous created socket's endpoint.
Currently, there is a local instance lock (m_initializeLock) around the InitializeNetwork() method. I think the naive fix here (without further investigation) would be to protect the BindSocket() method with a static object lock. If I do the same outside the Lidgren API when creating my peers, the race condition ceases to happen. More investigation is needed, but I wanted to put this up for anyone else who is having problems.
Windows 10 Pro, .Net Core 2.0.