Fenrir fixes

.github/workflows/broker-check.yml

@@ -115,6 +115,10 @@ jobs:
             cflags: ""
             wolfmqtt_opts: "--enable-broker --enable-v5 --enable-broker-persist --disable-broker-retained"
             check_units: "yes"
+          - name: "Broker with persist + nonblock"
+            cflags: ""
+            wolfmqtt_opts: "--enable-broker --enable-v5 --enable-broker-persist --enable-nonblock"
+            check_units: "yes"
 
     steps:
     - name: Install dependencies

.gitignore

@@ -138,4 +138,6 @@ tests/test_mqtt_sn_client_mt_only
 tests/test_mqtt_sn_client_nodata
 tests/unit_tests
 tests/test_mqtt_props_init
+tests/test_mqtt_sem_init
+tests/test_broker_log
 tests/test_mqtt_curl_init

BROKER.md

@@ -165,11 +165,39 @@ script or installer inherits the ambient umask - under a relaxed umask such as
 mkdir -p /var/lib/wolfmqtt && chmod 0700 /var/lib/wolfmqtt
 ```
 
+The POSIX backend names each record after its key in hex, so a key can be at
+most `(NAME_MAX - 8) / 2` bytes: 123 on filesystems with the usual 255-byte
+`NAME_MAX`. Sessions and subscriptions are keyed by client ID, retained
+messages by topic, and offline-queue entries by client ID plus 3 bytes. With
+this backend a client ID longer than 120 bytes loses its queued messages across
+a restart, one longer than 123 bytes loses its whole session, and a retained
+message whose topic is longer than 123 bytes is not kept. The broker still
+serves them from memory while it runs. Use a custom backend through
+`MqttBroker_SetPersistHooks()` if longer identifiers must persist.
+
+A custom backend must follow the same contract as the POSIX one. `kv_get`
+treats `*inout_len` as the buffer capacity on input and sets the record length
+on success, returns `MQTT_CODE_ERROR_NOT_FOUND` for a missing key, and returns
+`MQTT_CODE_ERROR_OUT_OF_BUFFER` - never a truncated success - for a record
+larger than the buffer. Every key `kv_iter` hands to its callback must be
+accepted unchanged by `kv_get` and `kv_del`; the broker deletes records it
+finds while iterating and repeats until none match.
+
 | Macro | Default | Description |
 |---|---|---|
-| `BROKER_MAX_PERSIST_SESSIONS` | 64 | Dynamic-memory persistent sessions retained across restarts |
+| `BROKER_MAX_PERSIST_SESSIONS` | 64 | Dynamic-memory persistent sessions (connected and offline); a new persistent CONNECT beyond it is refused, existing sessions are never evicted |
 | `BROKER_MAX_OFFLINE_MSGS_PER_SUB` | 32 | Offline queue depth per session |
-| `WOLFMQTT_BROKER_PERSIST_SCHEMA_VER` | 5 | On-disk record schema version |
+| `WOLFMQTT_BROKER_PERSIST_SCHEMA_VER` | 6 | On-disk record schema version |
+
+Because existing persistent sessions are never evicted, any client allowed to
+connect can use up `BROKER_MAX_PERSIST_SESSIONS` by opening persistent sessions
+under fresh client IDs (a v3.1.1 CleanSession 0 session never expires); after
+that, persistent CONNECTs with new client IDs are refused until sessions end,
+and with persistence enabled the sessions survive a restart. Clients that
+resume their own session are unaffected. Configure broker credentials
+(`-u`/`-P`), size the cap for the deployment, and prefer bounded v5 Session
+Expiry Intervals where this matters. The previous drop-oldest
+policy let the same client destroy other clients' saved sessions instead.
 
 ### Encryption at rest
 

README.md

@@ -150,6 +150,7 @@ These are the network connect / disconnect interfaces that wrap the MqttNet call
 
 * `int MqttClient_NetConnect(MqttClient *client, const char* host, word16 port, int timeout_ms, int use_tls, MqttTlsCb cb);`
 * `int MqttClient_NetDisconnect(MqttClient *client);`
+* `int MqttClient_NetDisconnect_Wait(MqttClient *client);` - like `MqttClient_NetDisconnect`, but in `WOLFMQTT_MULTITHREAD` builds waits for other threads' network I/O on the client to finish first. Do not call it from a message, property or publish payload callback; where thread identities are available it returns `MQTT_CODE_ERROR_STAT` there instead of deadlocking.
 
 Helper functions:
 
@@ -225,6 +226,8 @@ The multi-threading feature can also be used with the non-blocking socket (--ena
 
 If you are having issues with thread synchronization on Linux consider using not the conditional signal (`WOLFMQTT_NO_COND_SIGNAL`).
 
+With `WOLFMQTT_NO_COND_SIGNAL`, or with `WOLFMQTT_USER_THREADING` unless `WOLFMQTT_SEM_SIGNAL` is defined, a write-only publish or `MqttClient_CancelMessage` whose response another thread is decoding waits for that thread to release the receive lock instead of being signalled. A thread that blocks in `MqttClient_WaitMessage` can then hold them up until its read returns.
+
 ### Atomic publish and subscribe examples
 In the `examples/pub-sub` folder, there are two simple client examples:
 * mqtt-pub - publishes to a topic