How to get number of writable bytes in send buffer about mqtt-c HOT 7 CLOSED

Hi Josh,

Yeah, you are correct that curr_sz in struct mqtt_client doesn't usually change when mqtt_sync is called. That is because the buffer is only flushed when you try to add a packet that is too big to currently fit. This prevents the need to flush of acknowledged packets after each received acknowledgement (a flush requires a memcpy of all unacknowledged packets in the buffer).

I think that curr_sz in struct mqtt_message_queue is what you're looking for (here). Does that look right to you?

Cheers,

Liam

from mqtt-c.

Yes, the curr_sz field in struct mqtt_message_queue is what I was referring to. At a first glance, that appears to be what I need. But when I actually use it, it doesn't change after calling mqtt_sync. I created a quick & dirty paste here that should demonstrate this behavior. When I compile and run this code, this is the output I see:

Initially, curr_sz = 1942
After publishing, curr_sz = 1870
After syncing, curr_sz = 1870

from mqtt-c.

Oh yeah, I see what you mean. Unfortunately, I don't think there is a way to getting what you are looking for without looping through the start of the queue to see how many messages are of state MQTT_QUEUED_COMPLETE.

Try calling mqtt_mq_clean(client->mq) after every mqtt_sync(client). This should force the message queue to be cleaned immediately, and bring the curr_sz field to the maximum possible number of bytes that can be sent.

Let me know if you still have any problems.

from mqtt-c.

Okay, yeah that seems like it will do the trick. I've got a busy couple weeks ahead of me so I haven't actually tried it yet, but it looks promising. I'll close this for now and add a comment or re-open when I actually try it out.

Thanks for your help,
Josh

from mqtt-c.

Great, sounds good. Let me know how it goes when you get to it.

Liam

from mqtt-c.

I finally got around to this this week. This generally did what I wanted it to.

An issue I ran into, however, was that __mqtt_ping could be called on a call to mqtt_sync, which could cause an MQTT_ERROR_SEND_BUFFER_IS_FULL error. This is the error I was trying to avoid in the first place. This scenario would probably only happen if a broker silently disappears when the send buffer is almost completely full of unacknowledged data. I'm working on putting together a system that needs to be relatively fault-tolerant, so my workaround was to make sure that before I call mqtt_publish (or any other function that puts data on the send buffer), that client->mq.curr_sz is larger than:

1. The size of the packet I'm trying to put on the buffer, PLUS
2. The size of the ping packet which could be placed on the buffer, PLUS
3. The size of a mqtt_queued_message struct used for my packet, PLUS
4. The size of a mqtt_queued_message struct which could be used for the ping packet.

Basically, I just make sure I always leave room for a possible ping packet before putting anything on the send buffer. Note that I am manually calculating points 1 & 2 above according to the MQTT 3.1.1 spec. I haven't seen the send-buffer-is-full error come across since doing what I've described here, so I think I've solved this issue.

Thanks!
Josh

from mqtt-c.

The safest thing is to make your buffers as big as you can afford, and use MQTT-C's reconnect functionality.

Because pings, acks, etc are all happening behind the scenes, and being put on the same send buffer that your publishes are put on, checking that client->mq.curr_sz is smaller than your publish message doesn't mean the buffer is big enough.

MQTT-C really does try to be semantically correct (i.e. it will give you errors if something goes wrong), so I'd caution against inspecting the maximum usage of your send buffer for anything besides finding a "reasonable" buffer size for your application.

Let me know if you have any ideas about a better way to handle this though!
Liam

from mqtt-c.