Jump to content
Mumble forums

Frequent reconnects on low bandwidth line


dersquisher
 Share

Recommended Posts

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!

Link to comment
Share on other sites

  • Moderators

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

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

  • Moderators

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

Link to comment
Share on other sites

  • Administrators

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?

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...