BTW - Thanks for the article reference.� That helped.<br><br>The only real disadvantage to AMQP is not monitoring<br>whether clients are present/active or not, and that<br>requirement is application specific.<br><br>- Jim<br>

<br>Jim Irrer� �� <a href="mailto:irrer@umich.edu">irrer@umich.edu</a>� � �� (734) 647-4409<br>University of Michigan Hospital Radiation Oncology<br>519 W. William St.� � � � � �� Ann Arbor, MI 48103<br>
<br><br><div class="gmail_quote">On Fri, Jan 28, 2011 at 7:51 AM, Jim Apperly <span dir="ltr">&lt;<a href="mailto:jim@rabbitmq.com">jim@rabbitmq.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<div class="gmail_quote"><div class="im">On 27 January 2011 19:25, Jim Irrer <span dir="ltr">&lt;<a href="mailto:irrer@umich.edu" target="_blank">irrer@umich.edu</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">



Would XMPP be more appropriate for this application?� I&#39;m not real<br>familiar with it but I&#39;ve heard that it has different strengths than AMQP.<br>I&#39;m interested in the pros and cons.<br clear="all"></blockquote>



<div><br></div></div><div>This may help shed some light:</div><div><a href="http://www.opensourcery.co.za/2009/04/19/to-amqp-or-to-xmpp-that-is-the-question/" target="_blank">http://www.opensourcery.co.za/2009/04/19/to-amqp-or-to-xmpp-that-is-the-question/</a></div>



<div><br></div><font color="#888888"><div>Jim</div></font><div><div></div><div class="h5"><div><br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

Thanks,<br>

<br>- Jim<br><font color="#888888"><br>Jim Irrer� �� <a href="mailto:irrer@umich.edu" target="_blank">irrer@umich.edu</a>� � �� (734) 647-4409<br>University of Michigan Hospital Radiation Oncology<br>519 W. William St.� � � � � �� Ann Arbor, MI 48103</font><div>



<div></div><div><br>
<br><br><div class="gmail_quote">On Thu, Jan 27, 2011 at 10:06 AM, Michael Bridgen <span dir="ltr">&lt;<a href="mailto:mikeb@rabbitmq.com" target="_blank">mikeb@rabbitmq.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">





Hi Kaiduan,<br>
<br>
Your questions suggest you&#39;re attempting something very interesting, which I would love to hear more about. �Federation and distribution are very much on our minds here at Rabbit Towers, as you might imagine.<br>
<br>
In the meantime ---<div><br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
1) Any user can subscribe to the interested topic, but only topic<br>
owner can publish message to the group. There is no limit on the<br>
number of subscribers in each group. Potentially it can be huge, for<br>
example, the fans of U2 around the world.<br>
</blockquote>
<br></div>
Is there anything that determines who can own topics? �For example, is it just the first person to declare a topic that is the exclusive publisher to that topic? �Can the publishing rights, so to speak, be handed to another publisher?<div>





<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
2) User including subscriber and publisher is not always connected to<br>
the system, and not always connected to the same node in the system,<br>
and the message delivery should be guaranteed. When publisher<br>
publishes a message, the system should deliver the message to all<br>
subscribers. If the subscriber is connected to the system, the message<br>
should be delivered immediately. If the subscriber is not connected,<br>
system should hold the message, and the next time the user comes<br>
connected, system will deliver the message to the user. Just imagine<br>
the user can be any mobile user and moves out of cellular coverage.<br>
</blockquote>
<br></div>
So far as I know, this is still an area of active research. �Typically, distributed pub/sub systems like Scribe and Hermes give rather weak guarantees of delivery and ordering and so on.<br>
<br>
In particular, &quot;If the subscriber is not connected, system should hold the message, and the next time the user comes connected, system will deliver the message to the user&quot; is difficult if the subscriber can connect to any node, and I don&#39;t think most pub/sub systems would allow that.<div>





