What are the good use cases for using RPC over MQ ? If a node process wants to talk to a java program, can we use RabbitMQ ? What are the other alternatives ?
what nowjs or dNode does that can not be done with socket.io ?
There are many modules in node.js on either RPC or MQ.. Do they all cater to some specific need ?
EDIT:
What I am looking for ?
How do you do a RPC style of full duplex communication between browser/client and server? I think the answer would be socket.io or nowjs or dNode.. Please add if there are more.
How does your node process talk to other processes in a heterogeneous system ? This might be necessary if you want to offload some of your CPU bound task to other processes... For example between node.js process and a Java process. There can be 3 different ways of doing that. Which one is suitable for what ?
i. publish-subscribe
ii. request-response
iii. push-pull
When would you use xmpp and not rabbitMQ ?
Yes, NowJS or dnode are good choices.
redis pub sub might work for you, as would using rabbit. Depends on your use-case.
I don't think xmpp and rabbit are comparable? rabbit is for messaging, xmpp is a chat protocol (like what google chat uses, I think).
/fyi #node.js IRC welcomes you: http://bit.ly/nodeIRC
Related
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.
I want to use a communication mechanism between a server and a linux client, for messaging and discovery. My only requirement is that, the client should be as lightweight as possible. On searching internet, I cam across XMPP and MQTT. But, I am not sure, which of its version is the most lightweight. Can anybody please guide me regarding which is the most lightweight of all. Please let me know, if any other such mechanism exists.
This isn't an easy question, because it's not clear which aspects of "lightweightness" you are looking for. Are you looking for small implementation (in file size), for minimum CPU usage or minimum network requirements.
MQTT and XMPP can both be pretty slim on the client side. Out of the box without any extensions, MQTT most of the time is (much) more lightweight on the wire, it's a binary protocol while XMPP is (without any extensions) XML based. MQTT focuses on efficient Pub/Sub messaging, if you need something fancy on top, you should choose a sophisticated broker (click here for an overview). XMPP has a bit more out of the box. If you don't need things like friendship requests on the protocol level, MQTT is a solid choice.
Again, both protocols have their use cases (which IMHO don't intersect too much). A pretty good overview of MQTT, XMPP, CoAP and HTTP can be found here on slideshare.
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 got a server running SignalR and another server runing Node.js. I would like these two servers to communicate using SignalR. Is this possible?
I'm thinking I can use the SignalR client javascript library to connect to the SignalR server from Node:js but I can't find any good examples of how to do this.
Well the answer to can you do this is ultimately "yes" because there is nothing proprietary about SignalR communication. It's just variations of HTTP or WebSockets with a custom handshake/message framing protocol for Hubs on top of that.
So the how is the question we'd need to answer. Out of the box SignalR provides a client side JavaScript library based on the jQuery plug-in architecture, but that won't help Node.js. Someone has started a Node.js implementation here on GitHub, but according to the ReadMe it only supports HTTP long polling today. I'm unaware of any other implementations at this time, but obviously you start with that one and fork it to add support for the other transports if you wanted.
MsgPack ?
JSON-RPC ?
Socket.io (is it possible ? how ?)
EDIT:
I am talking about 2 node processes each one on a different physical machine;
I don't understand how redis can help me on this...
I'm not really clear on whether you are looking for ways to make two node servers on two physical machines "talk to each other", or two node.js server processes on one machine.
(You could edit your question to make it clearer).
You could look at:
protocol buffers for node
MsgPack-RPC for node
Websocket.MQ
dnode --This uses socket.io as the transport layer
IPCNode
AMQP with node-amqp or node-amqp and something like RabbitMQ
Or you could go with a document based db like redis
Note: some of these may need some updating
I hope this helps
I would go for redis. The pubsub semantics are pretty sweet. The node_redis client library is very fast because it can use the lightning fast c-extension-library named hiredis. I would just use json as my encoding. That will probably be more than fast enough.
You could also use DNode to do your communication if you like. I also believe it has socket.io capabilities. You should have a look at the source code to find this out.
It is not really clear from your question what do you mean by a Node server talking to another server. You can use anything from sending UDP packets, making TCP connections, HTTP connections to using any of the high-level mechanisms that others have already pointed out.
For an interesting scenerio of Node processes communication you may take a look at
the 2010 JSConf.eu talk by Mikeal Rogers. He explains how to use CouchDB to do that. Very interesting talk.