[rabbitmq-discuss] building chat

Fri Aug 7 11:52:41 BST 2009

Ben,

Further to your email exchanges with Paul...

On Thu, Aug 6, 2009 at 3:32 PM, Ben Browitt<ben.browitt at gmail.com> wrote:
> Hi,
>
> I'm trying to understand how AMQP and RabbitMQ works by building a simple
> chat.

Cool :-)

> From reading the AMQP specs I get the impression that it's best usage is
> when someone publish content to an exchange
> and someone else bind his queue to this exchange to get updates. This model
> works very well for publish-subscribe
> and to finance systems but chat could be different.

I think chat is a very natural application of AMQP.  The benefit of
using XMPP would be to integrate with existing chat infra in a
standard way, but that does not prevent you from using an AMQP based
implementation underneath.

Do you want to do MUC or IM?

In fact, you can use a single approach to both.

One approach is to have one queue per consumer 'chat window' and one
exchange per 'chat room'.  The queue is bound to the exchange when the
user is in the chatroom.  Then, IM is a special case of MUC - it is a
chatroom with two participants.

Another approach would be to have one queue per consumer, and have
that queue bound to the exchange(s) N times, where N is the number of
chatrooms (or IMs) which the consumer is currently in.  In this
approach, you will need to identify which message came from which
room, before you show the messages to the user.  That's easy but it's
extra work and data to carry around.

Let me know if you want more detail on either of the above, eg which
exchange type to use.

> I read the xmpp gateway
> docs and have some questions.
>
> In a chat we want to be able to get presence from users on our friend-list,
> send them messages
> and send subscription request and messages to users not yet on our
> friend-list.

Do you only want to enable chat when both users are online and have a
'friend' relationship?

> One possibility is that each user will have an exchange and a queue with
> binding to his own exchange.
> When user1 wants to send a message to user2 he send it directly to the
> exchange of user2.
> There is a problem with presence updates. If user1 changes his presence,
> he'll have to sends the update
> to the exchange of all the users on his friend-list. With this design we
> move the logic to the client rather then use the AMQP features.

One approach to presence is to broadcast changes using the pubsub
system.  Changes could include:

* User goes online / offline
* User changes their 'status message'

> Another option is that when a user logs in he'll create a binding to the
> exchanges of all the users on his friend-list.

You can do this but it creates quite a lot of churn on the exchange
layer.  Paul's suggestion is one way to prevent that.  Another is to
use exchange-exchange bindings, which we are also looking at.

> When user1 want to send a private message or a presence update to user2
> he'll send it to his own exchange and it'll be directed to user2. The
> problem with this design is that users without mutual presence subscription
> can't send private message to each other and can't send subscription
> requests.

You can decouple presence, which is about status updates, from
friendship.  If you like, you could have a set up where one user can
DM another, provided they are mutual friends, regardless of who is
online.  Do you want that?

Subscription requests could also be implemented using a queue - one
per user.  Whenever a new user wishes to request mutual friendship
with user A, then user A could be notified of this via a queue.

> Can you please share your thoughts on the two options and maybe other design
> options?

I've tried to shed some light on some of the issues above.  Feel free
to elaborate on your needs and ask more questions.

alexis

> Thanks
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
>