<div dir="ltr">Gday Emile<div><br></div><div>I am working on moving an IoT platform from a custom TCP protocol across to MQTT, the aim is to provide a combined topic structure for these devices partitioned by a user identifier then a group or zone identifier.</div>
<div><br></div><div>We have in home and cloud services, with a range of topics used by either end.</div><div><br></div><div>Incoming messages to the central cloud services, which are sent from the in home gateway are organised under $cloud base, note variable params are signified by []:</div>
<div><br></div><div>$cloud/[userid]/[zoneid]/[gwid]/config</div><div>$cloud/[userid]/[zoneid]/[gwid]/status<br></div><div><div>$cloud/[userid]/[zoneid]/[gwid]/events<br></div></div><div><br></div><div>$cloud/[userid]/[zoneid]/[gwid]/device/[deviceid]/...<br>
</div><div><br></div><div>Outgoing to the gateway, these are subscribed to by the software on the device.</div><div><br></div><div>$gw/[userid]/[zoneid]/[gwid]/config</div><div>$gw/[userid]/[zoneid]/[gwid]/commands<br></div>
<div><br></div><div><div>$gw/[userid]/[zoneid]/[gwid]/device/[deviceid]/...<br></div></div><div><br></div><div><br></div><div>Now given that each gateway authenticates using a username and password the types of rules we are looking for are very similar to those currently present in RabbitMQ, for AMQP.</div>
<div><br></div><div>Restrict write access to the outgoing topics $cloud/[userid]/[zoneid]/[gwid]/.* for a given user.</div><div>Restrict read access to the incoming topics $gw/[userid]/[zoneid]/[gwid]/.* for a given user. </div>
<div><br></div><div>The aim here is to keep a given user constrained to a part of the topic structure.</div><div><br></div><div>The reason I am keen to continue using RabbitMQ is it has done a sterling job of knitting together a number of internal services, most of which connect using AMQP, using either amqplib by Michael Bridgen or the golang AMQP library by Sean Treadway.</div>
<div><br></div><div>Outside our core I am keen to use MQTT as: </div><div><br></div><div>- the gateway devices are in a lot of cases are on consumer wireless networks</div><div>- in some cases these will be micro controllers such as Arduinos</div>
<div>- mostly non x86, so arm and mips based systems.</div><div><br></div><div>Hopefully that gives you some insight into what I am hoping to achieve.<br></div><div><br></div><div>Cheers</div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Tue, Jan 7, 2014 at 7:29 PM, Emile Joubert <span dir="ltr"><<a href="mailto:emile@rabbitmq.com" target="_blank">emile@rabbitmq.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Hi Mark,<br>
<div class="im"><br>
On 07/01/14 07:38, Mark Wolfe wrote:<br>
> Interested to hear if anyone intends to add ACL support to the MQTT module?<br>
><br>
> At the moment it is built around routing keys which as i understand<br>
> cannot be controlled by the existing ACLs.<br>
<br>
</div>There are no immediate plans to grant permissions on individual topics.<br>
That is because the feature barely mentioned in the current<br>
specification, and also because it has no equivalent in AMQP.<br>
<br>
Can you describe your use-case in more detail? This will help us to<br>
determine which features to include.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
-Emile<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>Regards,<br><br>Mark Wolfe<br><br>--<br>I am not young enough to know everything.<br>--
</div>