When one opts to NOT receive status update messages, the Connection does not properly update its "Status" property value after Connection.Connect() is called.
While the Connection.m_status field changes to NetConnectionStatus.InitiatedConnect, the Status property keeps its original None value.
When using NAT introduction, this makes detection of the connection's state unreliable since two NAT introductions are usually received by clients. If the first one triggers a call to Connection.Connect(), upon receiving the second, assessing the state of the connection via Connection.Status leads to incorrectly assessing that Connect() can be called again.
Looking at the code, the clear culprit is the direct modification of the Connection.m_status field rather than using the more complete Connection.SetStatus() call which takes care of updating the property's value when needed.
Note that there are also a few other places in the code where such direct modification of m_status probably would have similar ill results. It seems that in general, no code should directly modify m_status but rather call SetStatus().
These changes highlights how to fix the issue (read the comments) and the other places that probably would be worth fixing.
Currently, I am only interested in fixing NetPeer.cs for the current needs of the game my company is developing and can prepare a Pull Request for that purpose ASAP if needed.
When one opts to NOT receive status update messages, the Connection does not properly update its "Status" property value after Connection.Connect() is called. While the Connection.m_status field changes to NetConnectionStatus.InitiatedConnect, the Status property keeps its original None value.
When using NAT introduction, this makes detection of the connection's state unreliable since two NAT introductions are usually received by clients. If the first one triggers a call to Connection.Connect(), upon receiving the second, assessing the state of the connection via Connection.Status leads to incorrectly assessing that Connect() can be called again.
Looking at the code, the clear culprit is the direct modification of the Connection.m_status field rather than using the more complete Connection.SetStatus() call which takes care of updating the property's value when needed. Note that there are also a few other places in the code where such direct modification of m_status probably would have similar ill results. It seems that in general, no code should directly modify m_status but rather call SetStatus().
I have illustrated the issue in a (very slightly) modified version of the MasterServerSample sample code. It is present at this commit in my fork: https://github.com/nekoniaow/lidgren-network-gen3/commit/801b46d06807c8d7b2e0550ed1442e0cd7d4bd6b
These changes highlights how to fix the issue (read the comments) and the other places that probably would be worth fixing.
Currently, I am only interested in fixing NetPeer.cs for the current needs of the game my company is developing and can prepare a Pull Request for that purpose ASAP if needed.
Cheers, Laurent Giroud
PS: corresponding Pull Request: #118.