I am using socket.io with xhr polling on my chat system.I don't want to use websocket because not working on all users.But when I use xhr polling if user open 5 tabs on the browser,messages slowing down.
Same problem here
https://github.com/LearnBoost/socket.io/issues/1145
I tested it but not worked.Still have 5 connections limit.How can I disable this limit ?
I come across this question quite late, but it seems that you have reached the connection limit of your browser. By default, the browser has a limit on how many connection to a host:port can be opened at one time (Chrome allows 8 for example)
So, for your socket.io case, when you open 5 tabs to the same domain which means that you have used 5 connections allowed by your browser. For normal websites, it is not a problem because you request and receive a response, then the connection is closed. But for socket.io (and related libraries), the connection is kept opened at all time to receive "server-push" data. I might be wrong, but at least this is the problem with my project (I don't use Socket.IO but a similar library)
The solution is to limit the number of socket.io connections in your application so that there will be only 1 connection at all time. The rest of the communication should be done via cross-tab (cross-window) events (through LocalStorage for example). The result is that you have 1 tab (window) holds the real socket.io connection and broadcasts events (received from socket.io) to the other tabs (windows). Of course, there are many other factors that you need to consider when you actually implement it
P/s: I am sorry for my bad English
You provided the solution yourself--the bug ticket you linked has links to a solution at the end, which is basically to add this:
var http = require('http');
http.globalAgent.maxSockets = 100;
http.Agent.maxSockets = 100;
Or whatever maximum value you want.
Related
I am making a tracking system and i would like to know, if i have 1000 cars (clients) transmitting via sockets(tcp) at an interval of 5 seconds. Should the client open ,send then close the socket. Or should client keep the socket open though out as it transmits.
Depends on many things. For example, if there is a maximum number a server can handle sockets at same time, then you better close them in case you are going to have lots of requests. At the same time, if a live and fast connection really matters to you (1 request per 5 sec is normal, not too high not too low in my opinion) then live socket connections are better for you. Note that they also give you power in server side to broadcast messages to clients at any times, while with none persistent connections you have to broadcast messages as response to each 5 second request.
The tags you used suggests me you are trying to choose between websocket or HTTP. Finally, I should clarify that it really depends on your needs. With HTTP you can serve your logic to more clients, while with websocket you have to deal with server loads a little harder while you have advantage of sending messages to clients and faster tracking, and handshake just happens once.
I have a React App that currently in development. I use socket.io to connect the frontend to my server file which I'm running locally.
I opened multiple tabs (including incognito) so I can simulate multiple people using it at the same time and the browser hangs up on the 4th window. I can open up to 3 just fine. When I introduce the 4th one I can either not get the React app loaded or I load it and it hangs up when I try to do anything that emits a socket action.
I did notice that I can open a 4th window in Firefox no problem. So it seems like it's a Chrome / Browser thing limiting me to 3 socket connections from a single browser.
Any ideas on what's going on? I don't even have a ton of emits being sent out. I really don't think it's my server or client code. I tried turning on `multi-plexing using
const socket = io.connect('http://localhost:3000', { forceNew: true });
in my Client code (React) but it didn't fix the problem until I started using Chrome and Firefox together to keep Chrome under 4 tabs.
Unfortunately this is a hard-coded limit of open connections to a server in Chrome.
It's actually 6 open sockets per host (https://support.google.com/chrome/a/answer/3339263?hl=en). However, to confuse things, I suspect that you're using something like hot-reloading, which also uses a socket (hence why each page takes up two sockets, not just one).
The only thing you could do, depending on your architecture, is spawn multiple servers on different ports (then you'd be able to have 6 per port).
Alternatively, as you've found, you can use another browser that does not enforce this limit.
I have a production app that uses socket.io (node.js back-end)to distribute messages to all the logged in clients. Many of my users are experiencing disconnections from the socket.io server. The normal use case for a client is to keep the web app open the entire working day. Most of the time on the app in a work day time is spent idle, but the app is still open - until the socket.io connection is lost and then the app kicks them out.
Is there any way I can make the connection more reliable so my users are not constantly losing their connection to the socket.io server?
It appears that all we can do here is give you some debugging advice so that you might learn more about what is causing the problem. So, here's a list of things to look into.
Make sure that socket.io is configured for automatic reconnect. In the latest versions of socket.io, auto-reconnect defaults to on, but you may need to verify that no piece of code is turning it off.
Make sure the client is not going to sleep such that all network connections will become inactive get disconnected.
In a working client (before it has disconnected), use the Chrome debugger, Network tab, webSockets sub-tab to verify that you can see regular ping messages going between client and server. You will have to open the debug window, get to the network tab and then refresh your web page with that debug window open to start to see the network activity. You should see a funky looking URL that has ?EIO=3&transport=websocket&sid=xxxxxxxxxxxx in it. Click on that. Then click on the "Frames" sub-tag. At that point, you can watch individual websocket packets being sent. You should see tiny packets with length 1 every once in a while (these are the ping and pong keep-alive packets). There's a sample screen shot below that shows what you're looking for. If you aren't seeing these keep-alive packets, then you need to resolve why they aren't there (likely some socket.io configuration or version issue).
Since you mentioned that you can reproduce the situation, one thing you want to know is how is the socket getting closed (client-end initiated or server-end initiated). One way to gather info on this is to install a network analyzer on your client so you can literally watch every packet that goes over the network to/from your client. There are many different analyzers and many are free. I personally have used Fiddler, but I regularly hear people talking about WireShark. What you want to see is exactly what happens on the network when the client loses its connection. Does the client decide to send a close socket packet? Does the client receive a close socket packet from someone? What happens on the network at the time the connection is lost.
webSocket network view in Chrome Debugger
The most likely cause is one end closing a WebSocket due to inactivity. This is commonly done by load balancers, but there may be other culprits. The fix for this is to simply send a message every so often (I use 30 seconds, but depending on the issue you may be able to go higher) to every client. This will prevent it from appearing to be inactive and thus getting closed.
I've implemented the chat application using node.js. The program open the connection with the client and it'll response the new message when the EventEmitter emit "recv" event.
The problem is it takes very long time to response to other request when the server hold about 3 or 4 more streams. The chrome developer tool show the status of the request as pending. it took more than 5-30 second to reach the server(localhost). I use console.log to log when the new request is received by the node.js
I have no idea why there's a long pause. Is there any limit on chrome browser, node.js or any other stuffs i should know? Does the node delay when it hold too many request at the same time and how should i measure this value? Thank you
Chrome supports six simultaneous connections per domain, so if those are already in use, it will have to wait for one to close. If you want to know what's going on, use a packet capture program to check the actual network traffic.
Browsers are limited to certain number of parallel connections which applies to the same browser context - for example when you have opened let's say more than 6 tabs, then the connections will be queued and you will see them pending.
You can avoid this limitation, for example, by using unique poll subdomain for each client connection. This is how facebook workaround this limitation, however problem is with Firefox, where this workaround doesn't work and your connections will be queued when they reach the limit even when you use unique subdomains.
Other solution might be to use HTML5 local storage where you can take advantage of StorageEvent which propagate changes also to other tabs within the same browser. This is how StackOverflow chat is done. Advantage of this approach is that you need only one polling connection with the server, but disadvantage is lack of HTML5 local storage support in older browsers or different implementation in FF version < 4.
We have an browser application (SaaS) where we would like to notify the user in the case of internet connection or server connection loss. Gmail does this very nicely, the moment I unplug the internet cable or disable network traffic it immediately says unable to reach the server and gives me a count down for retry.
What is the best way to implement something like this? Would I want the client browser issuing AJAX requests to the application server every second, or have a separate server that just reports back "alive". Scalability will be come an issue down the road.
Because GMail already checks for new e-mails every some seconds and for chat information even more frequently, it can tell without a separate request if the connection is down. If you're not using Ajax for some other sort of constant update, then yes, you would just have your server reply with some sort of "alive" signal. Note that you couldn't use a separate server because of Ajax cross-domain restrictions, however.
With the server reporting to the client (push via Comet), you have to maintain an open connection for each client. This can be pretty expensive if you have a large number of clients. Scalability can be an issue, as you mentioned. The other option is to poll. Instead of doing it every second, you can have it poll every 5-10 seconds or so.
Something else that you can look at is Web Sockets (developed as part of HTML 5), but I am not sure if it is widely supported (AFAIK only Chrome supports it).