<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
3) The system should be able to support tens to hundreds of millions<br>
users spreading around the world, so the system will consist hundred<br>
of nodes located in different physical locations.<br>
</blockquote>
<br></div>
This is rather ambitious. �But systems on this kind of scale are indeed being built: <a href="http://ci.oceanobservatories.org/" target="_blank">http://ci.oceanobservatories.org/</a> for instance.<div><br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
4) The number of topics/groups in the system is unlimited.<br>
<br>
5) As to the latency, it should be in the range of 1 minute if<br>
subscriber is connected.<br>
<br>
It looks like RabbitMQ already has functionalities to meet the above<br>
requirement, for example, fan out exchange, and persistent message.<br>
The following is my understanding on how to build the above system<br>
with RabbitMQ,<br>
</blockquote>
<br></div>
Perhaps, in the sense that it can be a building block. �But it doesn&#39;t fulfill all the requirements you&#39;ve given above, &quot;out of the box&quot;. �In other words, you (or we) would have to invent a substantial part of the technology.<div>





<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
a) Publisher creates an exchange. For example, U2 creates an exchange<br>
noted as &quot;U2&quot; for &quot;U2&#39;s next world wide tour&quot; on Node 1.<br>
<br>
b) Each subscriber creates a queue in the system. For example, Alice<br>
creates a queue noted as &quot;Alice&quot; on Node 2 and binds to exchange U2;<br>
and Bob creates a queue noted as &quot;Bob&quot; on Node 3 and binds to exchange<br>
&quot;U2&quot; on Node 2.<br>
<br>
c) U2 publishes a message, m1 on Node 1 to exchange &quot;U2&quot;; and RabbitMQ<br>
will deliver the message m1 to queue &quot;Alice&quot; on Node 2 and to queue<br>
&quot;Bob&quot; on Node 3.<br>
<br>
How we handles the following scenarios?<br>
<br>
1) When U2 wants to publish a message, but Node 1 is done.<br>
<br>
2) When message m1 is delivered to queue &quot;Alice&quot; on Node 2, Node 2<br>
crashed or the network link between Node 1 (publisher&#39;s node) is<br>
disconnected? Will exchange &quot;U2&quot; on Node 1 persist the message?<br>
</blockquote>
<br></div>
No; the message will be lost so far as Alice is concerned. �In AMQP terms, you&#39;re asking for queues to be replicated. �Rabbit doesn&#39;t do this, yet.<br>
<br>
(Actually, we are working on queue replication right now. �I think you would need both replication and some kind of queue migration or distribution.)<div><br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
3) After message m1 is arrived on queue &quot;Alice&quot;, but the connection<br>
between Alice and Node 2 is gone, the message will be stored on Node<br>
2, right? Next time, Alice connects to the system, but she is<br>
connected to Node n instead of Node 2, how to handle this?<br>
</blockquote>
<br></div>
In Rabbit&#39;s clustering as it works now, the messages will be delivered across the cluster to Node n.<div><br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
4) What is the multi-cast technology used in RabbitMQ to deliver the<br>
message to queues located on different locations spreading around<br>
different countries?<br>
</blockquote>
<br></div>
There isn&#39;t any right now. �Clustering is really for nodes that are co-located and have reliable connections. �It uses Erlang&#39;s distribution mechanism, which essentially forms a fully-connected graph of nodes. �It doesn&#39;t really scale beyond a handful of nodes.<br>






<br>
There /is/ a plugin called the &quot;shovel&quot;, which will relay messages from one broker to another. �However, it is statically configured, and constrained by using AMQP to do the relaying (i.e., you cannot tell it to relay all messages from a direct exchange; only to relay, e.g., messages with a particular routing key).<br>






<br>
<br>
Regards,<br><font color="#888888">
Michael</font><div><div></div><div><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="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
</div></div></blockquote></div><br>
</div></div><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="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
<br></blockquote></div></div></div><br>
</blockquote></div><br>