Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mosquitto-dev] [paho-dev] Java MQTT broker

Yes it would be cool :-)

We don't have to have standardization for this - experiment to see what works well, and then standardization might follow, if appropriate.


On 25/01/14 10:47, Andrea Selva wrote:
Defining bridging protocols and provide some MQTT networks monitoring
and management tools is great idea!


On Fri, Jan 24, 2014 at 11:10 AM, Paul Fremantle
<paul.fremantle@xxxxxxxxxx> wrote:
There is some early support for TLS-SRP in bouncycastle which is one of most
used open source implementations in Java.


On 23 January 2014 23:34, Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx>
Hi Roger,

On 23/01/14 22:03, Roger Light wrote:
Hi Ian,

The goal of RSMB, and I
believe Mosquitto (Roger, correct me if I'm wrong) is to be smaller
than faster.  (If it can be both small and fast, so much the better!)
This is basically correct and I think a good focus for the project. I
do take a subtly different approach with Mosquitto which is to not shy
away from adding features, but to make sure that they can be removed
at compile time to ensure it is always possible to create a lean
Your approach is perfect from my point of view.

In any case, I'm in favour of Andrea contributing Moquette.
  From what Andrea says we are aligned in our goals, so I agree.

How close do we want interoperability/equivalency of the
Mosquitto/Moquette to extend? A few examples - I provide support for
TLS-PSK and will support TLS-SRP in the future. Neither of these are
particularly widely used but are definitely useful. I'm not sure if
they are easily available in the Java libraries, so should Moquette
strive to provide support as well? Should they have a common config
file format? I have been talking for a while now about moving away
from the current flat file format to a lua based config file, and then
extending to allow lua plugins in the future. There are also some
options which may be more C oriented (the auth plugins for example)
that wouldn't make sense in the Java context.

My feeling is that neither of these points should be a sticking point.
I'd be interested to hear your thoughts around the area.

My thoughts are ...  I would advocate compatibility where it helps the
different brokers collaborate in MQTT networks.  Where the function does not
affect collaboration, by all means use the best available for that platform,
or experiment.

For example, supporting different flavours of TLS is great.  As long as
both allow TLS clients to connect at some common level it's fine.  As long
as we can bridge from one broker to another with a TLS connection of some
kind, it's fine.

Where I would suggest compatibility:

- bridging protocols (including where brokers might exchange useful system
- a significant proportion of monitoring topics (because you could monitor
whole networks of brokers easily)
- the format of system error/log messages, alerts and events (again
because you could monitor whole networks)
- remote admin method (so you could administer whole networks of brokers)

Where it might not matter:

- initial configuration (but what if you wanted to deploy networks of
- plugin interfaces (like security).  If the plugins have to be written in
C for Mosquitto and Java for Moquette for instance, it doesn't really matter
if the interfaces are different, and following the standard for the platform
could make more sense.  If you could use the same language for both, the
balance could swing.


mosquitto-dev mailing list

Paul Fremantle
Part-time PhD student - School of Computing
email: paul.fremantle@xxxxxxxxxx, paul@xxxxxxxxxxxxx
twitter: pzfreo / skype: paulfremantle / blog:
CTO and Co-Founder, WSO2
OASIS WS-RX TC Co-chair, Apache Member
07740 199 729

mosquitto-dev mailing list

mosquitto-dev mailing list

Back to the top