Chances are that due to your mobile Internet access there are -sometimes (and other times not)- increased packet loss/packet checksum mismatches, resulting on TCP retransmissions, resulting in a certain probability that you may suddenly get disconnected.
If you are were on Linux, you could use the tcptraceroute utility to measure this.
On Windows, there is
tcping. It doesn't allow you to set a packet size and does not indicate retransmits but it's better than nothing and way more user friendly than wireshark / tcpdump (unless you know how these work in which case using these would be way better).
tcping -i 5 -n 120 engineer.megaglest.org 61357This would make an okay test, sending a TCP packet to the gameserver port of the engineer gameserver every 5 seconds, 120 packets total, resulting in a 10 minute test (make it longer for more reliable results).
Make sure this server is not running a game but is in the
waiting for players state while you're testing.
It will be interesting to see whether there will be a large difference in the minimum and maximum trip times. If the maximum trip time is way higher than the minimum this would provide an indication that packet retransmissions took place because of either partial (TCP checksum mismatches) or complete packet loss, causing packets to arrive with much delay. Since the game really needs every client and the server to receive every bit of information that is sent around (otherwise calculations would be off), loosing packets is not acceptable. So the gameserver may need to wait for a client to retransmit packets (or needs to retransmit them to the client). However, if a TCP timeout kicks in or one packet of data could not be transmitted between server and client (any direction) for more than 60 frames (IIRC that's 60 seconds) the client will be dropped.
Clients will receive a warning if the transmit times for packets are elevated. However, they could be so high that the packet times out entirely and retransmission fails. If this happens instantly, you would get instantly disconnected without a warning, too.
I'm obviously explaining this under a generic networking aspect, you could get a better explanation by examining the actual networking code.
