Re: [Pharo-dev] MQTT for Pharo

[Sean P. DeNigris]

timrowledge wrote
> Hi Sven,
> yes, the code in SqueakSource/MQTT is very early stuff. It's improving
> quickly though. I'd be happy to get together to work on an as common as
> possible versions for both Squeak and Pharo.





-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/MQTT-for-Pharo-tp4927759p4928045.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] MQTT for Pharo

[Sven Van Caekenberghe]

Back on topic, MQTT, I added more/better functional units tests and more 
comments, as well as variants against a local broker.

Here is a more complete example:

"Fork a process that reads 10 temperature sensor values"

[ (Array streamContents: [ :stream | | count |
count := 1.
MQTTExperimentalClient new
   clientId: 'listener';
   open;
   subscribeToTopic: '/device/42/outside-temperature';
   runWith: [ :message |
 stream nextPut: message contents asInteger.
 (count := count + 1) > 10 ifTrue: [ ConnectionClosed signal ] ] ]) 
inspect ] fork.

"Post 10 temperature sensor value readings, using a new client/connection each 
time"

1 to: 10 do: [ :i |
  MQTTExperimentalClient new
atLeastOnce;
open;
sendMessage: i asByteArray toTopic: '/device/42/outside-temperature';
close ]

Sven

> On 21 Dec 2016, at 21:57, Sven Van Caekenberghe  wrote:
> 
>> 
>> On 21 Dec 2016, at 18:19, Henrik Johansen  
>> wrote:
>> 
>>> 
>>> On 21 Dec 2016, at 16:52 , Sven Van Caekenberghe  wrote:
>>> 
 
 On 21 Dec 2016, at 16:04, Henrik Johansen  
 wrote:
 
> 
> On 21 Dec 2016, at 14:57 , Sven Van Caekenberghe  wrote:
> 
> Hendrik,
> 
> Thank you for this detailed feedback.
> 
>> On 21 Dec 2016, at 12:44, Henrik Johansen  
>> wrote:
>> 
>> Hi Sven!
>> One thing I noticed when testing the RabbitMQ client with keepalive > 0, 
>> was connection being closed and all subscriptions lost when receiving 
>> large payloads, due to timeout before the keepalive packet could be sent 
>> before waiting to receive next object.
> 
> Indeed, I used my Stamp (STOMP) Rabbit MQ client as a model for the MQTT 
> one - there is a lot of similarity, especially in concept.
> 
> Keep alive processing is not that easy. I tried to do it by using read 
> timeouts as a source of regular opportunities to check for the need to 
> process keep alive logic. But of course, if you have no outstanding read 
> (in a loop), that won't work.
> 
> The fact that receiving a large payload would trigger an actual keep 
> alive time out is not something that I have seen myself. It seems weird 
> that the reading/transferring of incoming data would not count as 
> activity against keep alive, no ?
 
 I never had a chance to investigate fully, but I distinctly remember 
 having the same reaction!
 It's quite awhile ago now, so my memory might be hazy, take the following 
 with an appropriate amount of grains of salt.
 
 The first times I encountered it, it seemed quite random, occuring after 
 extended periods of client inactivity after receiving only small 
 payloads...
 Setting a much shorter keepalive timeout than the default was/is very 
 useful in reproducing/verifying if it is an issue.
 The timeouts then occurred relatively shortly after I'd received a single 
 payload with no other activity, and disappeared once I removed the 
 resetting of lastActivity timestamp on reads, indicating that for at least 
 rabbitmq (3.5 was the version at the time, I believe), receiving data was 
 *not* being counted as keep-alive activity.
 
 The issue of receiving large payloads blocking writing in time was still 
 unresolved, consistently cut off in the middle of (its own!) multi-MB 
 payload transfers due to keepalive packet not being sent.
 I couldn't see a solution other than abandoning the elegant 
 single-threaded approach and do keepalive as a separate high-priority 
 process, but the architectural choice for the app  changed at this point 
 to not include a MQ in first delivery, so the more involved rewrite for 
 doing so before deploying in production, kinda got stranded :/
