MIMIC MQTT Simulator driving a IoT demo at Cisco Live

If you are planning to attend Cisco Live next week, take a look at a
dynamic IoT platform demo. You will see a cruise ship with dynamic,
real-time cabin temperature and door lock sensors simulated by
MIMIC MQTT Simulator.

Here you see a drill-down to a particular sensor:

Update 6/12/2019: Here is a tweet to a video at the show.

MIMIC MQTT Simulator: dynamic, scalable device shadows on AWS IoT

This 2-minute Youtube video shows multiple, independent device shadows
updating from MIMIC MQTT Simulator to Amazon AWS IoT with dynamic,
real-time,  predictable, scalable values.

MIMIC allows to quickly create on-demand prototypes and proof-of-concepts for
your particular IoT Application based on AWS IoT device shadows.

Update 12/04/2019:

Our AWS IoT Get Started Tutorial Lab  allows you to get started with
AWS IoT Core in a matter or minutes, learning and experimenting quickly.

Update 2/24/2020:

Here is a video testing AWS IoT Rules.

MIMIC Simulator integrated with Telegraf OSS monitoring application

What better way to quickly develop / test / prototype Telegraf deployments
than with simulated data? MIMIC Simulator delivers the dynamic,
customizable, scalable data for the variety of Telegraf input plugins.

To exercise SNMP interoperability, for this experiment we graph real-time
interface statistics from a simulated Cisco ASR 9000  router.

The graph in Grafana shows ifInOctets SNMP data collected from the MIMIC
simulated Cisco ASR 9000. The data is collected by the Telegraf application
using the SNMP plugin, and output to InfluxDB. Grafana is showing the data
using the InfluxDB as data source.

The Telegraf, InfluxDB and Grafana setup was done using this link:

https://lkhill.com/telegraf-influx-grafana-network-stats/

MIMIC implements MQTT 6

Skipping the latest MQTT 5, MIMIC MQTT Simulator now supports the
yet-to-be-defined MQTT 6 standard.

Happy April Fool's Day!

In all seriousness, MIMIC is the first MQTT 5 simulator to implement the
latest MQTT 5.

Try it out at http://mqttlab.iotsim.io/mqtt5/

MQTT 5 Testing

MQTT 5.0 is the next version of the ISO standard MQTT 3.1.1 Internet
of Things protocol.

We used the latest version of MIMIC MQTT Simulator to test several MQTT
brokers with MQTT 5 support, and in a short time have discovered some
differences in protocol behavior between them.

Test 1 - CONNECT with Maximum Packet Size set to low value

In the case of 0, one broker disconnects immediately, and the other sends a
CONNACK with Reason Code. In this case, the spec clearly says

It is a Protocol Error to include the Maximum Packet Size more than once,

or for the value to be set to zero.

Both behaviors are legal, since protocol errors must result in disconnect, but
at the discretion of the server it may send a CONNACK with reason code, as
detailed here.

Curiously, if the value is 10, again one broker disconnects immediately, but
the other does not send anything, presumably because the CONNACK would
have violated the limit. This results in a timeout at the client.

Test 2 - PUBLISH with empty topic name and no topic alias

In this case, one broker disconnects and the other sends PUBACK with
Reason Code. In this case, the spec clearly says

It is a Protocol Error if the Topic Name is zero length and there is no Topic Alias.

Protocol errors must result in disconnect as detailed here.

Test 3 - PUBLISH to wildcard topic

For example, to handle the error of a PUBLISH with QOS = 1 to an illegal
wildcard topic, one broker returns a PUBACK with the Reason Code of 0x90,
whereas another returns a DISCONNECT with that Reason Code. This
behavior is expected with QOS 0, but since it is not defined as a protocol
error, for QOS 1 and 2 the PUBACK and PUBREC response should be used.

This is what our logs show:


