Hendrik, Thank you for this detailed feedback.
On 21 Dec 2016, at 12:44, Henrik Johansen <henrik.s.johansen@veloxit.no> 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 <sven@stfx.eu> 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-6...
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