How do I handle a socket.io client when the socket.io server is unavailable? Currently when the socket.io server is unavailable the client site is also unavailable. Is there a way to use try/catch to handle situations where the server is not available?
Per the doc, there are events for connect_error, connect_timeout, reconnect_error and reconnect_failed. If you listen to all these error messages you will see when the client is unable to connect to the server.
socket.io does not throw exceptions for connection issues because they are all async issues so they need to be communicated back via messages/events.
Related
I'm new in socket-io. socket-io working fine but keep sending connect request infinitely to server.
Here is my client ts :
private url = environment.socketServer;
constructor() { this.socket = io(this.url) }
The usual reason for a socket.io client to try to connect over and over is if the socket.io version on the server and client are not compatible. The client connects, the server finds the version is incompatible and drops the connection and the client then tries to connect again, over and over.
Other possible issues:
Server infrastructure (such as load balancers, proxies, firewalls, etc...) are not properly configured to allow webSocket connections.
You're trying to connect to a cluster, but it isn't configured for sticky connections that will "bind" a socket.io client to the same server.
You're confused about how a socket.io connection starts. It is normal for the client to start with a couple web connections in a row (polling) until it realizes that both sides support a webSocket and then socket.io switches over to webSocket.
I am trying to create a multi room chat application in node.js using socket.io and express. I am confused between use of server port and websocket port. I understand server port is used by the client to connect to server. But not sure about use of websocket port.
Thanks & Regards..
webSockets can share the same port as your web server and this is a common configuration. The reason this works is because of how a webSocket establishes a connection (all webSocket connections are initiated with an HTTP request). It works like this:
Client makes an HTTP request to a web server with a header specifying that they want to "upgrade" to the webSocket protocol and sends a security-related header.
Web server sees the upgrade request and, if it has support enabled for webSocket connections, it will respond with a 101 request (switching protocols) and another security related header.
Client gets the accepted upgrade and both ends switch to the webSocket protocol and the original TCP socket that started out using the HTTP protocol is now using the webSocket protocol.
In this manner, the same port and webServer can be used for regular HTTP requests or webSocket connection requests.
For a chat application it is common to use a webSocket connection because it is a continuous connection that more easily allows the server to send information directly to the client which is often needed in a chat application.
To understand more about how a webSocket connection and server work, see this reference on MDN: Writing WebSocket servers which shows the step by step process for initiating a webSocket connection.
Server socket is used by server... that keeps listening to coming sockets request in a loop... and websocket sends a request to server socket and bound a connection between two devices...
If you have / want to have web clients, WebSocket is going to be required, because there is no access to 'regular' TCP (or UDP) sockets from browser-based JavaScript (and I assume you do not want Flash, SilverLight or Java Applets, in 2017). WebSocket is not special because of the port number, but it is special because of the protocol: a WebSocket connection starts as a regular HTTP connection, and protocol upgrade reconfigures it afterwards, it is designed for the browser-world, and even capable of traversing HTTP proxies. After establishing the connection, it provides a full-duplex, bi-directional message stream, very usable for chat applications.
And because of being a Web-thing, you could simply use port 80, if you are allowed to.
I get an issue using socket.io.
My code : var socket = io.connect('SUBDOMAIN.DOMAIN.fr');
Response error :
WebSocket connection to
ws://SUBDOMAIN.DOMAIN.fr/socket.io/?EIO=3&transport=websocket&sid=u2V-6uOMZrBtnCK5AAAH
failed: Error during WebSocket handshake: Unexpected response code:
503
My SUBDOMAIN.DOMAIN.fr is a type A domain.
What this actually means is that the environment hosting your socket.io service is not WebSocket enabled.
When socket.io first establishes a connection it will use long-polling, once connected, it then attempts to upgrade the connection to using WebSocket. If your hosting environment doesn't support WebSocket then you will see this message. It doesn't prevent socket.io from working it simply means it attempted to upgrade to WebSocket as the transport but failed. Now, if you explicitly state that socket.io should only use WebSocket, then your connection will not work.
An example would be IIS 7.5 or below. WebSocket isn't supported in IIS until version 8.0, so anyone using socket.io in an IIS 7.5 or below environment would see this message every time a connection is established.
This is discussed in the Engine.io Goals & Engine.io Architecture.
Engine.io is what socket.io is built on top of.
I have an app on heroku that uses socket.io for server-client communication. Everything is working just fine. However, once I scale my app to more than 1 dyno, I get several http request errors:
can't establish a connection to the server at wss://***/socket.io/?EIO=2&transport=websocket&sid=Hky6IHdckNADdU_tAACm. socket.io.js:4520
The connection to wss://***/socket.io/?EIO=2&transport=websocket&sid=Hky6IHdckNADdU_tAACm was interrupted while the page was loading. socket.io.js:4520
can't establish a connection to the server at wss://***/socket.io/?EIO=2&transport=websocket&sid=kWymv6ItJHBcUybZAAAA. socket.io.js:4520
The connection to wss://***/socket.io/?EIO=2&transport=websocket&sid=kWymv6ItJHBcUybZAAAA was interrupted while the page was loading. socket.io.js:4520
As well as a load of
HTTP status 400
{ code: 1, message: "Session ID unknown" }
My socket.io is using the redis adapter, so the state should be shared correctly. I kind of verified this by connecting to redis and issuing the following command:
PSUBSCRIBE socket.io#*
Since I can see data traveling back and force on this channel, I am assuming my socket.io redis adapter is working fine.
Anyone know how to make socket.io work on heroku with more than 1 dyno?
You need sticky load balancing. Socket.io has a great article on it, so I'll leave it to them to explain the topic:
https://socket.io/docs/using-multiple-nodes/
As socket.io said, it supports WebSocket, so, I use HTML5 standard web socket api to access socket.io server, but I always get below error:
WebSocket connection to 'ws://localhost:8080/' failed: Connection
closed before receiving a handshake response
Then, I tried to use socket.io client in js to access socket.io server, it works, and by chrome network monitoring, i found it using web socket protocol correctly.
Did anyone ever try W3C Websocket api to access socket.io server and met similar issue? or any ideas or clues for my problem? appreciated!
Test code is here: https://github.com/piginzoo/socketiotest
Note: Socket.IO is not a WebSocket implementation. Although Socket.IO indeed uses WebSocket as a transport when possible, it adds some metadata to each packet: the packet type, the namespace and the ack id when a message acknowledgement is needed. That is why a WebSocket client will not be able to successfully connect to a Socket.IO server, and a Socket.IO client will not be able to connect to a WebSocket server (like ws://echo.websocket.org) either.
And I find this in socketio github issues:
Socket.IO is not a WebSocket server. Please see ws instead.
https://github.com/socketio/socket.io/issues/3022
The error message you got was because you used the wrong url. The error message "Connection closed before receiving a handshake response" actually told you this (not receiving a response)
It should be 'ws://localhost:8080/socket.io/?EIO=3&transport=websocket'
Check here https://socket.io/docs/client-api/#With-custom-path & https://socket.io/docs/internals/ for details
e.g.
"EIO=3" # the current version of the Engine.IO protocol
BUT as other answer said and actually that was what socket.io readme said
Although Socket.IO indeed uses WebSocket as a transport when possible, it adds some metadata to each packet: the packet type, the namespace and the ack id when a message acknowledgement is needed. That is why a WebSocket client will not be able to successfully connect to a Socket.IO server, and a Socket.IO client will not be able to connect to a WebSocket server.
I have tested that to verify both ws & browser native Websocket can't not connect to a Socket.IO server. They are both immediately disconnected from Socket.IO server after they connects, with Socket.IO server send out the error message socket id xxx has disconnected with reason parse error
The ws author also mentioned here https://github.com/websockets/ws/issues/1390
using plain WebSocket to talk with a Socket.IO server does not work seamlessly.
If you want to use browser native Websocket you can use ws can server.
We had exactly the same problem. Ended up with ws websockets. Not sure may be there is better solution.