3

I know this question has been asked partially before (How to Scale Node.js WebSocket Redis Server?) but I am wondering if there is any alternatives to redis for rapidly sharing websocket objects between node instances, specifically ws type sockets (https://github.com/einaros/ws). I've tried redis and ran into issues with the fact that the web socket objects are cyclic and difficult to serialise. I then used Crockford's cycle.js (https://github.com/douglascrockford/JSON-js/blob/master/cycle.js), however it seems to strip out the websocket objects methods, as I get an error from node saying "Object object has no method send" after I have read the socket back from redis and retrocycled it. Any help would be much appreciated.

Thanks in advance, James.

Community
  • 1
  • 1
jamyspex
  • 77
  • 3
  • 8
  • I am kinda not sure what you are trying to achieve. What exactly you mean sharing websocket objects? Are you trying to build a chat system and you are using redis to store the websocket connection information and you use that information for chatting purpose? – Jack Daniel's Feb 04 '14 at 23:42
  • I'm basically building a system that allows messages to be passed from an android phone to a chrome extension . Currently I have an array of browser sockets and an array of android sockets stored locally in node. The Issue is if I start more than one node instance and the users browser and phone connect to different instances there will be no way to forward the message to where it's meant to go. Hope that clairfies, James. @Atul – jamyspex Feb 05 '14 at 09:21

3 Answers3

3

IMO you should use messaging queue for that.. e.g (RabbitMQ)

  1. Application starts on Node A and Node B and connects to RabbitMQ
  2. Client A connects to Node A and subscribe to Queue named XXX Client
  3. Client B connects to Node B and subscribe to Queue named XXX
  4. Client A sendsmessage to websocket server Websocket Server sends message to Node A
  5. Node A publishes messages to RabbitMQ queue XXX
  6. Node B receives the message from RabbitMQ as it is subscribed to queue XXX
  7. Node B sends message to Client B or publishes the messages to all connected clients on node B

So, all you need is to put Messaging queue in your architecture (RabbitMQ, ZeroMQ) etc

Jack Daniel's
  • 2,583
  • 22
  • 28
  • Thanks for the response I'm not sure it solves my problem completely but I think rabbitMQ etc. could hold the answer. Thanks James. – jamyspex Feb 05 '14 at 10:13
  • Sorry but I've been thinking and I'm back, the real problem is that Redis, RabbitMQ etc all send text messages/PubSub messages, as such the problem arise when trying to send ws objects(https://github.com/einaros/ws) because they are difficult to stringify. Is there any robust solution to this. – jamyspex Feb 05 '14 at 10:36
  • What you are trying to do exactly? Do you want to broadcast a message to all user connected to a node server? or do you want to send message to a specific user? – Jack Daniel's Feb 12 '14 at 08:36
  • Hi, its to a specific user. – jamyspex Feb 12 '14 at 11:49
  • And you are storing connection in redis correct? and bottle neck is its not serialized properly to store in redis? – Jack Daniel's Feb 12 '14 at 12:41
  • @Jack Daniel's I need to implement Redis to share messages between users connected in different server instances. Could you please advise me on what to do ? – Jack M. Aug 08 '14 at 09:43
  • 1
    @JackM. I would suggest you to use Messaging queue (RabbitMQ, ActiveMQ, ZeroMQ etc)for that instead of Redis. – Jack Daniel's Aug 11 '14 at 04:20
0

There is a library which allows easily scale WebSocket across node.js processes and machines, you can check out it:

https://github.com/ClusterWS/ClusterWS

Dmitrii Goriunov
  • 178
  • 2
  • 17
0

When we speak of scalability we expect or want to hear the words linear performance gains. To be honest though this is not the case most setups as their reliance on another server/service is too great and thus bottle-necks form up within the network you're trying to host for users.

As we explore options we hear things like Databases, Message Queues, and Brokers; These are fine to use but as mentioned above if reliance on any of them is far too great you will destroy your setup in sure time.

Design the WSS Server to act solo (unless requirements are exceeded). You determine and set limits and let API server know this. So if I have 10 chat-rooms and they hold maximum 100 users and benching my WSS server proved I could hold 400-500 of them. With that information I'd set 4-5 rooms per server. So if two people enter room#1 they are on WSS server#1; If all 10 chat-rooms are full then WSS server #2 is now full and 11th room will need a WSS Server#3 up to 15th room.

The slowest part of the network would now just be your API server handling requests but this may include database as well.

If your requirements are for more users than the example, you can increase core power first or add a second server with help of an MQ or Redis Pub/Sub type setup.

Unfortunately there's no way to properly sort users, so if 3 rooms had 20 users and all were sitting on WSS server#1 that'd still leave a room left with hundreds of user slots available but is this really a problem?

It's possible this room could fill right up so leave them the spot, but still could be days till they max so programming something spicy for your needs will improve how cost effective you make it.

BGPHiJACK
  • 1,277
  • 1
  • 8
  • 16