ncr/node.ws.js

Server dying ECONNRESET

remy opened this issue · 13 comments

remy commented

I'm getting a rather unuseful error when the server dies:

Error: ECONNRESET, Connection reset by peer
    at IOWatcher.callback (net:326:21)
    at node.js:204:9

I've written a simple pass-through server: http://gist.github.com/431369 so I can't see anything particularly special causing me errors.

Any ideas or suggestions on how I help can debug it?

remy commented

Few more examples more examples of the error I'm getting:

events:11
        throw arguments[1];
                       ^
Error: EPIPE, Broken pipe
    at Stream._writeOut (net:627:22)
    at Stream.flush (net:684:24)
    at IOWatcher._doFlush [as callback] (net:268:14)
    at node.js:204:9
events:11
        throw arguments[1];
                       ^
Error: ECONNRESET, Connection reset by peer
    at IOWatcher.callback (net:326:21)
    at node.js:204:9
ncr commented

Does the server die without any apparent reason? What client do you use to connect to it? (fresh ff and chrome have updated implementations - I'll be updating node.ws.js to reflect that soon)

remy commented

I'm accessing it using Chrome 5.0.375.55 - but it's also open to the general public so it could be any browser.

Generally it works fine, but it does regularly go down. I'm currently using it for the server side of this hack I build: http://rem.im/collab-drawing and I found when it became more popular it would fall over ('disconnect' would show in the title).

I've currently wrapped the server in a while loop, so if it goes down, it comes straight back up again.

My gut feeling is that it's to do with packet size - if you try sending a message around 30K it'll keel over - but I can't be completely sure... Sorry, bit vague!

ncr commented

My gut feeling tells me something similar - it seems like it's a problem with nodejs itself. It also tells me that I need tests for my little server, mainly to test if it works with the ever-changing current version of node :) Which version of node do you use? I could take a look at the source code - the failing part is in js so quite readable.

remy commented

I'm on 0.1.97

ncr commented

All tracks seem to be leading to C sources in nodejs, effectively making me unhelpful ;) It seems that when connection is broken, then two functions throw exceptions and these exceptions are not transformed into error events on js side: read and write (node_net.cc: #484, #601). Can't really tell anything more...

remy commented

Is there any chance that you could log these C errors on the Node project? I see Web Sockets as a great way of getting real time data out, and so far your micro-library is the simplest and most stable, but I wouldn't know exactly what to say if I logged the bugs myself.

ncr commented

Have you maybe tried to reproduce the bug against current master?

nchapman commented

I'm experiencing the same issue using nodejs 0.1.99 and Safari 5 on Windows 7. Safari 5 on the Mac causes no such issue. Anyone have any additional insight on handling this problem?

ncr commented

I would appreciate such insight too. I don't have any Windows nearby...

nchapman commented

ncr, this seems on point:

http://github.com/ry/node/issues/issue/174

It looks like we at least need to be able to add a listener for "error". I hard coded one onto the socket in ws.js that would just write the error to sys.log, and it at least keeps node.js from crashing. I know this doesn't fix the specific problem, but it would at least allow us to handle it more gracefully in the meantime.

ncr commented

Thank you Nick! Could you send me a pull request?

ncr commented

Closing this