[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [m2m-iwg] General MQTT Protocol Question
|
On Tue, May 29, 2012 at 2:51 PM, Rick Bullotta
<rick.bullotta@xxxxxxxxxxxxx> wrote:
Hi, all.
We’re experimenting with and exploring MQTT and had a couple of questions. Might as well go right to the experts!
· Does the protocol indicate that a “subscribe” request will always trigger an initial notification of the last known value for a topic?
Only if the last message on that topic was a retained publication.
· If not, is there any way to force a synchronization from the client?
No - the idea of publish/subscribe is that both parties should be unaware of the other.
· Are there any thoughts to supporting an alternative, more browser-friendly client protocol layer (probably on top of web sockets) and using JSON as the wire format?
Not sure about JSON as the wire format specifically, but various folks have played with web sockets and MQTT - Googling should find you a couple of examples. I don't know whether this is something that specifically needs to be built in to the specification, after all... MQTT is MQTT and web sockets are web sockets... not to say something in the middle should not enable interop between them, of course.
· Are there any testing metrics available that give some guidelines/limitations for scalability and performance? (impact of # of topics, # of clients, # of connections, frequency of publications/notifications, etc.)
IBM's WebSphere MQ supportpacs include performance reports which refer to these kinds of metrics for their commercial implementation.
· Any known implementations with clustered servers for failover/scalability purposes?
This kind of thing is often done using bridged topics between brokers, etc. Again, you'll probably find people more familiar with specific implementations on the MQTT Google Group, more so than the Eclipse M2M IWG list as the discussions here are slightly more broad than just the protocol. You'll also find some very specific questions being asked about the protocol over there just at the moment! Another good resource is the MQTT.org wiki where details which are not clear from the protocol specification are being gradually documented
http://mqtt.org/wiki/doku.php/mqtt_protocol
· Any thoughts to discovery APIs to enable client(s) to discover available topics?
There are certainly thoughts about discovery of brokers using e.g. Bonjour / DNS discovery. The HTTP/MQTT bridge app that Nicholas Humfrey wrote and which is running at
http://m2m-eclipse.cloudfoundry.com will list the topics available on the mosquitto broker running at
m2m.eclipse.org (a more interesting / populated example is at
http://test-mosquitto.heroku.com), so it's not impossible to "walk" a topic tree... although my view is that an API to discover that kind of thing belongs in the client library, and not as part of the protocol.
MQTT is something that I typically compare with the UNIX philosophy of doing one thing, and doing that thing well - and interoperating with other things very simply. That's one reason why it has remained simple, lightweight, and easy to adopt.
Just my 2c.
Andy
--
Andy Piper | Farnborough, Hampshire (UK)
blog:
http://andypiper.co.uk | skype: andypiperuk
twitter: @andypiper | images:
http://www.flickr.com/photos/andypiper
