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.
Related
I created an OPC-UA server based on Node-OPCUA and node.js and several clients have wrong or empty parameters when connecting. This causes malfunctions on clients side.
Is it possible for server to override or correct the client configuration parameters so it works correctly even when the client is wrongly defined?
I am particularly interested in overriding session and connection timeouts.
Clients may disruptively disconnect, so the server does no close that connection. How do I get rid of those zombie connections? Sessions are usually closed due to timeout, but not connections.
You can't do that because it's again the OPC-UA protocol. The client should be able to open a connection with its own parameters.
If you detect that the client is wrongly configured you should throw a ServiceException instead.
I have a nodejs TLS client socket on my laptop, connected to a TLS server socket on a different computer (server). The server cannot connect to my laptop. The laptop needs to initiate the connection.
Now I want the server to make requests to my laptop. The idea is to reuse the HTTP protocol. Is there a way to create a HTTP server using the existing TLS client socket?
This way, the server machine can make a HTTP request, and the client TLS receives it, and the HTTP server would parse it? Or am I missing something?
Once you have a TCP socket open between laptop and server, you can send data either way over that socket. So, if the server wants to send some query to the laptop, it can do so just fine. You will have to invent your own protocol on top of TCP to do that, but it could be as simple as a text/line based protocol if you want.
Or, instead of making a plain TCP connection, you can make a webSocket or socket.io connection from the laptop to the server (instead of the plain TCP connection) and then either side can send messages either way and the protocol part is already taken care of. If you use socket.io, it will automatically reconnect if the connection is interrupted too.
There is no simple way to attach an HTTP server to an existing TCP socket and it would be fraught with difficulties too because an HTTP connection is generally not a continuous connection over which you send many separate requests (advanced versions of http can do that, but I doubt you want to get into implementing all that logic on both ends). You could use the HTTP protocol over your existing TCP socket, but that would probably be substantially more work to implement than just use the webSocket/socket.io idea above.
The Almond Plus router and home automation hub now exposes the state of its registered z-wave and zigbee sensors via a websocket.
The websocket API is here:
https://wiki.securifi.com/index.php/Websockets_Documentation
I've aimed a node-red websocket node at the router's local IP address, and have included authentication information in the URL. This seems to work for receiving status changes to devices.
But I need to also be able to send commands over the websocket to flip switches and whatnot. When I create both 'listen on' and 'connect to' websocket nodes in node-red, only the node that's listening connects. Do I need to make two nodes at all? I would have hoped there'd be a way to make one connection to the websocket and use it for two-way communication, but maybe this question just exposes my ignorance of how either websockets or node-red function.
Thanks for any help or information.
You should need both a Websocket in and a Websocket out, but both should be set to "connect to" mode. These handle the input and output side of the connection
I'd have to double check the code, but they should share the same client connection under the covers so there will only be one real Websocket connection. But even if the 2 nodes don't share the connection having 2 separate websocket connections to the same address shouldn't be a problem.
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.
I am developing a WebSocket service using NodeJS and Einaros WS module and I have raised this question: NodeJS Einaros WS Connection Timeout which apparently no one know the answer so I presume I should write my own ping pong based system to check whether a client is still connected or not.
I am not sure whether I should write code on server side or client side; I mean if the server should ping the client or... the client (which is my own websocket application) should ping the server.
Is there any difference between both methods ?
It is called a heartbeat and is usually sent by the client every 5 seconds with a ping frame (0x09) as opcode while the server responds with a pong frame (0xA) as opcode.
In theory it doesn't really matter whether it's the server or client initiating the heartbeat, but in a real-world situation it is usually better that the client keep itself updated whether the server is there or not to be able to inform the user as quickly as possible.