Great working ! How to check the current number of clients connecting to this mqtt?

[TridentTD]

I have just tried on ArduinoIDE by default libmqtt.a, and use mosquitto's clients connect to this mqtt-broker. I have found that it can connect 10 clients, if more than it will be WDT's restart.

I want to count the number of clients by this mqtt server for limitation and prevent WDT.

How can I count the number of clients by this mqtt server ?

Thank you.

[martin-ger]

Up to now, there is no clean API to get this info from the lib. But thank you for the request. As I think about it, I understand, it would be highly useful to track this number an to allow for an upper limit on the number of concurrent mqtt clients. Will work on this ... now.

[martin-ger]

Try now: MqttConnectCallback now has a second parameter giving the number of currently connected clients (incl. the current request).

Also the complete server software has a config param "broker_clients" defining the max number of currently connected clients (any additional request will be rejected).

[TridentTD]

Thank you. ^^

I will wait,
and if I want to deny the current mqtt client that is over limitation, this following code is correct ?

#define MAX_CLIENTS   8

bool ConnectCb (struct espconn *pesp_conn, uint16_t client_count) {
    if( client_count > MAX_CLIENTS ) {
        espconn_disconnect(pesp_conn);
        return false;
    }
    return true;
}

void user_init() {
    //... after  WiFi connection ..

    MQTT_server_onConnect( ConnectCb );
    MQTT_server_start(1883,30,30);

}

[martin-ger]

It's even simpler: just return false from the callback and the lib will do the clean disconnect.

[TridentTD]

Thank you .

[TridentTD]

I have found a problem about the second parameter "client_count" of MqttConnectCallback .

Scenario : When a mqtt-client be disconnected by wifi-disconnection and reconnect to uMqtt Broker when wifi-reconnection. If the same client-id reconnect , the uMqtt Broker will still count plus one more again.

This situation makes uMqtt Broker easy to full of connect-limitation, then the same client-id will can't connect again.

Wish the broker doesn't count plus one more, if the same client-id reconnect.

[martin-ger]

Fixed that: now all open clients are closed on STA disconnect. Also, the lib now automatically checks, whether there is enough heap left to open a new client - if not, it will reject it without even asking the callback.

[martin-ger]

Sorry, wrong - not the lib does this, but the broker in user_main.c. The lib still needs an API for cleanup on STA disconnection...

[martin-ger]

Now: If you want to force a cleanup when the broker as a WiFi client (WIFI_STA mode) has lost connectivity to the AP, call:

void MQTT_server_cleanupClientCons();

This will remove all broken connections, publishing LWT if defined.

[TridentTD]

This API , Can I use like this ?

#define MAX_CLIENTS   8

bool ConnectCb (struct espconn *pesp_conn, uint16_t client_count) {
    MQTT_server_cleanupClientCons();
    if( client_count > MAX_CLIENTS ) return false;
    return true;
}

[martin-ger]

This is too late - here the count is already done.

You should call it from your program, when you are aware, that the WiFi Status has become WiFi.status() != WL_CONNECTED.

[TridentTD]

OK, I got it .

Another Scenario : When the uMQTT Broker and the mqtt-client are connected and data pub/sub are fine already.

After that by some cases, In the mqtt-broker side, ESP8266 is restart and start mqtt-broker again after boot, In the mqtt-client side, ESP8266 will be still on the old mqtt-connection (?) and can send data after mqtt-broker start again . (I found data is sent from the client at the broker's onData-callback function.)

However at the mqtt-client side, ESP8266 is silent (I can not find any data at the client's onData-callback function.)

Do you mind to advice me any api for this situation the mqtt-client side can get data again?

[martin-ger]

I'm note sure, whether I understand exaclty the setup. But as soon as one side reboots or looses AP connectivity, all MQTT(TCP)-connections are broken and have to be newly established later by the clients. Also subscriptions are lost and have to be resubscribed explicitly after reconnection. If a broker silenty passes away without closing the connection, it takes a while for a client to realize that (timeout). In the meantime it might still try to publish things, but this will surely never reach the broker and the subscribers.

esp_umqtt_broker doesn't support yet non-clean sessions (i.e. re-establishing former MQTT client sessions on a new TCP connection). This might be a possible feature for a next release, but state changes are non-tivial and this permanently consumes memory (However, as the set of potential clients is usually limited in the most ESP scenarios) this might be an option...

[TridentTD]

Thank you, I will try again.