Frequent reconnects on low bandwidth line

[dersquisher]

Hi,

my friend lives in a smaller city and has a really crappy DSL line - about 50kb/s max, about double latency to those on decent DSL lines. If I ping the server on an idle line I get ~70ms avg.

He gets frequently disconnected from my mumble server. The log looks like this:

2011-01-08 23:38:12.468 1 => <77:(-1)> New connection: 84.174.74.116:50484

2011-01-08 23:38:12.825 1 => <77:(-1)> Client version 1.2.2 (Win: 1.2.2)

2011-01-08 23:38:12.827 1 => <77:baddsl(-1)> Authenticated

2011-01-08 23:38:31.716 1 => <77:baddsl(-1)> Requesting crypt-nonce resync

2011-01-08 23:38:59.713 1 => <77:baddsl(-1)> Requesting crypt-nonce resync

2011-01-08 23:39:06.356 1 => <77:baddsl(-1)> Requesting crypt-nonce resync

2011-01-08 23:39:43.690 1 => <77:baddsl(-1)> Requesting crypt-nonce resync

2011-01-08 23:39:50.722 1 => <77:baddsl(-1)> Timeout

2011-01-08 23:39:50.723 1 => <77:baddsl(-1)> Connection closed: [-1]

 

I read the sources and found an undocumented "timeout" setting. It is set by default to 30ms, which I think is rather low. Is there a reasoning behind such a default? I want to experiment so I increased the timeout to 300ms.

We haven't had a chat since I changed the timeout on the server side, so I don't know yet if it makes a difference. But I'm also concerned about the crypto resync. Is there something I change so that the crypto doesn't bail out so quickly?

Thanks in advance for any help!

[pcgod]

The server requests a crypto resync if it couldn't decrypt the packet received from the client which is often caused by lost or very late packets and the timeout option is multiplied by 1000 so the default timeout is 30 seconds which should be long enough (30ms wouldn't work because ping packets are sent every 5 seconds...).

[dersquisher]

I was looking at the 1.2.2 release.

Server.cpp:1151

                if (u->activityTime() > (iTimeout * 1000)) {

 

Timer.cpp:38

quint64 Timer::elapsed() const {
       return now() - uiStart;
}

 

Timer.cpp:77

quint64 Timer::now() {
       struct timeval tv;
       gettimeofday(&tv, NULL);
       quint64 e= tv.tv_sec * 1000000LL;
       e += tv.tv_usec;
       return e;
}

 

Seems to me like the timeout * 10000 is compared to microseconds. I do admit 30ms seems like it would not work out in practice, but please point out where I'm not reading the code correctly.

Thanks!

[pcgod]

The activity timer is not using the Timer class, it's using QTime in 1.2.2 (and QElapsedTimer in 1.2.3 if you're using Qt 4.7.0 or higher) and the documentation of QTime::elapsed() (http://doc.qt.nokia.com/4.7/qtime.html#elapsed) says "Returns the number of milliseconds that have elapsed since the last time start() or restart() was called.".

[dersquisher]

Ah, thanks for pointing out my mistake.

Unfortunately that leaves me with nothing - are there no settings I can tune? Can't I make the crypto a bit more forgiving, or maybe even turn it off?

Thanks!

[kissaki]

No. Encryption is mandatory, always enabled.

And the whole point of encryption is that it is encrypted and secure.

A crappy bandwidth and ping shouldn’t be a problem, as long as the (important) stuff does get through. Dunno what the problem with your friends connection is. Packet loss?