I forget but isn't MT using UDP and thus stateless and connectionless? So in a situation where you have significant packet loss, losing a few of the keep-alive packets would be problem.
Keep alives are not used in UDP. Their purpose is to ensure that routers between points A and B continue to cache the route information. Since UDP is connectionless, there is no need to cache the data (the routers can never tell when the communication will end).
Besides, keep-alives have a rather dirty reputation and many organizations will block them (they're just empty packets). They're good because they cause the routers to continue to cache routes that they might otherwise purge from lack of use. They're bad because they cause the routers to continue to cache routes that aren't being used (if they were being used, the keep-alives wouldn't be necessary, would they?
In any case, from trevor's reply, it must be TCP-related. Most likely there's a flaky router between points A and B. Maybe there's a lot of cache pressure on the router so it loses routes and the TCP times out? A better tool to have running would be ethereal
; tell it to only track packets to/from the server's IP address and the amount of data generated would be reduced significantly.
If it were also configured to write a circular buffer to a log file, the diagnosis could be done after-the-fact. When the connection drops, the packet capture could be turned off and a log of the most recent packets would be in the file. Setting the circular log size to 64K should be plenty -- roughly 40 packets, assuming they are all maximum size Ethernet packets...