dhbaird / easywsclient

A short and sweet WebSocket client for C++
MIT License
747 stars 204 forks source link

socket error Error: read ECONNRESET #11

Closed simonmorley closed 11 years ago

simonmorley commented 11 years ago

Hi David, was just about the start looking at the SSL stuff but we've run into this problem connecting to the Socket.io server... I'm trying to figure out whether it's the client, Socket.io or NodeJS.

I have raised an issue with Socket.io but I'm still not sure it's their side (see link 1). Struggling to debug it.

The problem only affects some clients, so we're trying to figure that too. It connects to the socket.io server ok, handshake done (I will document for you shortly).

However the first disconnect throws this error:

info  - socket error Error: read ECONNRESET
at errnoException (net.js:901:11)
at onread (net.js:556:19)

And doesn't clear the session properly (hence I thought it was node or socket.io). When you reconnect the client and disconnect again, you get this:

at Readable.on (_stream_readable.js:679:33)
at Transport.setHandlers (node_modules/socket.io/lib/transport.js:115:15)
at Transport.handleRequest (node_modules/socket.io/lib/transport.js:70:10)
at Transport (node_modules/socket.io/lib/transport.js:31:8)
at new WebSocket (node_modules/socket.io/lib/transports/websocket/hybi-16.js:59:13)
at new WebSocket (node_modules/socket.io/lib/transports/websocket.js:31:17)
at Manager.handleClient (node_modules/socket.io/lib/manager.js:662:19)
at Manager.handleUpgrade (node_modules/socket.io/lib/manager.js:618:8)

NodeJS needs to be restarted to accept a connection again.

Because we have most clients (Linux and Mac) working, I genuinely don't think it's client side. However, you're clearly a socket genius and was hoping you might have some thoughts?

-- EDIT --

We're actually getting this on some Ubuntu builds too.. Still trying to narrow it down..

  1. https://github.com/LearnBoost/socket.io/issues/1281
dhbaird commented 11 years ago

I'll dig into Socket.io and see if I notice what's happening. Have you opened up Wireshark, or had better luck with any other clients? The server should definitely not crash as a result of client poking, so that is likely bug-report worthy.

On another note, I've had pretty good luck with SockJS (rather than Socket.io). SockJS has server-side implementations for Node, Ruby, Python, Erlang, (and more, probably). I like the fact that SockJS is agnostic towards server platform (even though I do tend to just use Node anyways).

simonmorley commented 11 years ago

There's some reports that this is Node version .10 issue and the fix is to handle the error. Trying to find the root cause rather then handle server side.

We have tested on another mac and it works, no errors. They're using the g++ version 4.2.1. Both linux boxes are running 4.6.3. That's basically the only major difference. We have however compiled for the embedded device on their SDK in Ubuntu. Seems a little odd.

What are you building on?

dhbaird commented 11 years ago

Most recently, I build with g++ 4.7.3 in Ubuntu 13.04. My best guess is to use Wireshark to see if there is anything odd about data that makes the server hiccup, and then trace it back to the code/platform. I don't have any better ideas yet.

dhbaird commented 11 years ago

When disconnecting (the disconnect that throws the error), which side initiates the disconnect?

simonmorley commented 11 years ago

We'll get Wireshark out tomorrow.

Disconnect was done client side - ctrl-c and cable. Cable disconnect doesn't even get spotted server side...

dhbaird commented 11 years ago

Interesting. Just a thought, you could try calling ws->close() (which sends a WebSocket close frame, prior to closing the socket) and see if that narrows the issue down further.

simonmorley commented 11 years ago

Good plan. Will do later, have just walked out of office.

We downgraded g++ to 4.2.4 ( as clpse as we could get ) on Ubuntu. Same error so it's not that...

On 19 Jul 2013, at 18:26, David Baird notifications@github.com wrote:

Interesting. Just a thought, you could try calling ws->close() (which sends a WebSocket close frame, prior to closing the socket) and see if that narrows the issue down further.

— Reply to this email directly or view it on GitHubhttps://github.com/dhbaird/easywsclient/issues/11#issuecomment-21264106 .


The information contained in this email and its attachments is confidential and may be the subject of legal, professional or other privilege. It is intended only for the named addressees and may not be disclosed to anyone else without consent from PolkaSpots Limited. If you are not the named addressee you must not use, disclose, distribute, copy, print or rely on the contents of this email and should destroy it immediately. Whilst PolkaSpots Limited takes care to protect its systems from electronic virus attack or other harmful event, the firm gives no warranty that this email message (including any attachments to it) is free of any virus or other harmful matter and accepts no responsibility for any loss or damage resulting from the recipient receiving, opening or using it. If you need any further information, please contact the originator of this message on +44 (0) 20 7183 1471.

PolkaSpots Limited is registered in the UK, number 05508105. Registered Office: 62 Britton Street (behind the bike sheds), Clerkenwell, London EC1M 5UY

Website: polkaspots.com WiFi Shop: shop.polkaspots.com

Blog: polkaspots.com/blog

simonmorley commented 11 years ago

Home now, trying on another machine and it's connecting / disconnecting without errors... Ubuntu with 2.6.3 compiler.. Same as the broken one earlier. Will have to wait until Monday to test on a 'broken' device.

simonmorley commented 11 years ago

We have not really managed to narrow this down. This is what we have however discovered:

mac client on lo0 works fine ubuntu client on lo0 works fine mac client across network works fine ubuntu client across network does NOT work

Wireshark shows the same info between all devices. Earlier today we thought it was a network issue. Now we're not sure at all. In fact we're even more confused.

Going to drop socket.io back to version 8 and install NodeJS on another server..

simonmorley commented 11 years ago

It is without doubt an issue with NodeJS 0.10... Something to do with the way the socket is created. If we rollback to 0.6, all is happy.

I'll raise a bug with Node about this and update this if it gets resolved.

gagahjt commented 11 years ago

socket error Error: read ECONNRESET node: v0.10.15 socket.io :0.9.16

when using ie browser disconnected..

simonmorley commented 11 years ago

I don't know why you've commented on this when the problem is with node.. As per the post above, if you downgrade to 0.6, the problem with disappear.

We're working to find a fix in nodeJs

gagahjt commented 11 years ago

is nodejs v0.6 ? i will try ..thank u very much! I want to ask one other question ... using ie browser disconnected. how notice the server disconnect event .. there is a delay it?

simonmorley commented 11 years ago

Depend on how the session is terminated. And I believe on the browser too. A loss of connectivity will need you to use a heartbeat on socket.io

Is this question even related to easywsclient?

EvanCarroll commented 5 years ago

Blast from the past, but I'm still getting this on node v11.6

EvanCarroll commented 5 years ago

Here is how this problem is generated. It's generated when the client itself closes the connection with

ws = new WebSocket(`${baseURL}`);

And then

ws.close();

And then the server calls

wsServer.close();

Before it knows the connection is closed. In the case of a test-teardown that's common. In the client you have to set the error handler first

ws.on('error', () => {} );

now you can shut down the client and the server.