Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] paho-dev Digest, Vol 38, Issue 33

Thanks Ian ! Great work !

Paolo Patierno
Senior Software Engineer
 

 
Twitter : @ppatierno
Linkedin : paolopatierno
Blog (english) : Embedded101
Blog (italian) : DevExperience


> From: paho-dev-request@xxxxxxxxxxx
> Subject: paho-dev Digest, Vol 38, Issue 33
> To: paho-dev@xxxxxxxxxxx
> Date: Sat, 21 Feb 2015 08:37:41 -0500
>
> Send paho-dev mailing list submissions to
> paho-dev@xxxxxxxxxxx
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://dev.eclipse.org/mailman/listinfo/paho-dev
> or, via email, send a message with subject or body 'help' to
> paho-dev-request@xxxxxxxxxxx
>
> You can reach the person managing the list at
> paho-dev-owner@xxxxxxxxxxx
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of paho-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: Embedded-C dropping PUBACKs (Joe Planisky)
> 2. Paho 1.1 Released (Ian Craggs)
> 3. Re: Embedded-C dropping PUBACKs (Ian Craggs)
> 4. Re: Paho 1.1 Released (Nicholas O'Leary)
> 5. Re: Paho 1.1 Released (Jeff Prestes)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 20 Feb 2015 09:03:21 -0800
> From: Joe Planisky <joe.planisky@xxxxxxxxxx>
> To: General development discussions for paho project
> <paho-dev@xxxxxxxxxxx>
> Subject: Re: [paho-dev] Embedded-C dropping PUBACKs
> Message-ID: <1FB74B89-A827-470C-A072-59C2FDFD4592@xxxxxxxxxx>
> Content-Type: text/plain; charset=windows-1252
>
> Hi Ian,
>
> Thanks for your reply.
>
> > (An observation: in the most recent version of the MQTT specification,
> > 3.1.1, the server is not supposed to retry packets...)
>
> Understood, but I don't know how to make my server (mosquitto 1.3.4) behave
> that way. The spec seems to allow reties of unacknowledged packets outside
> of reconnects, although such behavior is "not encouraged". Switching to a
> different server is not feasible at this time.
>
> > How frequently are you expecting to receive messages? If you called
> > yield() less frequently, then when yield was called, then could it be
> > more likely that the message was available at the start of the 200ms?
> > I presume just lengthening the yield timeout wouldn't reduce the likelihood
> > of the message being received towards the end of the timeout period?
>
> It's possible either or both of those could reduce the likelihood of this
> happening, but it would impact the rest of my application in unacceptable ways.
>
> Adding a separate timer when sending the PUBACK seems to be the best solution
> for my particular case. It means my calls to yield will sometimes last
> slightly longer than the specified timeout period, but that's acceptable in my
> application.
>
> ?
> Joe
>
>
> On Feb 20, 2015, at 2:18, Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> > Hi Joe,
> >
> > the embedded-C code has to make a compromise between catering for all circumstances and its size, because we want it to take up the smallest amount of resources possible. This sounds like something that we should have to address though.
> >
> > (An observation: in the most recent version of the MQTT specification, 3.1.1, the server is not supposed to retry packets. This is not a resolution to this problem though.)
> >
> > How frequently are you expecting to receive messages? If you called yield() less frequently, then when yield was called, then could it be more likely that the message was available at the start of the 200ms? I presume just lengthening the yield timeout wouldn't reduce the likelihood of the message being received towards the end of the timeout period?
> >
> > The asynchronous version of the client API (which I haven't written yet) would start a background thread to receive and deliver messages, and avoid this problem. But, in the process of doing that, it would use significantly more resources, which for an environment like the Arduino Uno, could be too much.
> >
> > As you say, one obvious solution would be to add some time add the end of yield to allow the sending of the puback. The amount of time required would vary from environment to environment though...
> >
> > Ian
> >
> >
> > On 02/19/2015 09:36 PM, Joe Planisky wrote:
> >> Hi all,
> >>
> >> I am using the Paho embedded-C code in an Arduino environment (i.e. single threaded, no RTOS) and am running into an issue with QoS-1 PUBACKs frequently not getting sent to the broker. I've looked at the source code and I think I see the problem, but I want to make sure I'm not missing anything.
> >>
> >> My program's main loop calls MQTT::Client::yield() with a timeout of 200 mS. yield() starts a timer for 200 mS and calls cycle() until either the timer expires or cycle() returns an error.
> >>
> >> cycle() in turn reads a packet, deserializes it, and if it's a PUBLISH message, delivers it to my handler, and if it's QoS1 (or 2, although I'm not using QoS2), sends a PUBACK by calling sendPacket().
> >>
> >> sendPacket() then tries to write the data to the ipStack until EITHER all the data is sent OR the timer expires.
> >>
> >> What appears to be happening is that a new PUBLISH message comes in late in my 200 mS yield time, and by the time sendPacket() is called, the timer has expired, so the PUBACK never gets sent. This results in the broker resending the message even though my client got the initial message just fine. This is happening annoyingly often for me.
> >>
> >> Is that an expected scenario? It doesn't affect the integrity of the published data, but it does increase network traffic and the burden of dealing with duplicate PUBLISH messages.
> >>
> >> It seems like when sending a PUBACK, the call to sendPacket should be given a separate timer rather than whatever time happens to be left in the yield() timer to make sure the PUBACK has enough time to actually be sent. Or is there another way to deal with this scenario that I'm not seeing?
> >>
> >> --
> >> Joe
> >>
> >> _______________________________________________
> >> 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
> > Paho Project Lead; Committer on Mosquitto
> >
> > _______________________________________________
> > 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
>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 20 Feb 2015 23:46:09 +0000
> From: Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx>
> To: "paho >> General development discussions for paho project"
> <paho-dev@xxxxxxxxxxx>
> Subject: [paho-dev] Paho 1.1 Released
> Message-ID: <54E7C741.1090503@xxxxxxxxxxxxxxxxxxxxxxx>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> Dear all,
>
> finally I have produced the remaining pieces, and am pleased to be able
> to say that Paho 1.1 is released.
>
> What's new:
>
> 1) Paolo Patierno's .Net and WinRT MQTT client, M2Mqtt, version 4.0.0
> 2) An Android service - a wrapper around the existing Java client.
> Version 1.0.2
> 3) Embedded C and C++ MQTT client libraries, version 1.0.0
>
> Updated versions of the existing client libraries:
>
> 1) Roger Light's Python MQTT client, version 1.1
> 2) The full fat Posix/Windows/MacOS C client, updated to version 1.0.3
> 3) The Java MQTT client, updated to version 1.0.2
> 4) The _javascript_ MQTT client, updated to version 1.0.1
>
> The downloads page is updated:
>
> https://projects.eclipse.org/projects/technology.paho/downloads
>
> and the formal release documentation is here:
>
> https://projects.eclipse.org/projects/technology.paho/releases/1.1.0
>
> Thanks to everyone who has contributed, with code, bugs, suggestions or
> advice -- anything :-)
>
> I've updated some essentials on the web site, including references to
> the MQTT 3.1.1 standard, but there are updates that are still needed.
> If you find anything, please let me know.
>
> Ian Craggs
> Paho Project Lead
> IBM
>
>
> <https://www.eclipse.org/downloads/download.php?file=/paho/1.0/m2mqtt/M2Mqtt_4.0.0.0_bins.zip>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://dev.eclipse.org/mailman/private/paho-dev/attachments/20150220/06edc3e8/attachment.html>
>
> ------------------------------
>
> Message: 3
> Date: Sat, 21 Feb 2015 00:15:01 +0000
> From: Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx>
> To: paho-dev@xxxxxxxxxxx
> Subject: Re: [paho-dev] Embedded-C dropping PUBACKs
> Message-ID: <54E7CE05.5030707@xxxxxxxxxxxxxxxxxxxxxxx>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> Hi Joe,
>
> some other potential solutions:
>
> 1) store the message id of the publish for response the next time
> yield() is called. This would involve more code though, and I'm trying
> to keep the code size small.
>
> 2) Don't attempt to read a packet if there wasn't much time remaining in
> the yield interval, leave it to the next call to yield.
>
> If we considered the timeout value for yield() as the minimum amount of
> time it will wait, and in the case of needing to send an ack it could
> take longer, that does make a lot of sense though.
>
> Ian
>
> On 20/02/15 17:03, Joe Planisky wrote:
> > Hi Ian,
> >
> > Thanks for your reply.
> >
> >> (An observation: in the most recent version of the MQTT specification,
> >> 3.1.1, the server is not supposed to retry packets...)
> > Understood, but I don't know how to make my server (mosquitto 1.3.4) behave
> > that way. The spec seems to allow reties of unacknowledged packets outside
> > of reconnects, although such behavior is "not encouraged". Switching to a
> > different server is not feasible at this time.
> >
> >> How frequently are you expecting to receive messages? If you called
> >> yield() less frequently, then when yield was called, then could it be
> >> more likely that the message was available at the start of the 200ms?
> >> I presume just lengthening the yield timeout wouldn't reduce the likelihood
> >> of the message being received towards the end of the timeout period?
> > It's possible either or both of those could reduce the likelihood of this
> > happening, but it would impact the rest of my application in unacceptable ways.
> >
> > Adding a separate timer when sending the PUBACK seems to be the best solution
> > for my particular case. It means my calls to yield will sometimes last
> > slightly longer than the specified timeout period, but that's acceptable in my
> > application.
> >
> > ?
> > Joe
> >
> >
> > On Feb 20, 2015, at 2:18, Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
> >
> >> Hi Joe,
> >>
> >> the embedded-C code has to make a compromise between catering for all circumstances and its size, because we want it to take up the smallest amount of resources possible. This sounds like something that we should have to address though.
> >>
> >> (An observation: in the most recent version of the MQTT specification, 3.1.1, the server is not supposed to retry packets. This is not a resolution to this problem though.)
> >>
> >> How frequently are you expecting to receive messages? If you called yield() less frequently, then when yield was called, then could it be more likely that the message was available at the start of the 200ms? I presume just lengthening the yield timeout wouldn't reduce the likelihood of the message being received towards the end of the timeout period?
> >>
> >> The asynchronous version of the client API (which I haven't written yet) would start a background thread to receive and deliver messages, and avoid this problem. But, in the process of doing that, it would use significantly more resources, which for an environment like the Arduino Uno, could be too much.
> >>
> >> As you say, one obvious solution would be to add some time add the end of yield to allow the sending of the puback. The amount of time required would vary from environment to environment though...
> >>
> >> Ian
> >>
> >>
> >> On 02/19/2015 09:36 PM, Joe Planisky wrote:
> >>> Hi all,
> >>>
> >>> I am using the Paho embedded-C code in an Arduino environment (i.e. single threaded, no RTOS) and am running into an issue with QoS-1 PUBACKs frequently not getting sent to the broker. I've looked at the source code and I think I see the problem, but I want to make sure I'm not missing anything.
> >>>
> >>> My program's main loop calls MQTT::Client::yield() with a timeout of 200 mS. yield() starts a timer for 200 mS and calls cycle() until either the timer expires or cycle() returns an error.
> >>>
> >>> cycle() in turn reads a packet, deserializes it, and if it's a PUBLISH message, delivers it to my handler, and if it's QoS1 (or 2, although I'm not using QoS2), sends a PUBACK by calling sendPacket().
> >>>
> >>> sendPacket() then tries to write the data to the ipStack until EITHER all the data is sent OR the timer expires.
> >>>
> >>> What appears to be happening is that a new PUBLISH message comes in late in my 200 mS yield time, and by the time sendPacket() is called, the timer has expired, so the PUBACK never gets sent. This results in the broker resending the message even though my client got the initial message just fine. This is happening annoyingly often for me.
> >>>
> >>> Is that an expected scenario? It doesn't affect the integrity of the published data, but it does increase network traffic and the burden of dealing with duplicate PUBLISH messages.
> >>>
> >>> It seems like when sending a PUBACK, the call to sendPacket should be given a separate timer rather than whatever time happens to be left in the yield() timer to make sure the PUBACK has enough time to actually be sent. Or is there another way to deal with this scenario that I'm not seeing?
> >>>
> >>> --
> >>> Joe
> >>>
> >>> _______________________________________________
> >>> 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
> >> Paho Project Lead; Committer on Mosquitto
> >>
> >> _______________________________________________
> >> 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
> > _______________________________________________
> > 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
>
>
>
> ------------------------------
>
> Message: 4
> Date: Sat, 21 Feb 2015 09:15:30 +0000
> From: "Nicholas O'Leary" <nick.oleary@xxxxxxxxx>
> To: "paho >> General development discussions for paho project"
> <paho-dev@xxxxxxxxxxx>
> Subject: Re: [paho-dev] Paho 1.1 Released
> Message-ID:
> <CAF=vhqcWtB1LZANgFfN1QuLsWtw5BMGrcBAupfcxZ9KuOJE3yA@xxxxxxxxxxxxxx>
> Content-Type: text/plain; charset="utf-8"
>
> Great work Ian. Thanks as ever for your work on paho.
>
> Nick
>
> On Fri, 20 Feb 2015 23:46 Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx>
> wrote:
>
> > Dear all,
> >
> > finally I have produced the remaining pieces, and am pleased to be able to
> > say that Paho 1.1 is released.
> >
> > What's new:
> >
> > 1) Paolo Patierno's .Net and WinRT MQTT client, M2Mqtt, version 4.0.0
> > 2) An Android service - a wrapper around the existing Java client.
> > Version 1.0.2
> > 3) Embedded C and C++ MQTT client libraries, version 1.0.0
> >
> > Updated versions of the existing client libraries:
> >
> > 1) Roger Light's Python MQTT client, version 1.1
> > 2) The full fat Posix/Windows/MacOS C client, updated to version 1.0.3
> > 3) The Java MQTT client, updated to version 1.0.2
> > 4) The _javascript_ MQTT client, updated to version 1.0.1
> >
> > The downloads page is updated:
> >
> > https://projects.eclipse.org/projects/technology.paho/downloads
> >
> > and the formal release documentation is here:
> >
> > https://projects.eclipse.org/projects/technology.paho/releases/1.1.0
> >
> > Thanks to everyone who has contributed, with code, bugs, suggestions or
> > advice -- anything :-)
> >
> > I've updated some essentials on the web site, including references to the
> > MQTT 3.1.1 standard, but there are updates that are still needed. If you
> > find anything, please let me know.
> >
> > Ian Craggs
> > Paho Project Lead
> > IBM
> >
> >
> >
> > <https://www.eclipse.org/downloads/download.php?file=/paho/1.0/m2mqtt/M2Mqtt_4.0.0.0_bins.zip>
> > _______________________________________________
> > 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
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://dev.eclipse.org/mailman/private/paho-dev/attachments/20150221/b48827f7/attachment.html>
>
> ------------------------------
>
> Message: 5
> Date: Sat, 21 Feb 2015 11:37:24 -0200
> From: Jeff Prestes <jeffprestes@xxxxxxxxx>
> To: General development discussions for paho project
> <paho-dev@xxxxxxxxxxx>
> Subject: Re: [paho-dev] Paho 1.1 Released
> Message-ID:
> <CAKbj8jOpFFZmy2WeSpvhgewC9K1bM0216Q2SW2opFCz7CLR-Kw@xxxxxxxxxxxxxx>
> Content-Type: text/plain; charset="utf-8"
>
> Ian,
>
> congratulations for this awesome work!
>
> Thank you very much!
>
> -Jeff
>
> 2015-02-21 7:15 GMT-02:00 Nicholas O'Leary <nick.oleary@xxxxxxxxx>:
>
> > Great work Ian. Thanks as ever for your work on paho.
> >
> > Nick
> >
> > On Fri, 20 Feb 2015 23:46 Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx>
> > wrote:
> >
> >> Dear all,
> >>
> >> finally I have produced the remaining pieces, and am pleased to be able
> >> to say that Paho 1.1 is released.
> >>
> >> What's new:
> >>
> >> 1) Paolo Patierno's .Net and WinRT MQTT client, M2Mqtt, version 4.0.0
> >> 2) An Android service - a wrapper around the existing Java client.
> >> Version 1.0.2
> >> 3) Embedded C and C++ MQTT client libraries, version 1.0.0
> >>
> >> Updated versions of the existing client libraries:
> >>
> >> 1) Roger Light's Python MQTT client, version 1.1
> >> 2) The full fat Posix/Windows/MacOS C client, updated to version 1.0.3
> >> 3) The Java MQTT client, updated to version 1.0.2
> >> 4) The _javascript_ MQTT client, updated to version 1.0.1
> >>
> >> The downloads page is updated:
> >>
> >> https://projects.eclipse.org/projects/technology.paho/downloads
> >>
> >> and the formal release documentation is here:
> >>
> >> https://projects.eclipse.org/projects/technology.paho/releases/1.1.0
> >>
> >> Thanks to everyone who has contributed, with code, bugs, suggestions or
> >> advice -- anything :-)
> >>
> >> I've updated some essentials on the web site, including references to the
> >> MQTT 3.1.1 standard, but there are updates that are still needed. If you
> >> find anything, please let me know.
> >>
> >> Ian Craggs
> >> Paho Project Lead
> >> IBM
> >>
> >>
> >>
> >> <https://www.eclipse.org/downloads/download.php?file=/paho/1.0/m2mqtt/M2Mqtt_4.0.0.0_bins.zip>
> >> _______________________________________________
> >> 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
> >
> >
> > _______________________________________________
> > 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
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://dev.eclipse.org/mailman/private/paho-dev/attachments/20150221/c0baf4bd/attachment.html>
>
> ------------------------------
>
> _______________________________________________
> 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
>
> End of paho-dev Digest, Vol 38, Issue 33
> ****************************************

Back to the top