Losing connections to Vassal server

[palad0n]

As evinced by many posts over the years, many people have problems with frequent lost connections to the vassal server. In nearly all discussions, the most often cause cited is that the user has an issue, it is not a vassal server issue.

But could the server actually be the real issue?

What are the server's KeepAliveTime, KeepAliveInterval, TcpMaxDataRetransmissions and (possibly) the TcpTimedWaitDelay registry settings? The first may be set too low; sort of understandable given that we do not a lot of inactive connections clogging the server.

If these are not manually set, the default values should be adequate, although 2 hours for KeepAliveTime may be too long.

Just asking the question as I would be interested in the data output.

[TsukudaJoe]

Yesterday I suddenly started getting a "lost connection to server" message. It was working fine the day before and I am not aware of any updates or changes to my system in the meantime.

Any ideas or fixes out there? I haven't been able to figure it out. I have spoken with other vassal users on the x-wing module and no one else appears to be having any trouble.

[uckelman]

Try one of the test builds named "VASSAL-3.3.0-svn9451-connection_test", available here:

http://www.vassalengine.org/~uckelman/tmp/

Do you still have connection problems with that?

[uckelman]

Thus spake palad0n:
> As evinced by many posts over the years, many people have problems with
> frequent lost connections to the vassal server. In nearly all
> discussions, the most often cause cited is that the user has an issue,
> it is not a vassal server issue.
>
> But could the server actually be the real issue?
>
> What are the server's KeepAliveTime, KeepAliveInterval,
> TcpMaxDataRetransmissions and (possibly) the TcpTimedWaitDelay registry
> settings? The first may be set too low; sort of understandable given
> that we do not a lot of inactive connections clogging the server.
>
> If these are not manually set, the default values should be adequate,
> although 2 hours for KeepAliveTime may be too long.

I'm not sure what you're talking about here---the fact that you mention
the registry makes me think you're referring to a Windows machine?

On Linux, in /proc/sys/net/ipv4 I see:

tcp_keepalive_time = 7200
tcp_keepalive_intvl = 75
tcp_keepalive_probes = 9

My understanding is that these are more for detection of dead connections
rather than for actually keeping connections alive.

The test build I mentioned above contains an application-level keep-alive:
It send out an empty message two minutes after the previous message has
gone out, to keep the connection open. (I'm not a networking expert by
any stretch, but this is similar to what ssh does for keeping idle
connections from being closed by hostile things like routers using NAT
and such.)

--
J.

[palad0n]

7200 is 7.2 seconds, assuming it follows normal convention of being based on milliseconds. As vassal sever disconnects seem to occur around the 5 minute mark, I guess we can discount the server. Oh well, it was worth a thought.

[palad0n]

I will try the test build as well and advise. Thanks.

Being developmental software, may I assume that you would like any bug reports that I may encounter?

[jrwatts]

tcp_keepalive_time is in seconds, not milliseconds (according to this blog, at least).

[uckelman]

Thus spake palad0n:
> 7200 is 7.2 seconds, assuming it follows normal convention of being
> based on milliseconds. As vassal sever disconnects seem to occur around
> the 5 minute mark, I guess we can discount the server. Oh well, it was
> worth a thought.

No, both of those values are in _seconds_, so that's 2 hours.

--
J.

[uckelman]

Thus spake palad0n:
> I will try the test build as well and advise. Thanks.
>
> Being developmental software, may I assume that you would like any bug
> reports that I may encounter?

Yes, that would be appreciated.

--
J.

[palad0n]

No bugs to report. But happy news. The mod does solve the disconnection issue. I loaded up a game online and just left it alone for an hour or so. Remained connected. Yeh ha. Noting that in normal use my period of apparent inactivity is far less than that.

Well done Sir. Be proud of your accomplishments.

Do I need to now reinstall 3.2.17, or can I continue with the beta version and still play games with those on 3.1.17 - in particular those using my module made in the 3.2.17 version?

While I follow with interest the 3.3.x development (and ver 4 as well), I am probably uncomfortable with continuing refinement of my module in the 3.3.x environment in lieu of the 3.2.17 version. Or are my 'fears' totally unfounded? But can the mod for preventing untimely disconnection be added to 3.2.17 before the release of 3.3.x?

To reiterate, many thanks.

[uckelman]

Thus spake palad0n:
> No bugs to report. But happy news. The mod does solve the disconnection
> issue. I loaded up a game online and just left it alone for an hour or
> so. Remained connected. Yeh ha. Noting that in normal use my period of

Good to hear. Thanks for confirming.

> Do I need to now reinstall 3.2.17, or can I continue with the beta
> version and still play games with those on 3.1.17 - in particular those
> using my module made in the 3.2.17 version?

The only incompatibility between 3.2.17 and the 3.3.0 builds (to date) is
that 3.2.17 won't open modules written by 3.3.0---and this is only because
there's a version check in 3.2.17, not because modules writtren by
3.3.0 woudn't work.

Saved games and logs written by 3.3.0 builds will work just fine in 3.2.17
so long as the module they're for is loadable by 3.2.17.

> While I follow with interest the 3.3.x development (and ver 4 as well),
> I am probably uncomfortable with continuing refinement of my module in
> the 3.3.x environment in lieu of the 3.2.17 version. Or are my 'fears'
> totally unfounded? But can the mod for preventing untimely disconnection
> be added to 3.2.17 before the release of 3.3.x?

If we modify 3.2.17, it's not 3.2.17 anymore. We'd have do do a 3.2.18
release, which would be a huge waste of time when we're so near to
releasing 3.3.0.

I expect to release 3.3.0-beta4 in the coming week, and 3.3.0 sometime
later in June, assuming that we don't get new bug reports for beta4.
Once 3.3.0 is released, the answer to any question regading 3.2.17 will
be "ugprade do 3.3.0", so I expect to see 3.2.17 fall out of use fairly
quickly thereafter.

--
J.

[marktb1961]

This may have fixed an obscure buffering issue which I experience (almost uniquely amongst regular co-players). It occurs at least once in almost every long game - opponents output stalling for 30-90 seconds and then being received at my end all at once. In two long games since I installed the test VASSAL-3.3.0-svn9451-connection_test I don't recall getting it once. Maybe I am too optimistic.

[uckelman]

Thus spake marktb1961:
> This may have fixed an obscure buffering issue which I experience
> (almost uniquely amongst regular co-players). It occurs at least once in
> almost every long game - opponents output stalling for 30-90 seconds and
> then being received at my end all at once. In two long games since I
> installed the test VASSAL-3.3.0-svn9451-connection_test I don't recall
> getting it once. Maybe I am too optimistic.

It's possible that sending keep-alive messages could fix a variety of
network problems. Among other things, NAT is fairly hostile toward
idle connections and most people are behind NAT when they're at home
these days.

--
J.