I have been looking at various solutions around but when I put it all together, it looks very confusing.
I am trying to implement pm2 cluster mode for my application which has socket.io implementation. Now, I understand the concept that statelessness is required in order to make my app work properly in cluster mode. And socket.io is NOT stateless. The confusion is,
1) Our friend Cam says that just implementing socket.io-redis would work fine when we'll spawn on the maximum number of CPUs.
2) While socket.io says and I quote,
Note: sticky-session is still needed when using the Redis adapter."
For 1), According to my research, Internet should disagree that it would work. Maybe Mr. Cam got lucky to have transport method as websocket and might not had to deal with polling. But at the same time I think it should work, since redis-adapter is what we are using to make it stateless.
INFO: It worked for me with websocket as transport method but I couldn't test it with polling.
For 2), I think we can combine Mr. Joni's advice to run it with "pm2" IN "cluster" but on different ports. And then our beloved nginx's upstream group with ip_hash would give us kind of same effect.
Additionally, I want to make my application elastic. NOT just on cluster level but both scale up and out. What are the best practices given that my application included socket.io implementation and session token management in redis?
Am I missing something or am I totally wrong here? Which would be the best way to scale?
I've got the solution!!! And it is working perfectly fine for me! Thanks to #elad and contributors. I've done some extensive amount of testing(more than 2 MONTHS!) and never had a problem. I'll not disrespect the author by explaining what the snippet does as it has already been described enough, line-by-line.
It took me long enough because there were open issues on the repo and had to be sure. And now I am sure that those issues are workable with understanding of different components. Afterall, this is not magic!
Have a look and let me know if you still have doubts/questions.
Related
I'm looking for something to make my 2 running apps to communicate with each other.
I have two apps - main.js and events.js and I want to send event from events.js to main.js. I don't even know what to google for that coz everything I can find seems a little bit outdated and I'm looking something different then redis. I found out I can use uuid to communicate between different node.js processes but I don't know how. Any information would be great!
Your best bet is to use a message queue system similar to Kue.
This way you will be able to make your apps communicate to each other even if they are on different servers.
If you want to work without the redis backend you can skip the filesystem entirely and move to Sockets/TCP communication, which is one of the ways of getting around semaphores. This is a common method of low latency communication used by applications on the same machine or across the network. I have seen and used this method in games as well as desktop/server applications.
Depending on how far down the rabbit hole you want to go there are a number of useful guides about this. The Node.js TCP API is actually pretty great.
Ex.
https://www.hacksparrow.com/tcp-socket-programming-in-node-js.html
i am looking for a very lightweight framework that can very simply pass data between browser and the server. i started looking around for a possible alternative to express & socket.io and came across express.io and have a couple of questions:
1) when i look at express.io on github, it would appear that there has been no activity for a couple of years. should this be of any cause for concern? from my newbie perspective, i would think that one wants to strike a balance between stability and something that might not be under active development anymore. but i am only guessing.
2) websockets looked very interesting and i see some very recent activity there. any thoughts on if this is a good replacement for socket.io ? our application will only be running on a new html5 browser.
i have looked at quite a few possibilities (layers, kaph, locomotive, stapes, hapi, etc) but i wanted to stick closely with something that was more sinatra-like, very similar to express. i also thought perhaps i should look for recent development.
or could it be that there is really nothing better than the original socket.io & express ?
thank you very much.
socket.io is built on top of webSockets. It adds a bunch of useful features that webSockets do not have such as automatic reconnection, structured message passing, etc...
So, one would only really go back to webSockets from socket.io if you had no use for any of the extra features that socket.io adds or if you need to be compatible with some other endpoint that is only a webSocket and not socket.io.
As for express.io, here's one such discussion of a similar question: What utility of express.io VS express + socket.io?. The fact that there has been no development on it in a few years and that the domain it was using has expired seems like it is no longer being supported unless there is some other fork that is being developed. I don't know express.io very well myself, but it appears to be just be some extra glue that allows you to capture socket.io messages using express-like route definitions. It doesn't appear to really offer new capabilities that can't be done with just express and socket.io.
For you to get much else in helpful advice, I think you'd have to describe a lot more about your requirements and why express + socket.io doesn't already meet your needs.
https://pusher.com/ is a really nice software as a service that accomplishes this functionality. It's similar to socket.io and also runs on webSockets. There are a lot of other services like that out there. Pusher's free tier is not too bad, and you likely won't run over the hard constraints unless you're making enough money to pay for the premium tier of service. Their libraries are also super easy to understand.
socket.io is still a great choice, just wanted to show you that there are more options out there.
I have built a little system that uses dnode, shoe and browserify on the client, and NodeJS and dnode/shoe on the server end. I'm wondering if it is a good idea to use dnode (RPC) as the sole protocol for a real-time web application.
Let's look at the benefits of DNode or any other RPC interface. I like being able to call functions remotely (RPC). It definitely beats Ajax because you get a consistent interface for communicating from the client to the server and server to the client. I'm also betting that you get a small measure of performance over Ajax because of the HTTP overhead involved with Ajax.
However, using RPC, you have to deal with load balancing and the client connections on the server. But this goes with any websocket implementation. But, with other websocket implementation, you have a more traditional event based system, where the client listens to events from the server and responds to those events. I tried replicating this sort of interface using EventEmitters, but it's awful, and I keep getting warnings about too many handlers. Ugh!
I'm looking to achieve a lightweight, clean, interface that I can use to develop my application with. One that feels robust and is able to scale to many clients. It needs to feel solid.
I'm not really sure what my question is in writing this post. I'm tasked to update this codebase I wrote so that connections aren't lost, and it's overall more robust. I guess I'm just desperate for advice or consulting with my application. Is there someone so willing as to go face-to-face with me on discussing this topic (RPC and real-time web applications)?
Thanks for reading.
I have been investigating some of the same topics as it seemed to me than some of the RPC libs were very cool, but not altogether practical for large scale apps. I actually started with NowJS, realized it was a dead project, moved to DNode/Shoe/Browserify, and finally have moved on to SocketStream in an attempt to offload some of the dirty work to a project that has a unified goal. I really didn't want rewrite what others had already done on this subject and socketstream makes that easy. To get back to your question, as you can see on their page, SocketStream uses sticky sessions. This is a big assumption but one that probably can't be worked around at the moment without further developments. The reason I mention it is that they talk about some of the things they are working on as far as scaling goes. Might we worth a read or reaching out to the developer to see if you could talk things over with him. Good luck!
My question is rather straightforward. I started developing quite a large project and realized that node.js COULD be a viable solution. Since I am still new to node and therefore not in the position to determine if it's the right thing for me, I decided to ask here.
The project: It's basically an administration solution for gameserver providers. It includes both a web administration panel as well as server components to control everything.
My doubts are if I should use node for the panel.
It will require life updating of data (where sockets could come in handy) and we plan on developing it as a "one-page" kind of app.
Having it node means it would be able to perform tasks asynchronously and on it's own (instead of, say, php and cronjobs)
It will be distributed. Making it node would make this easy. No dependencies besides node, and a simple "npm install".
It will have multiple people connecting to it and using it at the same time.
Will node be able to handle these multiple connections well? Performance wise, will it be a good choice?
Will node (and maybe Derby) suffice to build a good web panel?
Am I right about any of the points I made, or did I miss something?
Thanks for the help!
Sincerely
-Antariano
Well you did answer yourself for some of the questions. Thanks to the asynchronous tasks node can take quite a load of connections so it should handle your app. I don't know Derby, but express is also good for your task.
Also when one node server will be insufficient you can always deploy next one and just create some communication between them. Since node is lightweight it can do the job.
Will node be able to handle these multiple connections well?
Yes.
Performance wise, will it be a good choice?
Yes.
Will node (and maybe Derby) suffice to build a good web panel?
Yes.
Am I right about any of the points
You are right with all of them.
I think node will be sufficient for this job.
Before starting to write my application I need to know what to do when a single node.js instance (express and (socket.io or nowjs)) isn't enough anymore.
You might tell me now, that I shouldn't care about scale until it's about time but I don't want to develop an application and run into trouble because you can't easily scale socket.io or nowjs across multiple instances.
I recently read that socket.io now supports a way to scale using Redis (which I also have no experience in). Nowjs is build on to of socket.io - does it work the same way? On nowjs.org you can read that a "distributed version of NowJS" is under development and is going to cost money.
If you need to scale node, the first place people usually start is putting a load balancer in front of multiple node instances. The standard for this today is nginx, though I would would like to check out the node balancer 'bouncy' that came out recently. Here's an example of someone using the nginx reverse proxy to manage multiple node instances:
Node.js + Nginx - What now?
The second thing you mention is socket.io/nowjs. Depending on how you're using these frameworks, you could get into a situation where you want to share context between clients who are hitting multiple node.js instances. If this is the case, I would recommend using a persistent store, like redis, to bridge the gap between your node instances. Here's an example:
How to reuse redis connection in socket.io?
Hopefully this is enough information and reading to get you started, let me know if you have any questions.
Happy coding!
Another useful link on 'Scaling Socket.IO' https://github.com/dshaw/talks/tree/master/2011-10-jsclub (slides and sample application)
Just as a sidenote on the discussion to use nginx for reverse proxy with socket.io, the way I understand it at least, nginx 1.0.x which is stable version does not support proxying of http/1.1 connections (which is needed in order to make socket.io work with websockets). there is a workaround described on here: http://www.letseehere.com/reverse-proxy-web-sockets to make it work, or use something like this: https://github.com/nodejitsu/node-http-proxy instead, the guys at nodejitsu says this should support it.