<font face="arial" size="2"><p style="margin:0;padding:0;">just my 2 cents... Rabbit on Android (iOS as well) is very easy to get up and running and is IMHO a very good fit. That said, getting reliable TCP connections over 3G can drive you batty...</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">You will need to implement heartbeat - very simple - to verify if the connection is alive as in our experience it is very difficult to maintain a connection over 3G. Pay close attention to error handling - specifically ShutdownSignalException.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">-----Original Message-----<br />From: "Tim Watson" <tim@rabbitmq.com><br />Sent: Thursday, November 15, 2012 3:58am<br />To: "Discussions about RabbitMQ" <rabbitmq-discuss@lists.rabbitmq.com><br />Cc: rabbitmq-discuss@googlegroups.com, "Michal Levý" <michal.liwoj@gmail.com><br />Subject: Re: [rabbitmq-discuss] RabbitMQ as communication server for mobile devices<br /><br /></p>
<div id="SafeStyles1352976950">
<p style="margin:0;padding:0;">Hi Michal,<br /><br />On 11/14/2012 04:49 PM, Michal Levý wrote:<br />> Hi everyone<br />><br />> I have following scenario:<br />> 1) Many Android clients (from 1000 to 10 000 clients) - not connected <br />> all the time (messaging seems like good fit for this)<br />> 2) Each sending max 100 messages\day<br />> 3) Also needs to send some messages back from server but not very <br />> frequently (10\day)<br />><br />> I was looking on rabbit tutorials, AMQP spec etc.<br />> It looks like collecting data from androids is easy task. All will <br />> send data into single exchange\queue.<br />> But what about sending messages to Androids from server?<br />> 1st i was thinking about having single queue and to subcribe from each <br />> device with some kind of "filter" (based on some header field). I know <br />> there are message brokers which support this scenario.<br />> But it seems Rabbit doesn't support this.<br /><br />It isn't hard to set this up in Rabbit! You will need to think about <br />solving the problem in AMQP terms though, which is admittedly a bit <br />different from what you'd do with say JMS or whatever.<br /><br />> Do i really have to create one "sending" queue for each client (using <br />> direct exchange with proper "per device" routing key) ?<br /><br />As a matter of fact, clients never send messages directly to queues, but <br />rather send them to exchanges (as you've already noted), after which <br />they're routed to zero or more queues based on the bindings you've set <br />up (between the exchanges and queues). So for example, you can send a <br />message to an exchange from one client and receive it on another a la <br />pub/sub by using a topic exchange. You can apply content based routing <br />using the headers exchange. If you've got data that needs to go out to <br />the devices then you first need to figure out what your filters look <br />like. Once these are in place, you can use one of the built in exchange <br />types to place the messages into the broker's care. Each device that <br />wishes to consume data can either create a temporary queue and bind it <br />to the exchange(s) in the right way, or connect to an existing queue <br />which is bound to a topic exchange for some set of keys that interest you.<br /><br />> How much overhead queues in rabbit have ?<br /><br />You can have lots (i.e., thousands) of queues without suffering too <br />much, though there is obviously *some* overhead (memory, etc) and its <br />worth planning your topology carefully so as to get the best out of <br />Rabbit. We can help with that (here) by pointing you to the right <br />resources and documentation, or if you want elaborate on some of the <br />finer details of the design we often have lively and interesting <br />discussions about how to solve various problems on this mailing list!<br /><br />Going back to something you mentioned at the beginning of your post:<br /><br />> It looks like collecting data from androids is easy task. All will <br />> send data into single exchange\queue.<br /><br />This really depends on what the whole messaging topology needs to look <br />like. Sometimes you need to propagate messages into various places, and <br />building blocks like fan-out and exchange-2-exchange bindings can help <br />with this. Other times, it actually makes more sense to send some <br />messages to a specific exchange and others to, well, another. As you're <br />making design decisions such as these, you'll want to consider various <br />factors which include performance and resource consumption on the <br />broker, scaling up/out (as you add more clients, potentially cluster the <br />broker and so on) and of course the management of all this <br />infrastructure, from the perspective of both the client application(s) <br />and the administration of the broker itself.<br /><br />> It can be also management issue and really feels like overkill when <br />> number of messages send from server to device is really low....<br />><br /><br />It's actually quite easy to set up a temporary, auto-delete (once the <br />client disconnects) queue that is used simply to bind to an exchange <br />that you're interested in. The semantics probably need some thought <br />however: how are you going to consume messages (e.g., round robin, <br />fan-out, etc), how will you know to delete them from the broker (using <br />acks, etc) and so on. This is where you need to think carefully about <br />your design. Either way, there shouldn't be much management to do if <br />you're using temporary queues to make consumption and guarantee that the <br />queues are deleted once you're finished with them (i.e., the client goes <br />away). If you're using long lived (shared) queues then the design <br />complexity pushes back into the exchanges and bindings you configure, <br />but that's done just once and then clients need to know where/how to <br />connect.<br /><br />> Any advice will be appriciated.<br /><br />If you've been through the tutorials, then hopefully it's clear that <br />consuming from a queue is relatively simple and that you have a number <br />of choices when it comes to 'filtering' what you receive. If you want to <br />go into a bit more detail about these 'filters' then we can look at <br />which topologies might best support your use cases.<br /><br />Cheers,<br /><br />Tim<br /><br />_______________________________________________<br />rabbitmq-discuss mailing list<br />rabbitmq-discuss@lists.rabbitmq.com<br />https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</p>
</div></font>