Error: write ECONNRESET

[edgarpochtel]

Hello!

Nice work so far.
Unfortunately I get the following error after a while:

      throw er; // Unhandled 'error' event
      ^

Error: write ECONNRESET
    at _errnoException (util.js:992:11)
    at Socket._writeGeneric (net.js:764:25)
    at Socket._write (net.js:783:8)
    at doWrite (_stream_writable.js:397:12)
    at writeOrBuffer (_stream_writable.js:383:5)
    at Socket.Writable.write (_stream_writable.js:290:11)
    at Socket.write (net.js:707:40)
    at throttle.run (D:\*\node_modules\teamspeak-q
uery\index.js:85:19)
    at Map.run (D:\*\node_modules\teamspeak-query\
lib\throttle.js:48:7)
    at TeamspeakQuery.checkQueue (D:\*\node_module
s\teamspeak-query\index.js:80:19)

[frct1]

Hello @edgarpochtel. Seems your host with server query interface is unreachable.
And do you enable keep-alive feature ?

[edgarpochtel]

Hey.

Yes, I have.

See:

var ts = new tsquery(ts_connection.tsip, ts_connection.ts_query_port);
ts.sock.setKeepAlive(true);
ts.keepalive.enable();
ts.throttle.set('enable', false);

ts.send('login', ts_connection.ts_query_admin, ts_connection.ts_query_password)
.then(() => ts.send('use', 1))
.then(() => console.log('Connected!'))
.catch(err => console.error('[TS-Query] Error:', err));

[schroffl]

ECONNRESET means that it could connect, but the established connection got closed by the other side, which is your Teamspeak server.

• Did you configure the black-/whitelist?
• Are you connecting from the outside or is everything in the same network (or even only your machine)?

[edgarpochtel]

Hi!

It's the same network and the ip (local too) is on the whitelist.
I use the connection information for multiple use cases, could this be the reason?

[frct1]

@edgarpochtel you can connect 200 Server Query users per one TeamSpeak 3 instance.

[edgarpochtel]

Ok. Good to know. Thank you. I use it only 3 times.

[schroffl]

Which version of the package are you running? And if it's a newer one, are you using ssh?

[edgarpochtel]

Im running version 2.1.1. I just upgraded the version to 3.0.0 an will test it.

I'm not using SSH.

Thank you so far for your help.

[frct1]

@schroffl ssh is slower (difference is visisble from 200 commands / second ), but more safety

[edgarpochtel]

No changes after upgrading on 3.0.0. But it seems that it need more time to crash.
Same error as posted.

[frct1]

@edgarpochtel I've upgraded yesterday from 2.? and all is ok. Some fixes in class but all is ok.
Check network setting on your host with teamspeak.

[schroffl]

What happens if you execute the following command? As far as I know it should work on Windows, Linux and MacOS:

telnet 127.0.0.1 10011

[edgarpochtel]

Hi.

Screenshot telnet command

[schroffl]

Huh, that is weird. Could you please try this piece of code, which is basically the one you sent, but with a few things left out:

var ts = new tsquery(ts_connection.tsip, ts_connection.ts_query_port);

ts.send('login', ts_connection.ts_query_admin, ts_connection.ts_query_password)
.then(() => ts.send('use', 1))
.then(() => console.log('Connected!'))
.catch(err => console.error('[TS-Query] Error:', err));

[edgarpochtel]

Actually I added

ts.sock.setKeepAlive(true);
ts.keepalive.enable();
ts.throttle.set('enable', false);

afterwards the nodejs application crashed. But I will try it with the 3.0.0 version and will provide new information tomorrow.

[edgarpochtel]

Hello again!

I removed the three lines from my last post.
Now it needs about 3-5 days dto crash. So the script have a longer running time.
But the error from the start post is still there. :/

[schroffl]

Edit: I just noticed that this post might be is complete bogus.
Because the timer on the server gets reset every time we send a command, the shift of the setTimeout calls doesn't sum up to one large delay, but gets reset as well.

Huh, I will just keep thinking and hopefully make out what is going on.

Though if you want to, we can still try my suggestion with the fix (which might not even be the fix).

---

Original Text

I could imagine that the deviation from the successive setTimeout calls eventually accumulates to a large enough delay to not send the keepalive-command in time.
Assuming a shift of 5 milliseconds every time the keepalive is run, a simple calculation [1] leads us to 1.44s of delay per day. After 3 days it reaches 4.32s. It could very well be that the server closes the connection in this time window.
It was naive of me to use a simple setTimeout for long-running, timing-critical operations, I guess. Maybe it's not even the problem, but I strongly suspect so.
Besides, the use of a timeout (for exactly that reason) bugged me since the addition of the keepalive anways.

I will aim to publish a potential fix in the next days.
Could you then test it again? I would be really grateful, since it is not too easy for me to replicate your conditions with a server running for multiple days.

---

[1] I hope I did the math correctly, here is the formula I used. Also keep in mind, that x is varying and probably below 5ms most of the time, but it should be close enough.

// d ~ Time between keepalives in minutes (Default is 5)
// x ~ Our approximated time shift in seconds (in the case above: 0.005)
// t ~ Number of days
24 * 60 / d * x * t

[schroffl]

I have another idea: Did you change the query_timeout option of your server?
Can you please try to set the keepalive-interval to something lower? If you haven't changed it, update it to 4 minutes instead of 5 (which is the default for the server and this library).

query.keepalive.setDuration(240);

Maybe the keepalive misses the countdown of the server by a few seconds (or even milliseconds). When you set it to 4 minutes there is more than enough margin to not have that happen.

And if this does the trick, I'm going to lower the default keepalive interval.

[edgarpochtel]

I don't thinkt that I changed the query_timeout option. I actually don't know how.
I added query.keepalive.setDuration(240); anyway to test if it helps. I will provide new information. Thank you a lot for your help!

[edgarpochtel]

It's now a week and the script is running without crashes. So, it could be, that your solution worked for me.
If something is chaning I will get again in touch with you. Thank you!

[schroffl]

Alright, I'm going to adjust the default timeout then.
Really glad to hear that it finally worked out :)

[schroffl]

The fix from 294527e is published in Version 3.0.1