I am trying to make a connection to a socket.io session. The connection is easily established, however, if I am idle for a short duration I get this error in my console:
websocket.js:116 WebSocket connection to 'ws://localhost:3000/socket.io/?EIO=3&transport=websocket&sid=PwzuR5tNmPmZfj0UAAAB' failed: WebSocket opening handshake timed out
I tried fixing the issue by setting pingTimeout and pingInterval but to no avail. I am not sure how to fix this or what is causing this.
On a side note, I am trying to read and understand the socket.io docs and am still not clear about what ping and pong packets exactly are. Does the client have to manually interact with the socketio server in order for it to receive pong packets or will it still receive pongs if say the client interacts with an http server on the same host ?
Related
I utilize Jetty (9.4.1) websocket for 2 ways communication between client and server.
On Client side, the messages 'onerror' and 'onclose' of WebSocket are listened, so that when there is a problem, the client will make a
new connection.
On Server side, the 'OnError' and 'OnClose' messages also handled.
Then, sometimes I see server got an 'org.eclipse.jetty.io.EofException', 'OnError' and 'OnClose' of ServerEndpoint are invoked. But on the Client side, there is no 'onerror' or 'onclose' message is sent.
Therefore, in this case the Client is not aware of the websocket connection is closed already, still use that connection.
My questions are:
1. How can this EofException happen?
2. When this error happen, is the connection actually close or still open? Because I cannot duplicate this error programmatically, I cannot investigate to understand clearly.
3. How can I make Client aware of this exception, so that Client can reconnect and function properly?
According to the Wikipedia article: http://en.wikipedia.org/wiki/WebSocket,
The server sends back this response to the client during handshake:
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol: chat
Does this close the connection (as HTTP responses usually do) or it is kept open throughout the entire handshake and it can start sending WebSocket frames straight away (assuming that it succeeds)?
An HTTP socket going through the handshake process to be upgraded to the webSocket protocol is not closed during that process. The same open socket goes through the whole process and then becomes the socket used for the webSocket protocol. As soon as the upgrade is complete, that very socket is ready for messages to be sent per the webSocket protocol.
It is this use of the exact same socket that enables a webSocket connection to run on the same port as an HTTP request (no extra port is needed) because it literally starts out as an HTTP request (with some extra headers attached) and then when those headers are recognized and both sides agree, the socket from that original HTTP request on the original web port (often port 80) is then switched to use the webSocket protocol. No additional connection on some new port is needed.
I actually find it a relatively elegant design because it makes for easy coexistence with a web server which was an important design parameter. And, a slight extra bit of connection overhead (protocol upgrade negotiation) is generally not an issue because webSocket connections by their very nature are designed to be long running sockets which you open once and use over an extended period of time so a little extra overhead to open them doesn't generally bother their use.
If, for any reason, the upgrade is not completed (both sides don't agree on the upgrade to webSocket), then the socket would remain an HTTP socket and would behave as HTTP sockets normally do (likely getting closed right away, but subject to normal HTTP interactions).
You can see this answer for more details on the back and forth during an upgrade to webSocket: SocketIO tries to connect using same port as the browser used to get web page
One of my app need socket connection.
I tested on nitrous.io, but their free account always close the socket connection if there is no signal between server and client more than 1 minute.
Just wonder if there is similar socket connection limitation on heroku?
Your comment welcome
Heroku has support for WebSockets, with the usual 30s timeout limitation. This can be easily worked-around by sending heartbeat packets.
https://devcenter.heroku.com/articles/heroku-labs-websockets
If I am not wrong, to have a push technology the client ( say browser ) also needs to run a small web server which is listening on some port ( say ijetty runs on 8080 ). Now when the actual server comes to know about any event, it sends the event to client. This way there is no PULL mechanism involved at all. Is this right ? OR there is a persistent connection involved and server sends the data on that connection whenever the event happens. My question is : in the former case ( if it is true ), how does server know about client's IP ?
WebSockets working with socket based on TCP connection, basically the client make a request for connection to the server with a challenge, websocket version, ip and more data, then the server decrypts the challenge and return his result back to the client, this process called Handshake.
If the handshake is approved, the connection is made, the socket connection remains open between the client and the server, heartbeats will be sent from the server to the client like a ping to check if the connection is still open.
read this wiki to find out more:
http://en.wikipedia.org/wiki/WebSocket
I have a webapp, which is running in a browser. That webapp is connected to a server, which uses websockets. So the communication between the server and my client/browser is based on websockets. If some magic event occurs on the server, some webservice sends a new XML / JSON to my webapp and the new data gets displayed.
But how do i, as the client / browser, know if the connection is stil alive? Lets say i do not get any new XML for about 30 seconds. How would i know if the connection is closed/broken/server offline or everything is fine, but on the server himself no new magic event occured.
A websocket connection object has a readyState field which will tell you if the connection is still active (from the dart documentation). The readyState can be either
0 - connection not yet established
1 - conncetion established
2 - in closing handshake
3 - connection closed or could not open
You can also define an event handler for the websocket close event if this is something you'd like to handle (try to reconnect, etc).
3 ways:
rely on TCP to detect loss of connectivity, which will ultimately pop up in JS onclose event
send WebSocket pings from server .. browsers will reply with WS pongs, loss of connectivity is probably more robustly detected also on client side
send app level heartbeats from browser to server, server need to have logic to reply. you can't trigger WS pings from browsers (in JS)