Hi Prajwal,
In the Mosquitto Broker this handling for incoming/outging messages depends (mainly) on the value config entry max_inflight_messages. The default value is of this entry is 20. This value will have effect on incoming messages and outgoing messages: * For incoming publish messages this value limits the number of incoming messages the broker is willing to accept in parallel. So by default the broker would accept up to 20 messages being send by the client. So the client implementation need to take care to send out a 21th packet only after the broker has acknowledged one of the previous 20 messages. Any violation of this limit will be considered as a protocol violation and the client will be disconnected. * For outgoing publish messages the broker will send out up to 20 messages with QOS1/2 and will only send additional messages after he has received acknowledges for any of these messages. Depending on the max_queued_messages configuration the broker will start to queue further outgoing messages with QOS1/2 until he reaches his queue limits. Any outgoing messages with QOS=0 will be dropped, if the cannot be sent out immediately. More precise: if the broker has already sent out 20 messages with qos=1/2 waiting for acknowledgment or already has started to queue messages with qos=1/2 he will drop any qos=0 message for this client.
The default value maybe reconfigured in the mosquitto.conf. An alternative config entry is the max_inflight_bytesn which limits on the number of bytes instead of the number of messages.
For a MQTTv5 client the configured value will be send out in the CONNACK packet as the “Receive Maximum” property. This way a MQTTv5 client implementation could adapt it’s outgoing message handling to send maximum message in parallel without the need to wait for the acknowledgment.
A MQTTv5 client may specify a different limit using the “Receive Maximum” in his CONNECT packet. The broker will adapt his outgoing message handling. So even with the default limit of 20 in flight messages in the broker config a MQTTv5 client may connect with a different limit. The Mosquitto broker in this case will use the limit specified by the client for this connection.
Best,
-- Norbert Heußer Senior Developer | Cedalo GmbH Email: norbert.heusser@xxxxxxxxxx Tel: +49 173 936 43 63
Cedalo GmbH The company behind Eclipse Mosquitto and Eclipse Streamsheets https://cedalo.com/ Geschäftsführer: Philipp Struss, Philip Ackermann Registergericht: Amtsgericht Freiburg, HRB 725414 ---------------------------------------------------------------------------------------------
Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.
On 7. Jan 2025, at 00:43, Prajwal THAKUR via mosquitto-dev <mosquitto-dev@xxxxxxxxxxx> wrote:
Hi, I have a scenario where msgs are generated, let's say 100ms and the latency in the system is 200ms. If I create a message at, let's say, T=0 sec and send it over the network, then it will take 200ms to receive the acknowledgment from the client. Can the broker process the other data generated at t=100ms and try to send it to the same client? (Or would it wait for the acknowledgment before processing the following message? In this case, it would be queued in some buffer, and the previous one would first be processed and then started processing this. ) I know in qos=0. This is possible, but I am unsure about the qos=1 and qos=2 mechanism. Do you know if there is any reference I can look into? Thanks ![]()
_______________________________________________ mosquitto-dev mailing list mosquitto-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/mosquitto-dev
|