I never saw a wrapaound happening, was just thinking what could go wrong, so I’d put this pretty low priority. values appeared to be low mostly, like under 10, nowhere near 16.7M.
Soak test passed 
There was one “System.ArgumentException: Invalid driver ID 0.” exception remaining when the server disconnected a client (on timeout), same stack trace as prev post. It seems that there was another message after the NetworkEvent.Type.Disconnect message in the message queue, or GetDriverRef() is called before the queue is checked in PopEventForConnection(). I just put a return; in ServerUpdateJob.Execute() to avoid PopEventForConnection being called after a NetworkEvent.Type.Disconnect. And then also checked for server disconnected clients before sending, as sending would throw the same exception if that NetworkConnection was later used. I’m just mentioning this as the docs say this shouldn’t be necessary, but seems it is for MultiNetworkDriver.Concurrent.
Good to read that the soak test passed.
Regarding the ArgumentException, is it possible that something in your code is resetting the NetworkConnection object to its default value when there is a disconnection? Otherwise I’m not sure I see a path in the UTP code for GetDriverRef to fail for a NetworkConnection that was previously valid. We’d need to have set the driver ID to 0 upon disconnection, but we can’t do that. NetworkConnection objects are passed by value so even if we modified the driver ID on disconnection, we wouldn’t be modifying the connection that’s stored in your code and that is presumably passed to later calls to PopEventForConnection.
Yes that’s exactly what we were doing when receiving the NetworkEvent.Type.Disconnect message. Ok not a Transport bug then, and looks like our attempt at a workaround was the right thing to do then after all. Thanks for all you help Simon.