[rabbitmq-discuss] building chat

[Ben Browitt]

On Fri, Aug 7, 2009 at 12:52 PM, Alexis Richardson <
alexis.richardson at gmail.com> wrote:

> 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?


I'm not actually building it.
I keep hearing about AMQP and RabbitMQ so I read the spec and the server
docs.
I couldn't find use cases on the web so I thought I'll try to fit the
protocol to a fun application.


>
>
> 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.
>

When a client sends a message to another client he usually doesn't create a
chatroom for two,
he just sends the message and the server routes it. With your suggestion the
server will create
the room if it doesn't exists when it needs to route a message.
When all the users leaves a MUC room if it is not persistent the server
destroys it.
What will be the case with a chatroom with two participants?
Maybe the server will destroy it when both users are offline?
Is there a way to destroy an exchange if it is not active for several
minutes to save memory?
Can you use a standard XMPP client with this setup?


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


I thought of a non durable exchange. One exchange per chatroom and one queue
per user.



>
>
>
> > 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'
>

All I know is that there are queues exchanges and bindings.
What do you mean by the pubsub system?


>
> > 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.
>

I meant to create bindings to all your online friends.
Can you explain how Paul's suggestion or exchange-exchange bindings solve or
improve it?

>
>
> > 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.
>

In that case will the server send the friendship request directly to the
queue?
Do you need another queue per user just for friendship requests or can you
use the same queue from above?


>
>
>
>
> > 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
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20090808/6652a8b5/attachment.htm