I am currently looking to buildout a messaging service where users can send and receive messages privately between each other. I may have a need for multi-user chat, but for the most part, I only want single recipients to be able to read messages sent to them.
With looking at RabbitMQ, does it make sense to use one exchange, and create a queue for each user when they login and destroy each queue on logout? Are there major performance issues with creating a queue for each user or are there better alternatives?
I am building a REST API and plan on having users send messages to others through an endpoint (/send) and subscribe to their own message streams via websockets or something similar. I will probably store messages in MongoDB as well, so users can access all of their previous messages. Any suggestions on structure are appreciated.
I think your approach is correct. You event don't need an exchange if you will use the default exchange (AMQP Default). And during login create a new queue and keep queue name same as user name. (Just need to make sure user names are unique) And if you publish message to the default exchange with username (ie: queue name) as routing key, RbbitMQ will route that message to that queue only. And on logout if you delete the queue then user is going to miss the messages when he is not online. If it is OK then create queue after login and use the configuration exclusive which says queue gets deleted when there is no consumer. But if you want to keep offline messages then you need to create queue permanently during user signup.
Related
we are building chat application similar to messenger. There is required behavior:
User log in
User should see last N messages, and he should be able to load older messages
New messages should be appended as well
My solution:
I would like to use websockets for this purpose with combination of REST. My idea was that client application decide by message id which messages need. So REST will be used for initial fetching of messages and fetching older messages.
New messages will received by websockets
Possible issue which I should handle:
Application starts subscribing websocket channel for new messages and send request for old messages without initial message id
There is chance that after calling GET request new message come, and will be stored in DB
Client application started subscribing websocket channel so message will received by websockets.
GET request didn't know about this message and fetch last N messages where this new messages will occured and client application will have duplicate record and have to filtered this messages
Can you give me advice if there is some elegant way how to handle this case? Thank you.
I would resolve your task having in mind the following:
The client application should know only about the topic to which to listen. And not the ID of the message starting from which to listen.
It is up to the server to decide what to return (even time should always be tracked server-side).
The WebSocket is used as a transport for STOMP (simply to not reinvent the wheel). The WebSocket connection could be opened once the client application is loaded and not when it is entering the "listen for messages" state. But topic subscription should be performed when necessary.
You can always send GET request and initiate a STOMP subscription simultaneously (almost simultaneously, well with a delay of 1-2 nano-second). And those always should be processed in different promises. But I would align those in the following way: first, the STOMP subscription is initiated, And a specific message on subscription with the initial timestamp of the start of subscription is delivered; second, REST request to get previous 10-100 messages for the TOPIC prior to a specific timestamp (received from STOMP) is performed.
Getting the last 10 messages (which are prior to subscription moment) could be delivered as by REST as by STOMP approach: you can always react to a subscription event on your server-side, and deliver client-specific messages.
Regarding the problem of multiple identical messages from different "data channels", it is easily resolvable: your client (hope that is not jquery, but rather Angular or React or Vue or anything else) will be storing all the data in a single collection in a controller, and filtering and checking by message-id that only unique entries are stored is easy.
BUT if your system will produce hundreds of thousands of messages per second: I guess HTTP-based protocols are not your choice in this case.
I'm trying to implement chat for my webapp with following features:
When user logs in he should see a number of unread messages (which is both offline messages and "unseen", I will explain "unseen" in next step).
When user is anywhere in the app but on chat window he should be notified that he has a new message. Message should be marked "unseen" and must be added to the count of unread messages.
The first point is quite easily achieved using XEP-0013: Flexible Offline Message Retrieval. So I can retrieve offline messages and when I'm sure user has seen them - I remove them from unread list. But the problem is: how do I achieve same thing for "unseen" messages?
In short what I need is: any message should be marked as offline, unless user sees it and it's removed from the list by explicit request.
Can I achieve that with XMPP and how do I do that?
Thanks in advance.
What you are trying to do is to basically store a counter of unseen stuff in your account. I think you do not need flexible offline retrieval as when you connect the messages would simply become unseen. You thus only have to deal with one case: Unseen.
I will reply from the perspective of ejabberd, that I know better as one of the developer: I would use private storage to store your current state of unseen count and conversation.
I am developing a chat application for android and i phone . Here i am to make persistent groups like whatsapp where members remain joined even after they get offline and after getting online they get their offline group messages. As it is not possible with XMPP so i am thinking about to go for rabbitmq and ejabberd both.
Here is how i want to make group-
When a group is created , an exchange is created in rabbitmq and each group members will add this user to its roster.
Now when a user send a message to rabbitmq then it will be delivered to members who are subscribed to that exchange and offline messages will remain in the queue till user gets online.
My Questions are-
Is it the correct way which i am thinking?
How much exchanges can we create in rabbitmq and how much memory an exchange takes ?
How much messages a queue can store and how much memory it takes?
Should i use it or simply go with XMPP-MUC for group chat?
First from this question :
Asmack/openfire How do I keep a user permanently in groupchat room
I read that I cannot use MUC to keep the user persistent in the group, they'll automatically leave the group and can rejoin after they come online again, that concept is like IRC like what've been asked in here -> http://community.igniterealtime.org/thread/48020.
Then from the stackoverflow question I read about using pubsub, then I've done some research about pubsub and what I've got is pubsub can persist the user to be in the group even the user is offline but the message flow is more like one directional from the publisher to the subscriber (read-only).
So if I want to create a group chat application can I use pubsub and set all the member to become both publisher and subscriber? or is there any alternative solution?or my understanding of the pubsub and MUC is incorrect?
my goal is to create some group chat like in the whatsapp or blackberry messenger group.
Thanks.
You can make users permanent in Group chat in MUC by changing the following code of openfire.
File : src/java/org/jivesoftware/openfire/muc/spi/LocalMUCUser.java
change line 547-550:
// TODO Consider that different nodes can be creating and processing this presence at the same time (when
remote node went down)
removeRole(group);
role.getChatRoom().leaveRoom(role);
TO:
// TODO Consider that different nodes can be creating and processing this presence at the same time (when
remote node went down)
// TODO Dont remove user from group when they go offline.
//removeRole(group);
//role.getChatRoom().leaveRoom(role);
I am developing a xmpp client and currently working on "pubsub".
I created a node in pubsub and subscribed two users to it.
But when a subscriber login(show presence) i get the last published item twice.
I am using ejabberd server.
Can anyone help??
Thank you.
Same here,
There seems to be two different queues. With notification_type=normal, messages are stored offline. When receiver becomes online, it receives the message twice:
from offline spool, without headline attribute
from pubsub send loop (as node is still configured with send_last_published_item = on_sub_and_presence)
As stated here when configuring pubsub node with notification_type=normal, it's best to disable send_last_published_item or set it to on_sub only in order to avoid receiving the message twice.