I know that the socket.io client library will close the current socket.io connection (and then attempt to reconnect) if it is not regularly receiving a response to the ping packets that it sends to the server (under the assumption that the connection has died for some reason). And, there are client options for controlling this reconnect behavior.
But, what happens server-side if a client goes inactive and stops sending ping messages (say because the client went to sleep)? I can't find any info in the socket.io server-side doc that explains that situation or allows for configuration of it. Will the server close an inactive client socket.io connection (one that it is not receiving ping messages from)? If so, how long will the server wait and is that behavior configurable?
As per the socket.io 2.20 readme (the latest version as of Jan 2020):
"A heartbeat mechanism is implemented at the Engine.IO level, allowing both the server and the client to know when the other one is not responding anymore.
That functionality is achieved with timers set on both the server and the client, with timeout values (the pingInterval and pingTimeout parameters) shared during the connection handshake."
So, you can configure both the server and client side timeout settings by setting the following timeout properties on the engine.io component inside of socket.io.
Using socket.io version 2.20:
const io = ...; // initialize socket.io how you wish
io.eio.pingTimeout = 120000; // 2 minutes
io.eio.pingInterval = 5000; // 5 seconds
The same thing using older versions of socket.io:
const io = ...; // initialize socket.io how you wish
io.set('heartbeat timeout', 1200000);
io.set('heartbeat interval', 5000);
Disconnection detection
The Engine.IO connection is considered as closed when:
one HTTP request (either GET or POST) fails (for example, when the server is shutdown)
the WebSocket connection is closed (for example, when the user closes the tab in its browser)
socket.disconnect() is called on the server-side or on the client-side
There is also a heartbeat mechanism which checks that the connection between the server and the client is still up and running:
At a given interval (the pingInterval value sent in the handshake) the server sends a PING packet and the client has a few seconds (the pingTimeout value) to send a PONG packet back. If the server does not receive a PONG packet back, it will consider that the connection is closed. Conversely, if the client does not receive a PING packet within pingInterval + pingTimeout, it will consider that the connection is closed.
The disconnection reasons are listed here (server-side) and here (client-side).
pingTimeout (Number): how many ms without a pong packet to consider the connection closed (60000)
pingInterval (Number): how many ms before sending a new ping packet (25000)
https://socket.io/docs/v4/server-api/
https://github.com/socketio/engine.io#methods-1
On socket.io 2.20. This can be set when, initializing socket.io
const io = require("socket.io")({pingTimeout: 10000, pingInterval: 30000});
See all options and their defaults here
Related
// client.js
const webSocket = new WebSocket('wss://127.0.0.1:8081');
webSocket.addEventListener('open', (message) => {
alert(message);
})
const text = document.getElementById('text');
const button = document.getElementById('button');
button.onclick = () => {
webSocket.send(text.value);
}
// server.js
import { Server } from 'net';
const server = new Server();
server.on('connection', (socket) => {
console.log(socket);
socket.on('data', (data) => {
})
});
server.listen(8081, '127.0.0.1', () => {
console.log('Server running at port 8081');
});
The problem that I'm facing is:
When I load the page the socket is printed in the console of the server (I can get the remote address and remote port)
No matter what I do, the connection in the client is always pending. I tried Chrome, Brave, Mozilla and Safari and no one seems to work.
What am I missing? I tried to not send the message until the connection is ready, but I never get that state in my PC. The alert in the client never pops, even if I establish the onopen property without an event.
Uncaught DOMException: Failed to execute 'send' on 'WebSocket': Still in CONNECTING state.
at button.onclick
A webSocket client must connect to a webSocket server. webSocket is a specific connection algorithm (that starts with an http request and then switches to the webSocket protocol) and a specific data format. So, a webSocket client must have a webSocket server to connect to. Your server is a generic TCP server that does not support webSocket connections.
The client will initially establish a TCP socket to your server, then send an http request over that socket, and then it will sit there waiting for an appropriate response to the http request it sent. Since your server never sends that response, it will just sit there waiting until eventually it will timeout and close the socket. This is why you see it stuck in the pending state. It's still waiting for the rest of the webSocket connection sequence to happen and it never does.
If you're curious how the webSocket connection scheme and data format work, you can see a nice description of it here.
Relevant StackOverflow answers:
How does WebSockets server architecture work?
What's the difference between WebSocket and plain socket communication?
Do websocket implementations use http protocol internally?
Overview of webSocket connection scheme
How WebSocket server handles multiple incoming connection requests?
I want to have an HTTP server which allows me to establish a TCP connection with a remote computer whenever I specify a given path inside the URL in a browser.
For example... let's say that I have a computer with a public IP address and a hostname as the server (mydomain.com:9000) and a remote computer with a local IP address (192.168.0.1) connected to the server. Somehow I want to establish a TCP connection between a client and the remote computer. And to make it easier just enter an URL with a path (mydomain.com:9000/remote). NOT WITH ANOTHER PORT! Also, I want the connection to be done if and only if that path is entered.
To illustrate a little better how the system works:
_________ _________ _________
| | internet | | local network | |
|_______| ----------> |_______| ----------> |_______|
____|____ <---------- ____|____ <---------- ____|____
client server remote computer
sends http request checks path gets http request
mydomain.com:9000/remote establishes TCP connection handles request
I made some code with node js to make sure that the connection was possible. And it is, now I only have to be able to check the path and establish the connection only then. My code is a simple TCP tunneling proxy and it works fine. But when I try to implement the path it doesn't.
//Import modules
const net = require('net');
const http = require('http');
let inpath = false;
// Create proxy server
const proxy = http.createServer( function(req,res){
console.log(req.url);
//Check path
if(req.url == '/remote')
inpath = true;
});
proxy.on('connection', client => {
if(inpath)
{
const remote = new net.Socket();
//Establish connection
remote.connect(80,'192.168.0.100');
client.on('error', err => {
console.log('Error: ' + err);
proxy.close();
});
//Port-forwarding
client.pipe(remote);
remote.pipe(client);
}
});
proxy.listen(9000);
Is there a way to do this?
In your code, you'll find that the connection event is firing well before your request handler callback is being called. This is because a TCP connection (for which the connection event is triggered) occurs from a client connecting before the client makes its HTTP request. Additionally, what you have isn't really going to work reliably because HTTP keep-alive may mean that multiple requests will come down a single TCP connection.
To fix this, you need to move all of that code you have in your connection event up to your HTTP request handler.
You'll run into other problems though, in that now your code is effectively handling the HTTP request/response, so you'll need to parse and rebuild the request/response data when communicating with the upstream server.
If you truly do wish to handle this at the TCP level, don't use http.createServer(). Use net instead and create a normal TCP server. Then, parse the request data yourself and if you find the certain path you want in the request, make the proxying TCP connection, and be sure to send down the existing buffers so that the upstream server can get the full HTTP request.
I use node.js(restify) and request module(https://www.npmjs.com/package/request).
My node server is proxy and request to other server.
I want to set socket timeout and read timeout each.
like clientSocket.connect / clientSocket.setSoTimeOut in java.
But request module document give "timeout" only.
Can i set socket timeout and read timeout another value?
It doesn't appear that you can. From the documentation:
timeout - Integer containing the number of milliseconds to wait for a server
to send response headers (and start the response body) before aborting the
request. Note that if the underlying TCP connection cannot be established, the
OS-wide TCP connection timeout will overrule the timeout option (the default
in Linux can be anywhere from 20-120 seconds).
So for the actual connection timeout you're relying on the OS. If you have that under your control you could change that if need be.
If you want the control you're looking for you could always use the clients that come with restify. For instance, the documentation for the JSON client shows these options:
connectTimeout Number Amount of time to wait for a socket
requestTimeout Number Amount of time to wait for the request to finish
Edit: I'm sending data from app A to app B over web socket, where A is a router app for something else, and B is my web app. When B receives the data, it should send it to any client viewing its home page, also over web socket. But, since the roter app and the home page clients are connected to the same web socket server, I don't know which connections are to the clients viewing the home page, and which connections are to other stuff, like my router. Only the home page clients should receive the data.
I basically want to pass the logging data recieved from my router to my home page in real time so I can view it.
========
I have an express app that server a simple html page. It runs this script:
var host = window.document.location.host.replace(/:.*/, '');
var ws = new WebSocket('ws://' + host + ':5000');
ws.onmessage = function (event) {
console.log(JSON.parse(event.data));
};
In the nodejs backend, I have a simple ws server running, listening for connections:
var WebSocketServer = require("ws").Server;
module.exports.init = function(server) {
var wss = new WebSocketServer({ server: server });
wss.on('connection', function (ws) {
...
});
};
I get connections from, at the moment, 2 different locations.
A router app I have running that is sending this web app logging messages.
The html-page that this web app is serving.
I want to pipe the data from the router app to my html page, but to do that I need to know which of my connections I need to pipe the data to. I can in theory have many connection, but only one of them, at least for now, should be passed the data after it is recieved.
I thought I could compare the origin of the web socket connection to the domain of the web server the web socket server ran on.
I can get the origin of the connection like this: ws.upgradeReq.headers.origin. That will return e.g: localhost:5000. But I don't know the domain name where my web socket server is running. I've tried to google, and it seems like to get the domain name, I need to get it from an http request. What I am looking for is something that just gives me the name, without having to wait for an http request.
I've tried os.hostname(), but it doesn't give me the results I need.
I've also tried server.address(), where server is var server = require("http").createServer(app);, but that gives me this: { address: '::', family: 'IPv6', port: 5000 }.
Isn't there just a way to get the host and port? Can I somehow use the address part above to get the host name?
The web app will probably run on Heroku.
Based on your recent comments, it sounds like each browser client that connects a webSocket should just tell your server what web page it is looking at with an initial message and the server should keep track of that for each active connection.
In socket.io (built on top of webSockets), you could just connect to the /homepage namespace and then that server could broadcast to all sockets connected to that namespace. You could, of course, implement that type of functionality yourself with a plain webSocket.
Then, your server would not only have a list of connected sockets, but could also know what page they were all from. That would allow you to broadcast based on current page. Your server-to-server webSocket would not have sent a message that it's from the home page, so it would not be tagged as such and you could avoid sending to it.
You might find socket.io easier to use for all of this. In additon to namespaces on both client and server, it also gives you automatic reconnection from browsers, a simpler message passing system, server-side broadcast to namsepaces and so on.
I created a WebSocket client in JavaScript
if ("WebSocket" in window) {
ws = new WebSocket(url);
ws.binaryType = "arraybuffer";
} else if ("MozWebSocket" in window) {
ws = new MozWebSocket(url);
ws.binaryType = "arraybuffer";
}
and a WebSocket server application. For certain cases I programmed the server to reject the connection request and provide an error code.
In e.g. Firefox Console then a message is shown
Firefox can't establish a connection to the server at ws://123.123.123.123:1234/.
and it provides the status code
HTTP/1.1 403
which is the error code that I have sent by my WebSocket server.
My question is: how can I read this status code in my JavaScript client?
ws.onerror = function(e) {
console.log(e);
};
ws.onclose = function(e) {
console.log(e);
};
are both called, but none of the Event objects contains this error code.
The spec forbids reading the HTTP status code (or anything like it) from the WebSocket object because otherwise the WebSocket object could be used to probe non-WebSocket endpoints, which would be a security issue:
User agents must not convey any failure information to scripts in a way that would allow a script to distinguish the following situations:
A server whose host name could not be resolved.
A server to which packets could not successfully be routed.
A server that refused the connection on the specified port.
A server that failed to correctly perform a TLS handshake (e.g., the server certificate can't be verified).
A server that did not complete the opening handshake (e.g. because it was not a WebSocket server).
A WebSocket server that sent a correct opening handshake, but that specified options that caused the client to drop the connection (e.g. the server specified a subprotocol that the client did not offer).
A WebSocket server that abruptly closed the connection after successfully completing the opening handshake.
— https://www.w3.org/TR/websockets/#feedback-from-the-protocol
There is another way to do it though!
The WebSocket protocol allows for custom close codes:
4000-4999
Status codes in the range 4000-4999 are reserved for private use and thus can't be registered. Such codes can be used by prior agreements between WebSocket applications. The interpretation of these codes is undefined by this protocol.
— https://www.rfc-editor.org/rfc/rfc6455#section-7.4.2
In your server-side logic, even when you ultimately want to reject the connection (like say the user is currently unauthenticated), do this instead:
Accept the WebSocket connection
Immediately close the connection with a custom close status
The client can now look at the CloseEvent.code to know why the connection was rejected.
You don't need to do this every time the server wants to reject a WebSocket connection. For example, I'd still reject the connection with a 4xx HTTP status if the request isn't a proper WebSocket request, or for security reasons (like if the anti-CSWSH Origin check fails). You only need to use the WebSocket close status for cases that you want the client-side logic to handle.