User login

Weekly Report

30

Apr

2012

Had a meeting with Richard and Brendon on Monday. It ended up being a fairly long discussion given I hadn't made up my mind too much. The plausible choices seem to be: running an AMQP broker in federation on each node, improving the existing system; or possibly MQTT but authentication is an issue. So, this week I looked at the cost of an AMQP broker - RabbitMQ needs around 40MB of Erlang VM, Qpid is around 10MB total including the client libraries. I also looked at exactly how federation works with Qpid and it seems feasible, but I'm worried about it using a different version of AMQP than everyone else (0.10) - losing most of the benefits of AMQP anyway (which are moot given the standard is changing).

The main issue with the current system (apart from being custom) was identified in the meeting to be unreliability in the client side persistence, so I've started having a look at libraries for that that are known reliable (the main choices seem to be embedded databases). A good option may be to integrate that and use something like the STOMP protocol for ease of interoperability (and possibly a 3rd party STOMP broker).

MQTT (designed for low power) authentication built in to the protocol is indeed plain text and only on connection so not at all useful, but I did find an ActiveMQ Apollo MQTT plugin that does support SSL; and confirmed the main open source MQTT client has built-in client-side persistence.