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 <[email protected]> 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 > >
