I am making an application live chat SAAS, and I intend to use socket.io, but some doubts arose.
1) I realized that all applications in the same category do not use socket, there some reason for this?
2) Socket.io is ready for medium / large-scale applications? It is a good choice?
3) I'm thinking of creating a room for each time conversation. This is a good practice?
4) To the service conversation, I better use room, namespace or otherwise?
5) A server with 2GB ram supports many socket connections about?
Thank you so much.
1) I realized that all applications in the same category do not use socket, there some reason for this?
socket.io uses websockets (obviously) and falls back to HTTP. HTTP has well defined request and response definitions. Everyone knows what a 404 is right? socket.io is pretty new and how emits should behave is not well defined.
2) Socket.io is ready for medium / large-scale applications? It is a good choice?
Websockets are not as well supported as HTTP. NGINX provides good websocket support as a webserver and I can vouch for NGINX in this respect. Not all products provide such good support. e.g. if you want to use Google APIs do they support websockets? Unlikely!
3) I'm thinking of creating a room for each time conversation. This is a good practice?
That's not a development question. Research existing chat sites and make your own decisions :)
4) To the service conversation, I better use room, namespace or otherwise?
Sounds good.
5) A server with 2GB ram supports many socket connections about?
I don't know how well socket.IO scales.
Related
I am looking to implement some sort of chat server. And I want it to scale. This seems like a big question, so I guess I expect the answers to be direction pointers, sort of exploratory.
The end-user clients are web or phone client. I think some sort of websocket implementation, such as Socket.IO is nice.
On the server side I wish to use Node.js. I want the architecture to be scalable so that the number of users are not limited (well, within reason, the chance of big hit is not expected, and if it is, the chance of having smarter, experienced people to work on it is reasonable instead of currently just me coding) The number of users per chatroom is hopefully not limited, or maybe some fixed large number. And that means I need to scale horizontally using several servers written in Node.
Suppose some load balancer (and hopefully in the future not a single point of failure, but I don't know how I would achieve that, or maybe just move to AWS) are dispatching SocketIO connections from the end clients to the chat servers. Different users connection to different servers may be in the same room, so the messages need to be send to other servers.
How would I feasibly implement something like this? Hopefully not too complex.
Questions:
(1) If all servers need to handle all messages as users can be logged on via any of the servers, does this scale?
(2) Do I need some sort of message queue for the servers to talk among them? Is Pub-sub from Rabbitmq usable for this? Or if zeromq, how would I scale with pub sub? The Zeromq guide is has explanations for scaling to more than one server with REQ/REP type of applications. But not Pub Sub.
(3) Or should I start with XMPP?
I am hoping to make it work as easy as possible.
There's a rather good explanation at the Socket.io site. Have a look at
http://socket.io/docs/using-multiple-nodes/
It suggests using Nginx as HTTP load balancer, Node.js clustering (with sticky sessions) and Redis as the message backend.
I think your goals should be achievable with little to none coding involved, only using the given modules and configuration mechanisms.
I have been tasked to develop a mobile chat app that will run both on Android and iPhone devices. I will be developing the respective clients in their native languages. Where I am a bit confused is in the development of the server.
My intended approach is to use 'long polling' to retrieve messages from the server and a separate connection to send messages to the server using GET/POST (obviously, there is no need for this to be long polled). My initial intention was to use Apache & PHP?MySQL for the server, but after a bit of reading, I learnt Apache won't be able to survive when there are lots of concurrent connections. I also learnt Node.js can survive where Apache failed by its capabilities to handle a lot of concurrent connections. Though, I don't have any knowledge about Node.js but if it will work, I am willing to do a crash course on it.
I know 'long polling' isn't the best method, but I can't seem to understand how XMPP can work for me on this project.
Thanks a lot in advance.
XMPP is the best way. You can install openfire on server side and for android you can use asmack. For Ios you can use xmpp lib.These are best combination. Communication with server is done through ssl connection.
I have built a multiplayer game with real time leader board. The game is in PHP(Backend) + Flex(Front end).
I have used socket.io for real time communication with a node.js server. But I am facing a lot of problem with respect to proxy settings on my client network configuration. Most of the time my application doesn't communicate with my node(socket) server. It is not able to establish a connection because of proxy configurations.
What alternatives can I go with? I tried to search a lot for alternatives. I came across services like pusher and pubnub, but those are little expensive. Have anyone tried Amazon SNS, is it suitable for this?
Thanks!
The reason that you cannot connect through proxies, is because socket.io is using web sockets. See Socket.io and firewall Software (that page also includes a link to test websocket connectivity). There are a number of ways you can mitigate this problem:
Use secure websockets (wss://)
But this does also not guarantee for 100% that it will work.
Use one of the fallback mechanisms of socket.io: Flash, Ajax, iFrame, JSONP, ...
For more information, see Configuring Socket.io.
There is SocketCluster: https://github.com/topcloud/socketcluster
It runs on multiple CPU cores and it's good with error-handling (workers auto-respawn). It has no identified memory leaks (just make sure you use latest version of Node.js).
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!
I want to implement newsfeed for followers just like Twitter in realtime. But I'm stucked which tools will be the best for my purposes. The solution (complexed solution) should be production-ready. I've tried node.js + socket.io + rabbitmq (node-ampq, rabbitJS), but node frequently crashes... Another solution is Tornado + sockJS-tornadio, but I'm unsure (and know Python not good). Before diving into code, I just need to know which tools are ebst for my purposes and can be 'really' realtime. By 'really' I mean trully fast request-responses. I've tried RabbitMQ + PHP API + Ajax, but it's not 'really' realtime, it uses ajax instead of, for example, websockets.
The data for newsfeed will be like 'John updated its profile', 'Doe uploaded new file' and something similar.
Thanks!
What sort of crashes are they? Node has been fairly stable for some time now, at least for me.
Node is a fine solution, but you introduce some amount of complexity with communication between Node and PHP (which you look to want to solve with RabbitMQ). "Really" realtime can be easily accomplished with socket.io, and since it has multiple fallbacks is ideal for getting a wide audience. Long polling and friends do have their overhead but it isn't too much if the events aren't very frequent.
If it's easier for you to integrate the newsfeed into your PHP program and you are willing to accept the minor overhead I say go for it. Otherwise, I would invest in Node. The platform is still young, but it's matured well, IMO.
I just build a realtime web application.Users can drag items and chat in the same page.and I use tornado + jquery pending + redis as a MQ system.It works good, but I am considering to try socket.io to handle realtime requests.
tornado is kickass in terms of performance, and really easy to work with. the only problem is that you need to make sure you have adapters for databases and other blocking-by-nature sources you need to communicate with. It supports websocket of course so you can stream data to users.
If I had to implement this today, the stack I'd use is:
Redis for the data and pub/sub on channels.
Tornado as the API server.
WebSocket for the communication layer wherever possible.