Hendrik, Thank you for this detailed feedback.
> On 21 Dec 2016, at 12:44, Henrik Johansen <henrik.s.johan...@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 <s...@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-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 >> >> > >
