Two instances of client, the one who publish disconnect after every pub

[matteoPhre]

Hi all! First of all, congratulations for the extraordinary work you do and keep doing. I have got a problem: I want to instantiate two clients that connect to two different brokers (the first gets the messages, the second ones publish the message after aggregations and manipulations). The problem is that the second one, every time it publishes a message, disconnects and reconnects.

These are the options I use to instantiate the two clients.

"options": {
        "port": 18883,
        "host": "tcp://192.168.3.77",
        "username": "*******",
        "password": "*******",
        "clientId" : "gw__dev-************",
        "protocolId": "MQIsdp",
        "protocolVersion": 3
    },
    "thingOptions": {
        "port": 8883,
        "host": "mqtts://",      //host url is built from other params
        "username": "********",
        "password": "***********",
        "clientId" : "thing__dev-************",
        "protocolId": "MQIsdp",
        "protocolVersion": 3
    }

What could be the mistake? Thanks for collaboration

Matteo

[mcollina]

I think your username/password/clientId combination has no right to publish to the second broker.

[RangerMauve]

Do you have logs from your second broker that might indicate why the client is disconnecting?

[matteoPhre]

@mcollina No, I'm actually able to send messages. I can see the messages published in the cloud platform. @RangerMauve Is possible to enable full log on mqtt?

[RangerMauve]

Sadly the MQTT protocol doesn't give any readable logs when things go wrong, so errors are better tracked in the broker's logs.

Can you show us the code you're using for publishing the messages?

[matteoPhre]

I can not check logs because I do not have control. I can only see published data that reach the broker in the cloud, and actually, they arrive.

I have wrapped mqtt.js into two support classes (one for each broker) that call simply:

1. this.client.publish(topic, JSON.stringify(message));

2. this.clientThing.publish(topic, JSON.stringify(message));

[RangerMauve]

Could you post more of the code to do with cleintThing? It's hard to analyze what's happening with just that. Do you have any errors that pop up when it disconnects? Can you show us the code you have that detects that the client has disconnected?

[matteoPhre]

@RangerMauve I can see that second client disconnect from listeners on 'offline','disconnected','reconnecting' that logs simple messages. I cannot check what goes wrong. I'm asking at Cloud Platform Owner to give me access to check logs.

[matteoPhre]

FYI I've fixed the issue with these configs:

"options": {
        "port": 18883,
        "host": "tcp://***.***.*.*",
        "username": "admin",
        "password": "*****",
        "clientId" : "mqttjs_gw",
        "protocolId": "MQIsdp",
        "protocolVersion": 3
    },
    "thingOptions": {
        "port": 8883,
        "host": "mqtts://",
        "username": "dev-******",
        "password": "********",
        "clientId" : "mqttjs_thing",
        "protocolId": "MQTT",
        "protocolVersion": 4,
        "keepalive": 120,
        "clean": true,
        "reschedulePings": true,
        "connectTimeout":30000,
        "reconnectPeriod":1000
    }

Now the client is always connected, even after publication. Thanks anyway for the support.

M.

[RangerMauve]

Glad you figured it out! Any idea what the problem was in the end?

[simonbuchan]

MQTT requires brokers to disconnect on protocol violations, including invalid connect packets: http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc398718110

Specifically, conack 3.2.2.3 has:

If none of the return codes listed in Table 3.1 – Connect Return code values are deemed applicable, then the Server MUST close the Network Connection without sending a CONNACK [MQTT-3.2.2-6].

For some reason, AWS IoT treats unauthorized packets by dropping the connection rather than a non-zero return code conack, probably for symmetry due to [puback 3.5.5]:

If a Server implementation does not authorize a PUBLISH to be performed by a Client; it has no way of informing that Client. It MUST either make a positive acknowledgement, according to the normal QoS rules, or close the Network Connection [MQTT-3.3.5-2].

So it's likely to be something similar with OP's broker.

So MQTT.js should probably treat dropped connections after connect but before receiving a conack as a connection rejection, and definitely shouldn't retry indefinitely, and possibly should be careful about reconnecting before getting a puback.

[github-actions[bot]]

This is an automated message to let you know that this issue has gone 365 days without any activity. In order to ensure that we work on issues that still matter, this issue will be closed in 14 days.

If this issue is still important, you can simply comment with a "bump" to keep it open.

Thank you for your contribution.

[simonbuchan]

Can I get a position on my response above, at least? To my knowledge the behavior here hasn't changed.

[github-actions[bot]]

This is an automated message to let you know that this issue has gone 365 days without any activity. In order to ensure that we work on issues that still matter, this issue will be closed in 14 days.

If this issue is still important, you can simply comment with a "bump" to keep it open.

Thank you for your contribution.

[robertsLando]

@simonbuchan Wants to send a PR?

[simonbuchan]

@robertsLando sorry if my last reply seemed shitty! I only meant in reply to the stale tag getting added if this was indeed considered a valid issue and that my suggested behavior seemed a reasonable fix.

It's been a while, but I do remember attempting to do a PR, but I couldn't follow the startup logic well enough to have any confidence I wasn't going to be making things worse. As a part of trying to figure it out, I ended up just reimplementing the small part we actually used with much simpler code that fit better into our codebase, so we don't even have this as a dependency any more (I do this a lot. I consider it a character flaw)

In other words, no, not really, sorry 😞