device-mqtt ProtocolDriver *Handlers* connect to broker on each request about device-mqtt-go HOT 4 CLOSED

This design is come from Java version, maybe we need more real device or use case to improve the device-mqtt.

Like this real device, it can't integrate with device-mqtt because it publishes and subscribes readings via different topics.
http://ftp.icpdas.com/pub/cd/mq-7200m/document/mq-7200m_user_manual_english_v100.pdf

And it didn't support Get command to handle request and send response.

from device-mqtt-go.

@tonyespy
Connection pool mechanism would be the way to resolve this issue. However, this is just a sample implementation. We need some help to implement this if it's necessary.

from device-mqtt-go.

I've just done a more thorough review of device-mqtt and its current usage of MQTT. I'm going to use this comment to document my findings, however as some of the issues I've discovered should be considered separate bugs, I will open new issues for each, as this issue is really just about how each new command received from EdgeX triggers a new client connection to be opened, and then closed after the command has been sent.

The MQTT device service implements asynchronous readings and also supports command actuation from EdgeX.

The [Driver] configuration stanza defines a set of Incoming* configuration values (including Host, Port, Topic, ClientId, ...) and a set of Response* configuration values (same set as for Incoming). Each device also includes configuration values for its own Command* MQTT broker configuration within the ProtocolProperties struct.

The service's ProtocolDriver.Initialize() method creates separate client connections for incoming data and response messages. If this method saved the corresponding connections to its ProtocolDriver struct, the HandleRead/Write*Commands methods could use an existing connection vs. creating and closing connections for every command received by the service (either directly or via Core Command).

As I mentioned there are other issues with this implementation:

• Why does it support different brokers for commands vs. [command] responses?

• Why does it support per-device broker configuration?

• This service can at any one time have up to 3 MQTT connections at one time. My gut tells me that most of the time, these would all point to the same broker, which means the service is generating 3x the number of pings to the same broker. I question whether there are real world scenarios where a single instance of device-mqtt would need to be configured to point to different brokers for command and data ingestion. That said, it's supported now, so I don't think we can remove it, however I would like to see the code optimized to use a single connection if all three configurations point to the same broker.

• Finally, it looks like there's no support for secure connections (e.g. TLS) in the current implementation. This means username/password are being transmitted in cleartext when this service attaches to the broker see issue #157 for more details.

from device-mqtt-go.

@tonyespy
Connection pool mechanism would be the way to resolve this issue. However, this is just a sample implementation. We need some help to implement this if it's necessary.

I'm not sure what you mean by sample implementation? I would instead call it a reference implementation, and as such, we should strive to make it robust and usable for production scenarios. IMHOP if it's just sample code, it belongs in edgex-examples (or the example folder in device-sdk-go).

from device-mqtt-go.