Home/ Questions/Q 8032427
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-05T01:22:48+00:00

I am building a node.js application. When a user connects, they transmit their state

  • 0

I am building a node.js application. When a user connects, they transmit their state as online. When they disconnect, the state gets switched to offline. Also, when a user connects, he gets a list of his connections, along with the states of these friends(online or offline). Ok, great, no problem with this.

But the trouble I’m running into is how to dynamically send the state of a user’s freind while I’m logged in. So, the steps would look like:

  1. I log in.
  2. I get a list of all my friends: user1, user2, user3
  3. I get a list of states for all users: user1:online, user2:online user3:offline
  4. user1 logs off
  5. How do I dynamically get the state change of user 1?

Remember that these users aren’t connected to each other, and also remember that a user’s state needs to get transmitted to all the other user’s who have him as a friend. Let’s say that user1 has 100 friends, I am one of them. I (along with the other 99) need to get the notification that user1 is now offline. Also note that these people may not be on the same physical server (multiple servers handling X number of connections each). What is the best theoretical way to solve this problem?

The only answer that I could come up with is that I save the state in a DB, and that node will query the db, and when the state changes, it will update. But it seems crazy that node would have to watch for changes to the db, that can’t scale. There’s got to be a better way to do this – maybe its an obvious one and I’m missing it.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    As hinted by ebohlman in the comments, the publish/subscribe pattern (also known as “pub/sub”) sounds applicable to your problem. In a pub/sub architecture, instead of the publisher sending messages to specific clients, the publisher instead sends messages to some central pub/sub server. Subscribers notify this server for the kinds of messages, or “topics,” they’re interested in. The key is that the publishers and the subscribers never know, or even care, about each other, making the pattern very scalable (there can be any number of publishers or subscribers).

    Publish/Subscribe Pattern

    In your case, each of the servers that handle user login/logout might subscribe to the “login_changed” topic. Whenever a user logs in or out, the server that processed the change would send a message to the pub/sub server with the topic “login_changed” along with some data indicating what happened to whom (e.g. with a JSON-encoded string). Each of the servers that have subscribed to the “login_changed” topic will receive the message, and they can each determine if they’re responsible for tracking the user in question.

    There are several common tools for managing the pub/sub pattern. Redis, a common key-value store, has support for pub/sub and is a personal favorite tool of mine for the task. AMQP is an open standard that includes many kinds of messaging-related behavior, including pub/sub, and has many implementations, the most common of which is probably RabbitMQ. If you’re interested in hooking up web clients over HTTP, you might be interested in something like Faye. There’s a lot of literature on the subject, as well as many implementations in many languages; a Google search should take you far.

    • 0