RPTools.net

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.

Interesting. I'll put this as a tracker for the 1.3 development cycle, get that beefed up.

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.

MT uses tcp for general communication and UDP for local server discovery. I might have you guys run a server some evening so I can connect and watch it happen. I'll also look at why the name conflict was happening.

Thanks for looking into this. I told him to sign up on the forums and jump into the conversation. Hopefully he'll be able to give you guys some better information than I can.

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

Welcome to the forums shiftre ! We'll get it working

Thanks

Ping times to rptools.net are fairly quick, about 19 hops at about 86ms avg ( not getting stuck anywhere). Still have to check the java version - we have our play session tonight so will run a few more tests then.

Ping time to rptools.net doesn't matter. You are interested in the path to your server.

The RPTools.net hookup is only for getting your client the servers IP address and port#. it isn't used after that.

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.

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...

Asking folks to run ethereal is probably a bit much. Your average user is going to take one look at the interface and run screaming the other way.

Probably would be better if MT had some optional diagnostic capability that could be turned on if it appear that there were connection issues.

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.

ego093 wrote:We ended up with the same problems again last night and he mentioned that his traceroute to me timed out as well.

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.

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.