|
I think it's a real problem worth thinking about - it has been
brought up before and we did create a fix which still left a
window. If a message arrives towards the end of the timeout,
perhaps we should extend that timeout to allow residual processing
to complete.
Ian
On 02/15/2017 02:32 PM, Petri Soininen
wrote:
Hi all,
Regarding:
MQTTClient/src/MQTTClient.h:
template<class Network, class Timer, int
MAX_MQTT_PACKET_SIZE, int b>
int MQTT::Client<Network, Timer,
MAX_MQTT_PACKET_SIZE, b>::cycle(Timer& timer)
I'm suspecting that there is timeout hitting too easily,
repro steps:
- You are waiting in yield() > cycle() >
readPacket() to message arrive
- Timeout is almost elapsed when message received, e.g.
PUBLISH, for sure sometimes this happens
- Your ipstack library might be slowish e.g. when
accessing wifi over UART
- Same remaining timeout value is used in sendPacket(),
the remaining timeout can be very small when
sending PUBACK.
- You hit timeout in your implementation
of ipstack.write()
It helps if reseting the timer before sendPacket(), like
this, needed in two places in cycle():
timer.reset();
rc = sendPacket(len, timer);
For timer.reset() there needs to be respective
implementation in Countdown(), something like this:
void reset() { countdown_ms(default_ms); }
...
private:
uint32_t
default_ms; // Need to be set when timer is initiated
Hopefully you can see my point.
Do you think this is real problem (and would fix be ok)
or am I missing something in my ipstack implementation?
BR, Petri
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev
--
Ian Craggs
icraggs@xxxxxxxxxx IBM United Kingdom
Eclipse Paho Project Lead; Committer on Eclipse Mosquitto;
Tech Lead in IBM Watson IoT Platform
|
