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.
Related
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 want to create a websocket server. I heard that socket.io is a good choice.
I tried socket.io with nodejs(v4.4.7) (npm install --save socket.io), using its sample server side code. A little confused why the client side code is using "http://" rather than "ws://" protocol, but after I setup a real server for testing, I found both "http//" and "ws//" will work using the official code.
Everything is fine till now. But soon I found I can't establish a connection using third-party online tester sites like:
1. www.websocket.org/echo.html
2. www.blue-zero.com/WebSocket
The connection seemed never established or closed asap connected,
I found "Firefox can't establish a connection to the server at ws://mytestserver:8888/?encoding=text" in Firefox console,
or "WebSocket connection to 'ws://mytestserver:8888' failed: Connection closed before receiving a handshake response" in Chrome console.
At last I changed socket.io to ws (npm install --save ws). using sample code from github.com/websockets/ws. all tester sites worked well.
(Of course, my final purpose is not to make a tester site work. the fact is the websocket lib based on nopoll integrated in my chip has exactly the same behavior as the tester sites.)
Anybody knows the reason why socket.io does not work with 3rd-party clients while ws does? Thanks a lot.
socket.io requires a socket.io server on the server-side end of things. It will not connect to only a webSocket server.
While socket.io uses webSocket as the underlying transport, it adds a layer on top of webSocket to implement a whole bunch of additional features and that requires server-side support for socket.io. So, you can't connect to a plain webSocket server with the socket.io client.
You must match:
webSocket client <==> webSocket server
socket.io client <==> socket.io server
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.
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.
We have a problem in our project using the node ws websockets library.
When the client looses network connection the only way to know that the client is disconnected is by sending a ws.ping() from the server. This is too resource consuming for us.
Does anybody know if there is a default way to get the ws server to use TCP level keepalives instead of using the ping/pong functionality?
Solved this by letting the client send a response when a message is received.