The servers do seem to struggle with the UMR. Heck, they have a hard time relaying consist information in the Southern China and Debrecen-Nyiregyháza sessions. The problem might lie in the algorithm by which train speeds and positions are communicated between client and server with error. A successful communication scheme should have the following properties. If a train is unassigned, has its driver removed, or is decoupled from an active locomotive, its location and brake status will automatically be sent to the server. If products are added or removed to a car or industry, that information is synchronized as well. If a client's information is outside of 3 deviations from what is on the server, the client will automatically move the outlying object to the reported mean location - this does not apply to consists that are directly under said client's control.
The client sends information about their own control state (throttle/brake or DCC) changes, AI driver commands, and couple/decouple requests to the server as they happen, as well as regular location updates and queries to ensure synchronization. The server then relays this same information to all clients; the turnaround time is used to compute latency. If a data send request fails, the game tries to resend up to four times before kicking the client off the server. If the latency exceeds 2000 ms, the game should attempt to reconnect.
Network data should include the following: locations, speeds, and consist associations of rolling stock; locations of drivers with respect to locomotives; assignment of drivers to players; AI commands; product loads; and signal states.