<div dir="ltr"><div class="gmail_quote"><div class="im">On Fri, Aug 7, 2009 at 12:52 PM, Alexis Richardson <span dir="ltr"><<a href="mailto:alexis.richardson@gmail.com" target="_blank">alexis.richardson@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Ben,<br>
<br>
Further to your email exchanges with Paul...<br>
<div><br>
On Thu, Aug 6, 2009 at 3:32 PM, Ben Browitt<<a href="mailto:ben.browitt@gmail.com" target="_blank">ben.browitt@gmail.com</a>> wrote:<br>
</div><div>> Hi,<br>
><br>
> I'm trying to understand how AMQP and RabbitMQ works by building a simple<br>
> chat.<br>
<br>
</div>Cool :-)<br>
<div><br>
<br>
> From reading the AMQP specs I get the impression that it's best usage is<br>
> when someone publish content to an exchange<br>
> and someone else bind his queue to this exchange to get updates. This model<br>
> works very well for publish-subscribe<br>
> and to finance systems but chat could be different.<br>
<br>
</div>I think chat is a very natural application of AMQP. �The benefit of<br>
using XMPP would be to integrate with existing chat infra in a<br>
standard way, but that does not prevent you from using an AMQP based<br>
implementation underneath.<br>
<br>
Do you want to do MUC or IM?</blockquote></div><div><br>I'm not actually building it.<br>I keep hearing about AMQP and RabbitMQ so I read the spec and the server docs.<br>I couldn't find use cases on the web so I thought I'll try to fit the protocol to a fun application.<br>
�<br></div><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
In fact, you can use a single approach to both.<br>
<br>
One approach is to have one queue per consumer 'chat window' and one<br>
exchange per 'chat room'. �The queue is bound to the exchange when the<br>
user is in the chatroom. �Then, IM is a special case of MUC - it is a<br>
chatroom with two participants.<br>
<br>
Another approach would be to have one queue per consumer, and have<br>
that queue bound to the exchange(s) N times, where N is the number of<br>
chatrooms (or IMs) which the consumer is currently in. �In this<br>
approach, you will need to identify which message came from which<br>
room, before you show the messages to the user. �That's easy but it's<br>
extra work and data to carry around.<br>
</blockquote></div><div><br>When a client sends a message to another client he usually doesn't create a chatroom for two,<br>
he just sends the message and the server routes it. With your suggestion the server will create<br>
the room if it doesn't exists when it needs to route a message.<br>
When all the users leaves a MUC room if it is not persistent the server destroys it.<br>
What will be the case with a chatroom with two participants?<br>
Maybe the server will destroy it when both users are offline?<br>Is there a way to destroy an exchange if it is not active for several minutes to save memory?<br>Can you use a standard XMPP client with this setup?<br>�<br>
</div><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Let me know if you want more detail on either of the above, eg which<br>
exchange type to use.</blockquote></div><div><br>I thought of a non durable exchange. One exchange per chatroom and one queue per user.<br><br>�<br></div><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<div><br>
<br>
> I read the xmpp gateway<br>
> docs and have some questions.<br>
><br>
> In a chat we want to be able to get presence from users on our friend-list,<br>
> send them messages<br>
> and send subscription request and messages to users not yet on our<br>
> friend-list.<br>
<br>
</div>Do you only want to enable chat when both users are online and have a<br>
'friend' relationship?<br>
<div><br>
<br>
> One possibility is that each user will have an exchange and a queue with<br>
> binding to his own exchange.<br>
> When user1 wants to send a message to user2 he send it directly to the<br>
> exchange of user2.<br>
> There is a problem with presence updates. If user1 changes his presence,<br>
> he'll have to�sends the update<br>
> to the exchange of all the users�on his friend-list. With this design we<br>
> move the logic to the client rather then use the AMQP features.<br>
<br>
</div>One approach to presence is to broadcast changes using the pubsub<br>
system. �Changes could include:<br>
<br>
* User goes online / offline<br>
* User changes their 'status message'<br>
</blockquote><div>�</div></div><div>All I know is that there are queues exchanges and bindings.<br>What do you mean by the pubsub system? <br><br></div><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><br>
<br>
> Another option is that when a user logs in he'll create a binding to the<br>
> exchanges of all the users on his friend-list.<br>
<br>
</div>You can do this but it creates quite a lot of churn on the exchange<br>
layer. �Paul's suggestion is one way to prevent that. �Another is to<br>
use exchange-exchange bindings, which we are also looking at.<br>
</blockquote></div><div><br>I meant to create bindings to all your online friends. <br>Can you explain how Paul's suggestion or exchange-exchange bindings solve or improve it? <br></div><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><br>
<br>
> When user1 want to send a private message or a presence update to user2<br>
> he'll send it to his own exchange and it'll be directed to user2. The<br>
> problem with this design is that users without mutual presence subscription<br>
> can't send private message to each other and can't send subscription<br>
> requests.<br>
<br>
</div>You can decouple presence, which is about status updates, from<br>
friendship. �If you like, you could have a set up where one user can<br>
DM another, provided they are mutual friends, regardless of who is<br>
online. �Do you want that?<br>
<br>
Subscription requests could also be implemented using a queue - one<br>
per user. �Whenever a new user wishes to request mutual friendship<br>
with user A, then user A could be notified of this via a queue.<br>
</blockquote></div><div><br>In that case will the server send the friendship request directly to the queue?<br>Do you need another queue per user just for friendship requests or can you use the same queue from above?<br>
�</div><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><br>
<br>
<br>
<br>
> Can you please share your thoughts on the two options and maybe other design<br>
> options?<br>
<br>
</div>I've tried to shed some light on some of the issues above. �Feel free<br>
to elaborate on your needs and ask more questions.<br>
<font color="#888888"><br>
alexis<br>
</font><div><div><br>
<br>
<br>
<br>
<br>
> Thanks<br>
> _______________________________________________<br>
> rabbitmq-discuss mailing list<br>
> <a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">rabbitmq-discuss@lists.rabbitmq.com</a><br>
> <a href="http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
><br>
><br>
</div></div></blockquote></div></div></div>