>>> 
>>> Instinctively it feels like messaging and multi-MB payloads would not be a 
>>> good fit, at least I would suspect that they are an edge case. But maybe I 
>>> am wrong.
>>> 
>>> I think that the code in StampMedium>>#readBodyBytes: and 
>>> StampMedium>>#readBodyString: could be refactored to use a loop with chunk 
>>> buffers and at the same time check the elapsed time to fire back keep alive 
>>> pings if necessary. A ping too much would not hurt, better safe than sorry. 
>>> But is is hard to catch any/all network slowdowns, any IO operation could 
>>> hang/timeout.
>>> 
>>> But all this would assume that the problematic situation can be recreated.
>> 
>> Absolutely, far from certain the MQTT server implementations work the same.
>> 
>> This is the test code I used for rabbit: 
>> 
>> consumer1 := StampClient new
>> timeout:1;
>> heartbeat: 5000;
>> login: 'guest';
>>  passcode: 'guest';
>>  open;
>> subscribeTo: '/exchange/testall';
>> yourself.
>> [[ consumer1 runWith:[:message 

Re: [Pharo-dev] MQTT for Pharo

[Sven Van Caekenberghe]

> On 21 Dec 2016, at 18:19, Henrik Johansen  
> wrote:
> 
>> 
>> On 21 Dec 2016, at 16:52 , Sven Van Caekenberghe  wrote:
>> 
>>> 
>>> On 21 Dec 2016, at 16:04, Henrik Johansen  
>>> wrote:
>>> 
 
 On 21 Dec 2016, at 14:57 , Sven Van Caekenberghe  wrote:
 
 Hendrik,
 
 Thank you for this detailed feedback.
 
> On 21 Dec 2016, at 12:44, Henrik Johansen  
> wrote:
> 
> Hi Sven!
> One thing I noticed when testing the RabbitMQ client with keepalive > 0, 
> was connection being closed and all subscriptions lost when receiving 
> large payloads, due to timeout before the keepalive packet could be sent 
> before waiting to receive next object.
 
 Indeed, I used my Stamp (STOMP) Rabbit MQ client as a model for the MQTT 
 one - there is a lot of similarity, especially in concept.
 
 Keep alive processing is not that easy. I tried to do it by using read 
 timeouts as a source of regular opportunities to check for the need to 
 process keep alive logic. But of course, if you have no outstanding read 
 (in a loop), that won't work.
 
 The fact that receiving a large payload would trigger an actual keep alive 
 time out is not something that I have seen myself. It seems weird that the 
 reading/transferring of incoming data would not count as activity against 
 keep alive, no ?
>>> 
>>> I never had a chance to investigate fully, but I distinctly remember having 
>>> the same reaction!
>>> It's quite awhile ago now, so my memory might be hazy, take the following 
>>> with an appropriate amount of grains of salt.
>>> 
>>> The first times I encountered it, it seemed quite random, occuring after 
>>> extended periods of client inactivity after receiving only small payloads...
>>> Setting a much shorter keepalive timeout than the default was/is very 
>>> useful in reproducing/verifying if it is an issue.
>>> The timeouts then occurred relatively shortly after I'd received a single 
>>> payload with no other activity, and disappeared once I removed the 
>>> resetting of lastActivity timestamp on reads, indicating that for at least 
>>> rabbitmq (3.5 was the version at the time, I believe), receiving data was 
>>> *not* being counted as keep-alive activity.
>>> 
>>> The issue of receiving large payloads blocking writing in time was still 
>>> unresolved, consistently cut off in the middle of (its own!) multi-MB 
>>> payload transfers due to keepalive packet not being sent.
>>> I couldn't see a solution other than abandoning the elegant single-threaded 
>>> approach and do keepalive as a separate high-priority process, but the 
>>> architectural choice for the app  changed at this point to not include a MQ 
>>> in first delivery, so the more involved rewrite for doing so before 
>>> deploying in production, kinda got stranded :/
>> 
>> Instinctively it feels like messaging and multi-MB payloads would not be a 
>> good fit, at least I would suspect that they are an edge case. But maybe I 
>> am wrong.
>> 
>> I think that the code in StampMedium>>#readBodyBytes: and 
>> StampMedium>>#readBodyString: could be refactored to use a loop with chunk 
>> buffers and at the same time check the elapsed time to fire back keep alive 
>> pings if necessary. A ping too much would not hurt, better safe than sorry. 
>> But is is hard to catch any/all network slowdowns, any IO operation could 
>> hang/timeout.
>> 
>> But all this would assume that the problematic situation can be recreated.
> 
> Absolutely, far from certain the MQTT server implementations work the same.
> 
> This is the test code I used for rabbit: 
> 
> consumer1 := StampClient new
> timeout:1;
> heartbeat: 5000;
> login: 'guest';
>   passcode: 'guest';
>   open;
> subscribeTo: '/exchange/testall';
> yourself.
> [[ consumer1 runWith:[:message | Transcript crShow: '1 read: ', message 
> body]] ensure: [consumer1 close]] forkAt: Processor userInterruptPriority .
> 
> producer := StampClient new
> login: 'guest';
>  passcode: 'guest';
>  open; yourself.
> 
> [1 to: 1 do: [:i | producer sendText: i asString to: 
> '/exchange/testall']] forkAt: Processor systemBackgroundPriority.
> 
> Sometimes, but not always, this would fail, either during processing, or some 
> time after.
> 
> A screenshot of how it looks when a disconnect happens during processing due 
> to heartbeat failing can be found at:
> https://tresor.it/s#HN4RG9PEX1SYyKy4NcM31w

I installed RabbitMQ 3.6.4 on my Mac and tried your example and it succeeded 
;-) But I modified it slightly so that both threads have a stop condition (I 
also used /queue instead of /exchange but I don't know if that makes a 
difference).

limit := 1.

consumer1 := StampClient new
timeout:1;
heartbeat: 5000;
login: 'guest';
passcode: 'guest';
open;
subscribeTo: '/queue/testall';
yourself.

producer 

Re: [Pharo-dev] MQTT for Pharo

[Henrik Johansen]

> On 21 Dec 2016, at 16:52 , Sven Van Caekenberghe  wrote:
> 
>> 
>> On 21 Dec 2016, at 16:04, Henrik Johansen  
>> wrote:
>> 
>>> 
>>> On 21 Dec 2016, at 14:57 , Sven Van Caekenberghe  wrote:
>>> 
>>> Hendrik,
>>> 
>>> Thank you for this detailed feedback.
>>> 
 On 21 Dec 2016, at 12:44, Henrik Johansen  
 wrote:
 
 Hi Sven!
 One thing I noticed when testing the RabbitMQ client with keepalive > 0, 
 was connection being closed and all subscriptions lost when receiving 
 large payloads, due to timeout before the keepalive packet could be sent 
 before waiting to receive next object.
>>> 
>>> Indeed, I used my Stamp (STOMP) Rabbit MQ client as a model for the MQTT 
>>> one - there is a lot of similarity, especially in concept.
>>> 
>>> Keep alive processing is not that easy. I tried to do it by using read 
>>> timeouts as a source of regular opportunities to check for the need to 
>>> process keep alive logic. But of course, if you have no outstanding read 
>>> (in a loop), that won't work.
>>> 
>>> The fact that receiving a large payload would trigger an actual keep alive 
>>> time out is not something that I have seen myself. It seems weird that the 
>>> reading/transferring of incoming data would not count as activity against 
>>> keep alive, no ?
>> 
>> I never had a chance to investigate fully, but I distinctly remember having 
>> the same reaction!
>> It's quite awhile ago now, so my memory might be hazy, take the following 
>> with an appropriate amount of grains of salt.
>> 
>> The first times I encountered it, it seemed quite random, occuring after 
>> extended periods of client inactivity after receiving only small payloads...
>> Setting a much shorter keepalive timeout than the default was/is very useful 
>> in reproducing/verifying if it is an issue.
>> The timeouts then occurred relatively shortly after I'd received a single 
>> payload with no other activity, and disappeared once I removed the resetting 
>> of lastActivity timestamp on reads, indicating that for at least rabbitmq 
>> (3.5 was the version at the time, I believe), receiving data was *not* being 
>> counted as keep-alive activity.
>> 
>> The issue of receiving large payloads blocking writing in time was still 
>> unresolved, consistently cut off in the middle of (its own!) multi-MB 
>> payload transfers due to keepalive packet not being sent.
>> I couldn't see a solution other than abandoning the elegant single-threaded 
>> approach and do keepalive as a separate high-priority process, but the 
>> architectural choice for the app  changed at this point to not include a MQ 
>> in first delivery, so the more involved rewrite for doing so before 
>> deploying in production, kinda got stranded :/
> 
> Instinctively it feels like messaging and multi-MB payloads would not be a 
> good fit, at least I would suspect that they are an edge case. But maybe I am 
> wrong.
> 
> I think that the code in StampMedium>>#readBodyBytes: and 
> StampMedium>>#readBodyString: could be refactored to use a loop with chunk 
> buffers and at the same time check the elapsed time to fire back keep alive 
> pings if necessary. A ping too much would not hurt, better safe than sorry. 
> But is is hard to catch any/all network slowdowns, any IO operation could 
> hang/timeout.
> 
> But all this would assume that the problematic situation can be recreated.

Absolutely, far from certain the MQTT server implementations work the same.

This is the test code I used for rabbit: 

consumer1 := StampClient new
timeout:1;
heartbeat: 5000;
login: 'guest';
passcode: 'guest';
open;
subscribeTo: '/exchange/testall';
yourself.
[[ consumer1 runWith:[:message | Transcript crShow: '1 read: ', message body]] 
ensure: [consumer1 close]] forkAt: Processor userInterruptPriority .

producer := StampClient new
login: 'guest';
 passcode: 'guest';
 open; yourself.

[1 to: 1 do: [:i | producer sendText: i asString to: '/exchange/testall']] 
forkAt: Processor systemBackgroundPriority.

Sometimes, but not always, this would fail, either during processing, or some 
time after.

A screenshot of how it looks when a disconnect happens during processing due to 
heartbeat failing can be found at:
https://tresor.it/s#HN4RG9PEX1SYyKy4NcM31w

Cheers,
Henry

Re: [Pharo-dev] MQTT for Pharo

[Sven Van Caekenberghe]

> On 21 Dec 2016, at 15:47, Ben Coman  wrote:
> 
> You might like to collaborate with Tim and Craig.
> http://forum.world.st/Graphing-weather-data-td4927701.html
> cheers -ben

Hmm, that code seems to be quite incomplete (from what I can see publicly): not 
all packet types and their IO is fully implemented, there are no unit tests, 
there is no client, and none of the more complex quality of service levels 0, 1 
& 2 logic/flow, and there are no functional unit tests against public 
sandbox/test servers. 

> On Wed, Dec 21, 2016 at 10:17 PM, Sven Van Caekenberghe  wrote:
>> 
>>> On 21 Dec 2016, at 15:11, p...@highoctane.be wrote:
>>> 
>>> FWIW get yourself an account at http://enco.io
>> 
>> OK, I'll put it on my list of things to look at.
>> 
>>> The devportal has mqtt endpoints so that we can integrate with that and 
>>> possibly have some market place solutions offered and running with Pharo.
>>> 
>>> I have a small EnCoClient class in Pharo that works. Now making the API 
>>> support more extensive.
>>> 
>>> Docs: http://docs.enco.io/docs/device-sensor-apis
>>> 
>>> Phil
>>> 
>>> On Wed, Dec 21, 2016 at 2:59 PM, Sven Van Caekenberghe  wrote:
>>> 
 On 21 Dec 2016, at 12:50, p...@highoctane.be wrote:
 
 Sven,
 
 I am currently working with IoT and MQTT is necessary. At this point I use 
 mosquitto as the broker and your Pharo client is nice to have and I will 
 test it and give you feedback.
>>> 
>>> That is good to here, Phil.
>>> 
>>> Yes, such real world testing is much needed. This is actually quite fun 
>>> stuff to experiment with. Let me know how it goes.
>>> 
>>> Sven
>>> 
 I've got a working microPython codebase so can compare what is in there 
 (this for the LoPy device):
 
 Thx for the module!
 
 Phil
 
 On Wed, Dec 21, 2016 at 12:15 PM, Sven Van Caekenberghe  
 wrote:
 Hi,
 
 MQTT is a light-weight publish/subscribe messaging protocol, originally 
 created around 1998. It is now an official open industry ISO standard. It 
 is perfect for large-scale Internet of Things applications and high 
 performance mobile messaging.
 
 The publish/subscribe messaging pattern requires a message broker. The 
 broker is responsible for distributing messages to interested clients 
 based on the topic of a message. Parties communicating with each other 
 over MQTT would all be clients in different roles, like producers and 
 consumers, using the broker as middleware.
 
 Many client libraries for different programming languages and multiple 
 brokers/servers are available. Facebook Messenger and Amazon AWS IOT are 
 two users, among many others.
 
 
 A good client library for Pharo was not yet available. I started a new 
 MQTT project and I am looking for collaborators to help me finish it. The 
 official specification is quite readable and there is a lot of information 
 available (see the References/Links section at the end).
 
 
 Right now, a first version of the following features is available:
 
 - reading & writing of all 14 binary packet types
 
 - an experimental client with support for connection open/close, ping, 
 subscribe/unsubscribe, QoS levels 0 (at most once), 1 (at least once) and 
 2 (exactly once) for application (publish) messages in both directions, 
 message/package IDs and keep alive (heartbeat)
 
 - unit tests, for packet reading/writing and for clients against 3 
 publicly available sandbox/test brokers
 
 Basically, the code works but needs polishing and maturing. Also, it might 
 be useful to experiment with alternative client API design. Not all 
 features are yet implemented. It would also be nice to implement an actual 
 server/broker, not to replace production quality servers, but as a proof 
 of concept and tools during development.
 
 
 Code
 
 http://smalltalkhub.com/#!/~SvenVanCaekenberghe/MQTT/
 
 Right now, documentation is limited, but there are class comments and the 
 most important public API methods are commented too. There is no Metacello 
 configuration yet, just load the 3 packages.
 
 
 References/Links
 
 - http://mqtt.org
 - https://en.wikipedia.org/wiki/MQTT
 - http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html
 - https://github.com/mqtt/mqtt.github.io/wiki/software
 - http://mosquitto.org
 - https://github.com/emqtt/emqttd
 - http://kamilfb.github.io/mqtt-spy/
 - https://github.com/eclipse/paho.mqtt-spy/wiki
 - https://eclipse.org/paho/
 - https://eclipse.org/paho/clients/c/embedded/
 - http://www.rabbitmq.com/mqtt.html
 - https://vernemq.com
 - 
 

Re: [Pharo-dev] MQTT for Pharo

[Sven Van Caekenberghe]

> On 21 Dec 2016, at 16:04, Henrik Johansen  
> wrote:
> 
>> 
>> On 21 Dec 2016, at 14:57 , Sven Van Caekenberghe  wrote:
>> 
>> Hendrik,
>> 
>> Thank you for this detailed feedback.
>> 
>>> On 21 Dec 2016, at 12:44, Henrik Johansen  
>>> wrote:
>>> 
>>> Hi Sven!
>>> One thing I noticed when testing the RabbitMQ client with keepalive > 0, 
>>> was connection being closed and all subscriptions lost when receiving large 
>>> payloads, due to timeout before the keepalive packet could be sent before 
>>> waiting to receive next object.
>> 
>> Indeed, I used my Stamp (STOMP) Rabbit MQ client as a model for the MQTT one 
>> - there is a lot of similarity, especially in concept.
>> 
>> Keep alive processing is not that easy. I tried to do it by using read 
>> timeouts as a source of regular opportunities to check for the need to 
>> process keep alive logic. But of course, if you have no outstanding read (in 
>> a loop), that won't work.
>> 
>> The fact that receiving a large payload would trigger an actual keep alive 
>> time out is not something that I have seen myself. It seems weird that the 
>> reading/transferring of incoming data would not count as activity against 
>> keep alive, no ?
> 
> I never had a chance to investigate fully, but I distinctly remember having 
> the same reaction!
> It's quite awhile ago now, so my memory might be hazy, take the following 
> with an appropriate amount of grains of salt.
> 
> The first times I encountered it, it seemed quite random, occuring after 
> extended periods of client inactivity after receiving only small payloads...
> Setting a much shorter keepalive timeout than the default was/is very useful 
> in reproducing/verifying if it is an issue.
> The timeouts then occurred relatively shortly after I'd received a single 
> payload with no other activity, and disappeared once I removed the resetting 
> of lastActivity timestamp on reads, indicating that for at least rabbitmq 
> (3.5 was the version at the time, I believe), receiving data was *not* being 
> counted as keep-alive activity.
> 
> The issue of receiving large payloads blocking writing in time was still 
> unresolved, consistently cut off in the middle of (its own!) multi-MB payload 
> transfers due to keepalive packet not being sent.
> I couldn't see a solution other than abandoning the elegant single-threaded 
> approach and do keepalive as a separate high-priority process, but the 
> architectural choice for the app  changed at this point to not include a MQ 
> in first delivery, so the more involved rewrite for doing so before deploying 
> in production, kinda got stranded :/

Instinctively it feels like messaging and multi-MB payloads would not be a good 
fit, at least I would suspect that they are an edge case. But maybe I am wrong.

I think that the code in StampMedium>>#readBodyBytes: and 
StampMedium>>#readBodyString: could be refactored to use a loop with chunk 
buffers and at the same time check the elapsed time to fire back keep alive 
pings if necessary. A ping too much would not hurt, better safe than sorry. But 
is is hard to catch any/all network slowdowns, any IO operation could 
hang/timeout.

But all this would assume that the problematic situation can be recreated.

> Cheers,
> Henry

Re: [Pharo-dev] MQTT for Pharo

[Henrik Johansen]

> On 21 Dec 2016, at 14:57 , Sven Van Caekenberghe  wrote:
> 
> Hendrik,
> 
> Thank you for this detailed feedback.
> 
>> On 21 Dec 2016, at 12:44, Henrik Johansen  
>> wrote:
>> 
>> Hi Sven!
>> One thing I noticed when testing the RabbitMQ client with keepalive > 0, was 
>> connection being closed and all subscriptions lost when receiving large 
>> payloads, due to timeout before the keepalive packet could be sent before 
>> waiting to receive next object.
> 
> Indeed, I used my Stamp (STOMP) Rabbit MQ client as a model for the MQTT one 
> - there is a lot of similarity, especially in concept.
> 
> Keep alive processing is not that easy. I tried to do it by using read 
> timeouts as a source of regular opportunities to check for the need to 
> process keep alive logic. But of course, if you have no outstanding read (in 
> a loop), that won't work.
> 
> The fact that receiving a large payload would trigger an actual keep alive 
> time out is not something that I have seen myself. It seems weird that the 
> reading/transferring of incoming data would not count as activity against 
> keep alive, no ?

I never had a chance to investigate fully, but I distinctly remember having the 
same reaction!
It's quite awhile ago now, so my memory might be hazy, take the following with 
an appropriate amount of grains of salt.

The first times I encountered it, it seemed quite random, occuring after 
extended periods of client inactivity after receiving only small payloads...
Setting a much shorter keepalive timeout than the default was/is very useful in 
reproducing/verifying if it is an issue.
The timeouts then occurred relatively shortly after I'd received a single 
payload with no other activity, and disappeared once I removed the resetting of 
lastActivity timestamp on reads, indicating that for at least rabbitmq (3.5 was 
the version at the time, I believe), receiving data was *not* being counted as 
keep-alive activity.

The issue of receiving large payloads blocking writing in time was still 
unresolved, consistently cut off in the middle of (its own!) multi-MB payload 
transfers due to keepalive packet not being sent.
I couldn't see a solution other than abandoning the elegant single-threaded 
approach and do keepalive as a separate high-priority process, but the 
architectural choice for the app  changed at this point to not include a MQ in 
first delivery, so the more involved rewrite for doing so before deploying in 
production, kinda got stranded :/

Cheers,
Henry

Re: [Pharo-dev] MQTT for Pharo

[Ben Coman]

You might like to collaborate with Tim and Craig.
http://forum.world.st/Graphing-weather-data-td4927701.html
cheers -ben

On Wed, Dec 21, 2016 at 10:17 PM, Sven Van Caekenberghe  wrote:
>
>> On 21 Dec 2016, at 15:11, p...@highoctane.be wrote:
>>
>> FWIW get yourself an account at http://enco.io
>
> OK, I'll put it on my list of things to look at.
>
>> The devportal has mqtt endpoints so that we can integrate with that and 
>> possibly have some market place solutions offered and running with Pharo.
>>
>> I have a small EnCoClient class in Pharo that works. Now making the API 
>> support more extensive.
>>
>> Docs: http://docs.enco.io/docs/device-sensor-apis
>>
>> Phil
>>
>> On Wed, Dec 21, 2016 at 2:59 PM, Sven Van Caekenberghe  wrote:
>>
>> > On 21 Dec 2016, at 12:50, p...@highoctane.be wrote:
>> >
>> > Sven,
>> >
>> > I am currently working with IoT and MQTT is necessary. At this point I use 
>> > mosquitto as the broker and your Pharo client is nice to have and I will 
>> > test it and give you feedback.
>>
>> That is good to here, Phil.
>>
>> Yes, such real world testing is much needed. This is actually quite fun 
>> stuff to experiment with. Let me know how it goes.
>>
>> Sven
>>
>> > I've got a working microPython codebase so can compare what is in there 
>> > (this for the LoPy device):
>> >
>> > Thx for the module!
>> >
>> > Phil
>> >
>> > On Wed, Dec 21, 2016 at 12:15 PM, Sven Van Caekenberghe  
>> > wrote:
>> > Hi,
>> >
>> > MQTT is a light-weight publish/subscribe messaging protocol, originally 
>> > created around 1998. It is now an official open industry ISO standard. It 
>> > is perfect for large-scale Internet of Things applications and high 
>> > performance mobile messaging.
>> >
>> > The publish/subscribe messaging pattern requires a message broker. The 
>> > broker is responsible for distributing messages to interested clients 
>> > based on the topic of a message. Parties communicating with each other 
>> > over MQTT would all be clients in different roles, like producers and 
>> > consumers, using the broker as middleware.
>> >
>> > Many client libraries for different programming languages and multiple 
>> > brokers/servers are available. Facebook Messenger and Amazon AWS IOT are 
>> > two users, among many others.
>> >
>> >
>> > A good client library for Pharo was not yet available. I started a new 
>> > MQTT project and I am looking for collaborators to help me finish it. The 
>> > official specification is quite readable and there is a lot of information 
>> > available (see the References/Links section at the end).
>> >
>> >
>> > Right now, a first version of the following features is available:
>> >
>> >  - reading & writing of all 14 binary packet types
>> >
>> >  - an experimental client with support for connection open/close, ping, 
>> > subscribe/unsubscribe, QoS levels 0 (at most once), 1 (at least once) and 
>> > 2 (exactly once) for application (publish) messages in both directions, 
>> > message/package IDs and keep alive (heartbeat)
>> >
>> >  - unit tests, for packet reading/writing and for clients against 3 
>> > publicly available sandbox/test brokers
>> >
>> > Basically, the code works but needs polishing and maturing. Also, it might 
>> > be useful to experiment with alternative client API design. Not all 
>> > features are yet implemented. It would also be nice to implement an actual 
>> > server/broker, not to replace production quality servers, but as a proof 
>> > of concept and tools during development.
>> >
>> >
>> > Code
>> >
>> > http://smalltalkhub.com/#!/~SvenVanCaekenberghe/MQTT/
>> >
>> > Right now, documentation is limited, but there are class comments and the 
>> > most important public API methods are commented too. There is no Metacello 
>> > configuration yet, just load the 3 packages.
>> >
>> >
>> > References/Links
>> >
>> >  - http://mqtt.org
>> >  - https://en.wikipedia.org/wiki/MQTT
>> >  - http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html
>> >  - https://github.com/mqtt/mqtt.github.io/wiki/software
>> >  - http://mosquitto.org
>> >  - https://github.com/emqtt/emqttd
>> >  - http://kamilfb.github.io/mqtt-spy/
>> >  - https://github.com/eclipse/paho.mqtt-spy/wiki
>> >  - https://eclipse.org/paho/
>> >  - https://eclipse.org/paho/clients/c/embedded/
>> >  - http://www.rabbitmq.com/mqtt.html
>> >  - https://vernemq.com
>> >  - 
>> > https://www.ibm.com/developerworks/community/blogs/c565c720-fe84-4f63-873f-607d87787327/entry/mqtt_security
>> >
>> >
>> > Sandbox/test Servers/Brokers
>> >
>> > iot.eclipse.org:1883
>> > test.mosquitto.org:1883
>> > broker.mqtt-dashboard.com:1883
>> >
>> >
>> > Sven
>> >
>> > --
>> > Sven Van Caekenberghe
>> > http://stfx.eu
>> > Smalltalk is the Red Pill
>> >
>> >
>> >
>>
>>
>>
>
>

Re: [Pharo-dev] MQTT for Pharo

[Sven Van Caekenberghe]

> On 21 Dec 2016, at 15:11, p...@highoctane.be wrote:
> 
> FWIW get yourself an account at http://enco.io 

OK, I'll put it on my list of things to look at.

> The devportal has mqtt endpoints so that we can integrate with that and 
> possibly have some market place solutions offered and running with Pharo.
> 
> I have a small EnCoClient class in Pharo that works. Now making the API 
> support more extensive.
> 
> Docs: http://docs.enco.io/docs/device-sensor-apis
> 
> Phil
> 
> On Wed, Dec 21, 2016 at 2:59 PM, Sven Van Caekenberghe  wrote:
> 
> > On 21 Dec 2016, at 12:50, p...@highoctane.be wrote:
> >
> > Sven,
> >
> > I am currently working with IoT and MQTT is necessary. At this point I use 
> > mosquitto as the broker and your Pharo client is nice to have and I will 
> > test it and give you feedback.
> 
> That is good to here, Phil.
> 
> Yes, such real world testing is much needed. This is actually quite fun stuff 
> to experiment with. Let me know how it goes.
> 
> Sven
> 
> > I've got a working microPython codebase so can compare what is in there 
> > (this for the LoPy device):
> >
> > Thx for the module!
> >
> > Phil
> >
> > On Wed, Dec 21, 2016 at 12:15 PM, Sven Van Caekenberghe  
> > wrote:
> > Hi,
> >
> > MQTT is a light-weight publish/subscribe messaging protocol, originally 
> > created around 1998. It is now an official open industry ISO standard. It 
> > is perfect for large-scale Internet of Things applications and high 
> > performance mobile messaging.
> >
> > The publish/subscribe messaging pattern requires a message broker. The 
> > broker is responsible for distributing messages to interested clients based 
> > on the topic of a message. Parties communicating with each other over MQTT 
> > would all be clients in different roles, like producers and consumers, 
> > using the broker as middleware.
> >
> > Many client libraries for different programming languages and multiple 
> > brokers/servers are available. Facebook Messenger and Amazon AWS IOT are 
> > two users, among many others.
> >
> >
> > A good client library for Pharo was not yet available. I started a new MQTT 
> > project and I am looking for collaborators to help me finish it. The 
> > official specification is quite readable and there is a lot of information 
> > available (see the References/Links section at the end).
> >
> >
> > Right now, a first version of the following features is available:
> >
> >  - reading & writing of all 14 binary packet types
> >
> >  - an experimental client with support for connection open/close, ping, 
> > subscribe/unsubscribe, QoS levels 0 (at most once), 1 (at least once) and 2 
> > (exactly once) for application (publish) messages in both directions, 
> > message/package IDs and keep alive (heartbeat)
> >
> >  - unit tests, for packet reading/writing and for clients against 3 
> > publicly available sandbox/test brokers
> >
> > Basically, the code works but needs polishing and maturing. Also, it might 
> > be useful to experiment with alternative client API design. Not all 
> > features are yet implemented. It would also be nice to implement an actual 
> > server/broker, not to replace production quality servers, but as a proof of 
> > concept and tools during development.
> >
> >
> > Code
> >
> > http://smalltalkhub.com/#!/~SvenVanCaekenberghe/MQTT/
> >
> > Right now, documentation is limited, but there are class comments and the 
> > most important public API methods are commented too. There is no Metacello 
> > configuration yet, just load the 3 packages.
> >
> >
> > References/Links
> >
> >  - http://mqtt.org
> >  - https://en.wikipedia.org/wiki/MQTT
> >  - http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html
> >  - https://github.com/mqtt/mqtt.github.io/wiki/software
> >  - http://mosquitto.org
> >  - https://github.com/emqtt/emqttd
> >  - http://kamilfb.github.io/mqtt-spy/
> >  - https://github.com/eclipse/paho.mqtt-spy/wiki
> >  - https://eclipse.org/paho/
> >  - https://eclipse.org/paho/clients/c/embedded/
> >  - http://www.rabbitmq.com/mqtt.html
> >  - https://vernemq.com
> >  - 
> > https://www.ibm.com/developerworks/community/blogs/c565c720-fe84-4f63-873f-607d87787327/entry/mqtt_security
> >
> >
> > Sandbox/test Servers/Brokers
> >
> > iot.eclipse.org:1883
> > test.mosquitto.org:1883
> > broker.mqtt-dashboard.com:1883
> >
> >
> > Sven
> >
> > --
> > Sven Van Caekenberghe
> > http://stfx.eu
> > Smalltalk is the Red Pill
> >
> >
> >
> 
> 
> 

Re: [Pharo-dev] MQTT for Pharo

[p...@highoctane.be]

FWIW get yourself an account at http://enco.io

The devportal has mqtt endpoints so that we can integrate with that and
possibly have some market place solutions offered and running with Pharo.

I have a small EnCoClient class in Pharo that works. Now making the API
support more extensive.

Docs: http://docs.enco.io/docs/device-sensor-apis

Phil

On Wed, Dec 21, 2016 at 2:59 PM, Sven Van Caekenberghe  wrote:

>
> > On 21 Dec 2016, at 12:50, p...@highoctane.be wrote:
> >
> > Sven,
> >
> > I am currently working with IoT and MQTT is necessary. At this point I
> use mosquitto as the broker and your Pharo client is nice to have and I
> will test it and give you feedback.
>
> That is good to here, Phil.
>
> Yes, such real world testing is much needed. This is actually quite fun
> stuff to experiment with. Let me know how it goes.
>
> Sven
>
> > I've got a working microPython codebase so can compare what is in there
> (this for the LoPy device):
> >
> > Thx for the module!
> >
> > Phil
> >
> > On Wed, Dec 21, 2016 at 12:15 PM, Sven Van Caekenberghe 
> wrote:
> > Hi,
> >
> > MQTT is a light-weight publish/subscribe messaging protocol, originally
> created around 1998. It is now an official open industry ISO standard. It
> is perfect for large-scale Internet of Things applications and high
> performance mobile messaging.
> >
> > The publish/subscribe messaging pattern requires a message broker. The
> broker is responsible for distributing messages to interested clients based
> on the topic of a message. Parties communicating with each other over MQTT
> would all be clients in different roles, like producers and consumers,
> using the broker as middleware.
> >
> > Many client libraries for different programming languages and multiple
> brokers/servers are available. Facebook Messenger and Amazon AWS IOT are
> two users, among many others.
> >
> >
> > A good client library for Pharo was not yet available. I started a new
> MQTT project and I am looking for collaborators to help me finish it. The
> official specification is quite readable and there is a lot of information
> available (see the References/Links section at the end).
> >
> >
> > Right now, a first version of the following features is available:
> >
> >  - reading & writing of all 14 binary packet types
> >
> >  - an experimental client with support for connection open/close, ping,
> subscribe/unsubscribe, QoS levels 0 (at most once), 1 (at least once) and 2
> (exactly once) for application (publish) messages in both directions,
> message/package IDs and keep alive (heartbeat)
> >
> >  - unit tests, for packet reading/writing and for clients against 3
> publicly available sandbox/test brokers
> >
> > Basically, the code works but needs polishing and maturing. Also, it
> might be useful to experiment with alternative client API design. Not all
> features are yet implemented. It would also be nice to implement an actual
> server/broker, not to replace production quality servers, but as a proof of
> concept and tools during development.
> >
> >
> > Code
> >
> > http://smalltalkhub.com/#!/~SvenVanCaekenberghe/MQTT/
> >
> > Right now, documentation is limited, but there are class comments and
> the most important public API methods are commented too. There is no
> Metacello configuration yet, just load the 3 packages.
> >
> >
> > References/Links
> >
> >  - http://mqtt.org
> >  - https://en.wikipedia.org/wiki/MQTT
> >  - http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html
> >  - https://github.com/mqtt/mqtt.github.io/wiki/software
> >  - http://mosquitto.org
> >  - https://github.com/emqtt/emqttd
> >  - http://kamilfb.github.io/mqtt-spy/
> >  - https://github.com/eclipse/paho.mqtt-spy/wiki
> >  - https://eclipse.org/paho/
> >  - https://eclipse.org/paho/clients/c/embedded/
> >  - http://www.rabbitmq.com/mqtt.html
> >  - https://vernemq.com
> >  - https://www.ibm.com/developerworks/community/
> blogs/c565c720-fe84-4f63-873f-607d87787327/entry/mqtt_security
> >
> >
> > Sandbox/test Servers/Brokers
> >
> > iot.eclipse.org:1883
> > test.mosquitto.org:1883
> > broker.mqtt-dashboard.com:1883
> >
> >
> > Sven
> >
> > --
> > Sven Van Caekenberghe
> > http://stfx.eu
> > Smalltalk is the Red Pill
> >
> >
> >
>
>
>

Re: [Pharo-dev] MQTT for Pharo

[Sven Van Caekenberghe]

> On 21 Dec 2016, at 12:50, p...@highoctane.be wrote:
> 
> Sven,
> 
> I am currently working with IoT and MQTT is necessary. At this point I use 
> mosquitto as the broker and your Pharo client is nice to have and I will test 
> it and give you feedback.

That is good to here, Phil.

Yes, such real world testing is much needed. This is actually quite fun stuff 
to experiment with. Let me know how it goes.

Sven

> I've got a working microPython codebase so can compare what is in there (this 
> for the LoPy device):
> 
> Thx for the module!
> 
> Phil
> 
> On Wed, Dec 21, 2016 at 12:15 PM, Sven Van Caekenberghe  wrote:
> Hi,
> 
> MQTT is a light-weight publish/subscribe messaging protocol, originally 
> created around 1998. It is now an official open industry ISO standard. It is 
> perfect for large-scale Internet of Things applications and high performance 
> mobile messaging.
> 
> The publish/subscribe messaging pattern requires a message broker. The broker 
> is responsible for distributing messages to interested clients based on the 
> topic of a message. Parties communicating with each other over MQTT would all 
> be clients in different roles, like producers and consumers, using the broker 
> as middleware.
> 
> Many client libraries for different programming languages and multiple 
> brokers/servers are available. Facebook Messenger and Amazon AWS IOT are two 
> users, among many others.
> 
> 
> A good client library for Pharo was not yet available. I started a new MQTT 
> project and I am looking for collaborators to help me finish it. The official 
> specification is quite readable and there is a lot of information available 
> (see the References/Links section at the end).
> 
> 
> Right now, a first version of the following features is available:
> 
>  - reading & writing of all 14 binary packet types
> 
>  - an experimental client with support for connection open/close, ping, 
> subscribe/unsubscribe, QoS levels 0 (at most once), 1 (at least once) and 2 
> (exactly once) for application (publish) messages in both directions, 
> message/package IDs and keep alive (heartbeat)
> 
>  - unit tests, for packet reading/writing and for clients against 3 publicly 
> available sandbox/test brokers
> 
> Basically, the code works but needs polishing and maturing. Also, it might be 
> useful to experiment with alternative client API design. Not all features are 
> yet implemented. It would also be nice to implement an actual server/broker, 
> not to replace production quality servers, but as a proof of concept and 
> tools during development.
> 
> 
> Code
> 
> http://smalltalkhub.com/#!/~SvenVanCaekenberghe/MQTT/
> 
> Right now, documentation is limited, but there are class comments and the 
> most important public API methods are commented too. There is no Metacello 
> configuration yet, just load the 3 packages.
> 
> 
> References/Links
> 
>  - http://mqtt.org
>  - https://en.wikipedia.org/wiki/MQTT
>  - http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html
>  - https://github.com/mqtt/mqtt.github.io/wiki/software
>  - http://mosquitto.org
>  - https://github.com/emqtt/emqttd
>  - http://kamilfb.github.io/mqtt-spy/
>  - https://github.com/eclipse/paho.mqtt-spy/wiki
>  - https://eclipse.org/paho/
>  - https://eclipse.org/paho/clients/c/embedded/
>  - http://www.rabbitmq.com/mqtt.html
>  - https://vernemq.com
>  - 
> https://www.ibm.com/developerworks/community/blogs/c565c720-fe84-4f63-873f-607d87787327/entry/mqtt_security
> 
> 
> Sandbox/test Servers/Brokers
> 
> iot.eclipse.org:1883
> test.mosquitto.org:1883
> broker.mqtt-dashboard.com:1883
> 
> 
> Sven
> 
> --
> Sven Van Caekenberghe
> http://stfx.eu
> Smalltalk is the Red Pill
> 
> 
> 

Re: [Pharo-dev] MQTT for Pharo

[Sven Van Caekenberghe]

Hendrik,

Thank you for this detailed feedback.

> On 21 Dec 2016, at 12:44, Henrik Johansen  
> wrote:
> 
> Hi Sven!
> One thing I noticed when testing the RabbitMQ client with keepalive > 0, was 
> connection being closed and all subscriptions lost when receiving large 
> payloads, due to timeout before the keepalive packet could be sent before 
> waiting to receive next object.

Indeed, I used my Stamp (STOMP) Rabbit MQ client as a model for the MQTT one - 
there is a lot of similarity, especially in concept.

Keep alive processing is not that easy. I tried to do it by using read timeouts 
as a source of regular opportunities to check for the need to process keep 
alive logic. But of course, if you have no outstanding read (in a loop), that 
won't work.

The fact that receiving a large payload would trigger an actual keep alive time 
out is not something that I have seen myself. It seems weird that the 
reading/transferring of incoming data would not count as activity against keep 
alive, no ?

> I see the default in ExperimentalClient is to disregard ConnectionTimedOut 
> when that happens, and resend a ping.

I use a similar technique, yes,

> Are MQTT servers generally more lenient wrt dropping subscriptions once the 
> timeout occurs, or will that lead to no new data being received from the 
> broker?

I don't know. I think this needs to be sorted out during actual usage.

Note that MQTT has to the concept of resuming an existing session that keeps 
subscriptions and outstanding undelivered data. I have not explored that area.

> (Also, doesn't there need to be a guarantee that timeout < keepalive when 
> keepalive is > 0, for this logic to work as intended?)

Yes, that is something that should be enforced.

BTW, the MQTT spec says:

<<
If the Keep Alive value is non-zero and the Server does not receive a Control 
Packet from the Client within one and a half times the Keep Alive time period, 
it MUST disconnect the Network Connection to the Client as if the network had 
failed [MQTT-3.1.2-24].
>>

So I guess there is some leniency.

Sven

> Cheers,
> Henry
> 
>> On 21 Dec 2016, at 12:15 , Sven Van Caekenberghe  wrote:
>> 
>> Hi,
>> 
>> MQTT is a light-weight publish/subscribe messaging protocol, originally 
>> created around 1998. It is now an official open industry ISO standard. It is 
>> perfect for large-scale Internet of Things applications and high performance 
>> mobile messaging.
>> 
>> The publish/subscribe messaging pattern requires a message broker. The 
>> broker is responsible for distributing messages to interested clients based 
>> on the topic of a message. Parties communicating with each other over MQTT 
>> would all be clients in different roles, like producers and consumers, using 
>> the broker as middleware.
>> 
>> Many client libraries for different programming languages and multiple 
>> brokers/servers are available. Facebook Messenger and Amazon AWS IOT are two 
>> users, among many others.
>> 
>> 
>> A good client library for Pharo was not yet available. I started a new MQTT 
>> project and I am looking for collaborators to help me finish it. The 
>> official specification is quite readable and there is a lot of information 
>> available (see the References/Links section at the end).
>> 
>> 
>> Right now, a first version of the following features is available:
>> 
>> - reading & writing of all 14 binary packet types
>> 
>> - an experimental client with support for connection open/close, ping, 
>> subscribe/unsubscribe, QoS levels 0 (at most once), 1 (at least once) and 2 
>> (exactly once) for application (publish) messages in both directions, 
>> message/package IDs and keep alive (heartbeat)
>> 
>> - unit tests, for packet reading/writing and for clients against 3 publicly 
>> available sandbox/test brokers
>> 
>> Basically, the code works but needs polishing and maturing. Also, it might 
>> be useful to experiment with alternative client API design. Not all features 
>> are yet implemented. It would also be nice to implement an actual 
>> server/broker, not to replace production quality servers, but as a proof of 
>> concept and tools during development.
>> 
>> 
>> Code
>> 
>> http://smalltalkhub.com/#!/~SvenVanCaekenberghe/MQTT/
>> 
>> Right now, documentation is limited, but there are class comments and the 
>> most important public API methods are commented too. There is no Metacello 
>> configuration yet, just load the 3 packages.
>> 
>> 
>> References/Links
>> 
>> - http://mqtt.org
>> - https://en.wikipedia.org/wiki/MQTT
>> - http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html
>> - https://github.com/mqtt/mqtt.github.io/wiki/software
>> - http://mosquitto.org
>> - https://github.com/emqtt/emqttd
>> - http://kamilfb.github.io/mqtt-spy/
>> - https://github.com/eclipse/paho.mqtt-spy/wiki
>> - https://eclipse.org/paho/
>> - https://eclipse.org/paho/clients/c/embedded/
>> - http://www.rabbitmq.com/mqtt.html
>> - 

Re: [Pharo-dev] MQTT for Pharo

[p...@highoctane.be]

Sven,

I am currently working with IoT and MQTT is necessary. At this point I use
mosquitto as the broker and your Pharo client is nice to have and I will
test it and give you feedback.

I've got a working microPython codebase so can compare what is in there
(this for the LoPy device):

Thx for the module!

Phil

On Wed, Dec 21, 2016 at 12:15 PM, Sven Van Caekenberghe 
wrote:

> Hi,
>
> MQTT is a light-weight publish/subscribe messaging protocol, originally
> created around 1998. It is now an official open industry ISO standard. It
> is perfect for large-scale Internet of Things applications and high
> performance mobile messaging.
>
> The publish/subscribe messaging pattern requires a message broker. The
> broker is responsible for distributing messages to interested clients based
> on the topic of a message. Parties communicating with each other over MQTT
> would all be clients in different roles, like producers and consumers,
> using the broker as middleware.
>
> Many client libraries for different programming languages and multiple
> brokers/servers are available. Facebook Messenger and Amazon AWS IOT are
> two users, among many others.
>
>
> A good client library for Pharo was not yet available. I started a new
> MQTT project and I am looking for collaborators to help me finish it. The
> official specification is quite readable and there is a lot of information
> available (see the References/Links section at the end).
>
>
> Right now, a first version of the following features is available:
>
>  - reading & writing of all 14 binary packet types
>
>  - an experimental client with support for connection open/close, ping,
> subscribe/unsubscribe, QoS levels 0 (at most once), 1 (at least once) and 2
> (exactly once) for application (publish) messages in both directions,
> message/package IDs and keep alive (heartbeat)
>
>  - unit tests, for packet reading/writing and for clients against 3
> publicly available sandbox/test brokers
>
> Basically, the code works but needs polishing and maturing. Also, it might
> be useful to experiment with alternative client API design. Not all
> features are yet implemented. It would also be nice to implement an actual
> server/broker, not to replace production quality servers, but as a proof of
> concept and tools during development.
>
>
> Code
>
> http://smalltalkhub.com/#!/~SvenVanCaekenberghe/MQTT/
>
> Right now, documentation is limited, but there are class comments and the
> most important public API methods are commented too. There is no Metacello
> configuration yet, just load the 3 packages.
>
>
> References/Links
>
>  - http://mqtt.org
>  - https://en.wikipedia.org/wiki/MQTT
>  - http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html
>  - https://github.com/mqtt/mqtt.github.io/wiki/software
>  - http://mosquitto.org
>  - https://github.com/emqtt/emqttd
>  - http://kamilfb.github.io/mqtt-spy/
>  - https://github.com/eclipse/paho.mqtt-spy/wiki
>  - https://eclipse.org/paho/
>  - https://eclipse.org/paho/clients/c/embedded/
>  - http://www.rabbitmq.com/mqtt.html
>  - https://vernemq.com
>  - https://www.ibm.com/developerworks/community/
> blogs/c565c720-fe84-4f63-873f-607d87787327/entry/mqtt_security
>
>
> Sandbox/test Servers/Brokers
>
> iot.eclipse.org:1883
> test.mosquitto.org:1883
> broker.mqtt-dashboard.com:1883
>
>
> Sven
>
> --
> Sven Van Caekenberghe
> http://stfx.eu
> Smalltalk is the Red Pill
>
>
>

Re: [Pharo-dev] MQTT for Pharo

[Henrik Johansen]

Hi Sven!
One thing I noticed when testing the RabbitMQ client with keepalive > 0, was 
connection being closed and all subscriptions lost when receiving large 
payloads, due to timeout before the keepalive packet could be sent before 
waiting to receive next object.

I see the default in ExperimentalClient is to disregard ConnectionTimedOut when 
that happens, and resend a ping.
Are MQTT servers generally more lenient wrt dropping subscriptions once the 
timeout occurs, or will that lead to no new data being received from the broker?
(Also, doesn't there need to be a guarantee that timeout < keepalive when 
keepalive is > 0, for this logic to work as intended?)

Cheers,
Henry

> On 21 Dec 2016, at 12:15 , Sven Van Caekenberghe  wrote:
> 
> Hi,
> 
> MQTT is a light-weight publish/subscribe messaging protocol, originally 
> created around 1998. It is now an official open industry ISO standard. It is 
> perfect for large-scale Internet of Things applications and high performance 
> mobile messaging.
> 
> The publish/subscribe messaging pattern requires a message broker. The broker 
> is responsible for distributing messages to interested clients based on the 
> topic of a message. Parties communicating with each other over MQTT would all 
> be clients in different roles, like producers and consumers, using the broker 
> as middleware.
> 
> Many client libraries for different programming languages and multiple 
> brokers/servers are available. Facebook Messenger and Amazon AWS IOT are two 
> users, among many others.
> 
> 
> A good client library for Pharo was not yet available. I started a new MQTT 
> project and I am looking for collaborators to help me finish it. The official 
> specification is quite readable and there is a lot of information available 
> (see the References/Links section at the end).
> 
> 
> Right now, a first version of the following features is available:
> 
> - reading & writing of all 14 binary packet types
> 
> - an experimental client with support for connection open/close, ping, 
> subscribe/unsubscribe, QoS levels 0 (at most once), 1 (at least once) and 2 
> (exactly once) for application (publish) messages in both directions, 
> message/package IDs and keep alive (heartbeat)
> 
> - unit tests, for packet reading/writing and for clients against 3 publicly 
> available sandbox/test brokers
> 
> Basically, the code works but needs polishing and maturing. Also, it might be 
> useful to experiment with alternative client API design. Not all features are 
> yet implemented. It would also be nice to implement an actual server/broker, 
> not to replace production quality servers, but as a proof of concept and 
> tools during development.
> 
> 
> Code
> 
> http://smalltalkhub.com/#!/~SvenVanCaekenberghe/MQTT/
> 
> Right now, documentation is limited, but there are class comments and the 
> most important public API methods are commented too. There is no Metacello 
> configuration yet, just load the 3 packages.
> 
> 
> References/Links
> 
> - http://mqtt.org
> - https://en.wikipedia.org/wiki/MQTT
> - http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html
> - https://github.com/mqtt/mqtt.github.io/wiki/software
> - http://mosquitto.org
> - https://github.com/emqtt/emqttd
> - http://kamilfb.github.io/mqtt-spy/
> - https://github.com/eclipse/paho.mqtt-spy/wiki
> - https://eclipse.org/paho/
> - https://eclipse.org/paho/clients/c/embedded/
> - http://www.rabbitmq.com/mqtt.html
> - https://vernemq.com
> - 
> https://www.ibm.com/developerworks/community/blogs/c565c720-fe84-4f63-873f-607d87787327/entry/mqtt_security
> 
> 
> Sandbox/test Servers/Brokers
> 
> iot.eclipse.org:1883
> test.mosquitto.org:1883
> broker.mqtt-dashboard.com:1883
> 
> 
> Sven
> 
> --
> Sven Van Caekenberghe
> http://stfx.eu
> Smalltalk is the Red Pill
> 
>