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

There is some early support for TLS-SRP in bouncycastle which is one of most used open source implementations in Java.

Paul


On 23 January 2014 23:34, Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
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 rather
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
executable.
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 information)
- 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 brokers?)
- 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.

Ian



_______________________________________________
mosquitto-dev mailing list
mosquitto-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mosquitto-dev



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

Back to the top