<div dir="ltr">Dear folks<div><br></div><div>I have a little bit of experience playing with both NDN and MQTT on a temperature sensor.</div><div><br></div><div>NDN is a request-response protocol.</div><div>The temperature must first register a prefix on the router before it could receive Interests. This step is quite difficult given the limited computation power on the sensor. (reply to <a href="http://www.lists.cs.ucla.edu/pipermail/ndn-lib/2016-May/000330.html">http://www.lists.cs.ucla.edu/pipermail/ndn-lib/2016-May/000330.html</a> if you have a good idea)</div><div>After getting past that step, the sensor just needs to respond to Interests.</div><div>If we want to continuously collect temperature readings, a separate program is needed to continuously send Interests to the sensor.</div><div><br></div><div>Although NDN allows multiple consumers to send Interests at the same time and the sensor only needs to process an Interest once, this capability is limited by the trust model.</div><div>To workaround computation power limit, my sensor signs Data packets with HMAC instead of RSA or ECDSA. Since HMAC uses pre-shared key, I cannot tell the world what the key is. If I want the world to trust the temperature readings, my data collection process must re-sign the Data packets with a RSA/ECDSA key. Therefore, the world would only trust the Data packets from the data collection process, not from the sensor.</div><div><br></div><div>MQTT is a pub-sub protocol over TLS.</div><div>Both the sensor and the data collection process connect to a MQTT broker. The sensor periodically pushes its temperature reading to the broker, which is then delivered to the data collection process who has subscribed to the sensor's MQTT topic.</div><div><br></div><div>A benefit of MQTT is that it uses less network bandwidth between sensor and broker. This is especially important if the sensor is connected over a slow and expensive cellular connection, although this may change when NDN has header compression.</div><div>A drawback of MQTT is that it replies on the sensor to control reporting frequency, and there isn't an easy way to get "the most current reading" between two reports (which is easy in NDN by sending another Interest). If the reports are too frequent, there's more bandwidth overhead and can lead to congestion; if the reports are too infrequent, subscribers cannot get an accurate "current" reading.</div><div><br></div><div>Finally, in terms of coding efforts, JSON over MQTT is much easier to program than NDN Interest-Data. But this may change when ndn-cpp-lite improves.</div><div><br></div><div>Yours, Junxiao<br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 23, 2016 at 4:18 PM, Wentao Shang <span dir="ltr"><<a href="mailto:wentaoshang@gmail.com" target="_blank">wentaoshang@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>My understanding of MQTT is that it simply specifies the messaging interface (wire format and send/receive operations), but does not prescribe the implementation detail of the message brokers, which IMHO is the most challenging part.<br></div><div><br></div><div><br></div></div></blockquote></div></div></div></div>