Unforgiving net-code.
Moderators: dorpond, trevor, Azhrei
Forum rules
PLEASE don't post images of your entire desktop, attach entire campaign files when only a single file is needed, or generally act in some other anti-social behavior.
PLEASE don't post images of your entire desktop, attach entire campaign files when only a single file is needed, or generally act in some other anti-social behavior.
Unforgiving net-code.
We had a problem with one of our players dropping constantly during our game last Wednesday using 1.2b18. The dropped connection was only in MapTool (Skype kept going) and was only happening with the one player. We've had problems in the past like this in 1.1, but with the current beta the user wasn't able to log back in with the same name - even if I booted the name from my connections. He ended up logging in ever 5 minutes under Dave1, Dave2, Dave3 and just Dave depending on what had been released over time.
I guess it all boils down to needing a way for MapTool to maintain a persistent connection and handle reconnects gracefully when things get botched.
If any of the devs are interested in helping us debug this whole thing further, let me know and I'll set up a session with the player to run through some diagnostics.
I guess it all boils down to needing a way for MapTool to maintain a persistent connection and handle reconnects gracefully when things get botched.
If any of the devs are interested in helping us debug this whole thing further, let me know and I'll set up a session with the player to run through some diagnostics.
Did you have him do a tracert between his PC and the server? Maybe he had a lot of packet loss somewhere in between.
Would Skype be affected in a conference call setup? Not sure but I imagine that for a conference call all data goes to one (or more ) of their servers and then gets sent out to each client in the call.
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.
Would Skype be affected in a conference call setup? Not sure but I imagine that for a conference call all data goes to one (or more ) of their servers and then gets sent out to each client in the call.
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.
Hey guys, I'm the one having the connection issues. Not much more I can add at this point, though I'll run a traceroute when I get home and post the results (as well as JVM version). I'm on sbc dsl and haven't had an issue connecting before 1.2 (well it happened, but infrequently).
One more thing to add, when I would get disconnected, I got no disconnect message - all the icons and map would still be up. I suspect I just need to update Java, but we'll see.
Great tool btw, love the changes in 1.2 despite my connection issues
One more thing to add, when I would get disconnected, I got no disconnect message - all the icons and map would still be up. I suspect I just need to update Java, but we'll see.
Great tool btw, love the changes in 1.2 despite my connection issues
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).Phergus wrote: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.
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...
I have the feeling Shiftre's good for running most diagnostic tools and I can walk him through the process. Thanks for the tips on what to use.
We ended up with the same problems again last night and he mentioned that his traceroute to me timed out as well. I don't have his logs so I can't comment on it, but I'm sure he'll pop on in the next day or so to fill in the details.
We ended up with the same problems again last night and he mentioned that his traceroute to me timed out as well. I don't have his logs so I can't comment on it, but I'm sure he'll pop on in the next day or so to fill in the details.
That is probably all you need to know though if there is a flaky or overloaded router between him and you there won't be much you can do about it.ego093 wrote:We ended up with the same problems again last night and he mentioned that his traceroute to me timed out as well.
Might be useful to try a tracert from him to you at some other times. Try it in the morning, later in the day and at night.