INFO  02/06.10:58:25 - MQTT[AGT=1] - sent PUBLISH (110 bytes)
INFO  02/06.10:58:25 - MQTT[AGT=1] - rcvd PUBREC rc=0x90 Reason String The topic is not valid: ...

vs.

INFO  02/06.11:01:25 - MQTT[AGT=1] - sent PUBLISH (110 bytes)
INFO  02/06.11:01:25 - MQTT[AGT=1] - rcvd DISCONNECT reason 0x90 (Reason String PUBLISH with wildcard character (#/+) was sent.)

Test 4 - PUBLISH with Payload Format property

For a PUBLISH with property Payload Format set, the spec says

A Server MUST send the Payload Format Indicator unaltered to all
subscribers receiving the Application Message [MQTT-3.3.2-4]

One of the brokers discards the Payload Format Indicator property if it is 0.
If this property is missing, it can be assumed to be 0. While not breaking
anything, this is technically incorrect.

Test 5 - Shared vs. non-shared subscriptions

The new shared subscriptions allow multiple subscribers to receive mutually 

exclusive subsets of the messages of a particular topic filter. This 90-second 

YouTube video illustrates the behavior

Conclusion

Since MQTT 5 is so recent, you need to test many features of your selected
MQTT brokers and IoT applications with different scenarios to mitigate
costly surprises before deployment. MIMIC MQTT Simulator can really help
with that.

Real-time telemetry throttling demo for MQTT.Cool

MQTT.Cool is a web gateway that you put in front of any MQTT broker to
boost its security, performance, and architecture. It allows IoT applications
to connect to your MQTT broker from anywhere on the Internet, even behind
the strictest corporate firewalls and proxies, without sacrificing security.
MQTT.Cool will automatically throttle the data flow for each client, to adapt
to any network congestion. Simply put, MQTT.Cool's unique feature
of optimizing the real-time data flow, rather than forwarding it as a dumb
pipe, is one of the biggest advantages for a Customer's application.

What better way to demonstrate its features than to create an online
demo page that lets you visualize and interact with a sample client?
The open-source client lets you control throttling globally or individually
to see the effect on the data.

The real-time data is generated by MIMIC MQTT Simulator with arbitrary,
customizable, scalable, predictable telemetry. We deployed 10 sensors on
our MQTT Lab to generate a variety of telemetry patterns that is throttled
by MQTT.Cool.

400,000 MQTT connections to IBM MessageSight for real-time performance testing

As part of our MQTT broker and IoT Platform testing program, we had
previously connected 100,000 simulated connections to IBM MessageSight.

Now, with the latest MIMIC MQTT Simulator 18.10 running in Docker
instances on 2 VirtualBox VMs (16GB RAM and 4 CPUs each), we managed
to start 200,000 simulated sensors connecting to IBM MessageSight 2.0 in
under 15 minutes.

Contrary to the prevailing testing methodologies, where either dummy
MQTT sessions are opened (not doing anything other than maintaining
the session with PING responses), or the vast majority of clients subscribe
rather than publish, each of our clients simulates a sensor publishing
telemetry. To test the actual performance of the topic switching, you can
now add your expected number of subscriber on the expected topic
hierarchies.

With this fast turnaround we can now do timely investigation of the
real-time performance impact of other variables such as:

1) unencrypted vs. TLS

2) varying message frequency

3) varying payload sizes with arbitrary content (JSON, binary, etc)

4) different QOS levels

5) varying topic hierarchies

6) varying subscription levels

7) impact on end-to-end latency

As always, each of the 200,000 sensors can be controlled individually or in
a group in real-time to affect payload contents, payload frequency,
connection status to verify handling of pathological conditions by the
IoT platform.

Update 1/8/2019: We have achieved 300,000 simultaneous connections.
Do you see where this is going?

Update 1/29/2019: We have achieved 400,000 simultaneous connections
on the newly released MessageSight 5.

Update 6/1/2022: MessageSight is now open-sourced as Eclipse Amlen