If you're telling me that is, according to the standard, how it is supposed to work... that is good and helpful.
yes. I can do interop tests... I figure mosquitto is the lowest bar, in terms of being the lightest one likely the most
conservative in implementation. If different brokers do different things... That is sub-optimal, as I want it to work
with at least a good subset of them. Is there a list somewhere that compares brokers for these sorts of things? I have experimented with: emqx, verneMQ, and mosquitto, so far. I can add Hive, I guess. In earlier work they seemed to all work fine, but I wasn't getting as detailed as now. The wikimedia MQTT implementation page is long. MQTT's origins are in SCADA, and with mqtt v5 it has much better support for message queueing apps that are a little different... hard to know which brokers to try for an app from a message queueing background. We want reliable messaging (no loss, yes queueing) good load balancing (dynamic shared subscriptions?) and error recovery (which seems to mean different things to different people.) It's very close to amqp stuff... just can't quite tell if it is really there yet.
more concretely: It occurred to me that brokers might want to load balancing based on ReceiveMaximum... which mosquitto appears to do... in that it doesn't queue data for any client that has reached it's receive Maximum... but that seems to mean that if there are no clients connected who have < receiveMaximum messages pending... it looks like it drops the message. Sigh... that's not what I'd prefer either... It should queue as long as it sees the client is connected, and receiveMaximum should control the number of messages in flight.
I'm searching for a way to provide backpressure... My only guess for now is to disconnect temporarily...