Hi Roger,
thanks a lot for the detailed answer!
After giving this a bit more thought and reading the spec, it seems the behaviour is indeed correct. I was just surprised by the behaviour that neither the connect nor the subscribe method are waiting for the responses. Brokers of course need to handle that. The behaviour you described with the callbacks makes sense to me.
For new users of the library it may be worth pointing out that the connect / subscribe / publish methods are not blocking and the users have to synchronize the code / wait for responses themselves, so maybe one or two sentences about that at the website would clarify this. If this is generally the “Python style” of programming - I’m not a Python person - and users expect this behaviour, please ignore this comment. :)
On 14 Aug 2015 at 01:22:10, Roger Light (roger@xxxxxxxxxx) wrote: Hi Dominik,
I seem to be missing emails from the eclipse lists, yours didn't come through. Luckily I got Nicolas' reply.
> From an architectural perspective it seems that the Python client is highly > callback based. When looking at the front page of the Paho Python website > (https://eclipse.org/paho/clients/python/), the idiom to follow seems to > have a onConnect callback and all further actions should happen in the > onConnect callback (or other callbacks).
The reason for putting calls to e.g. subscribe() in the connect callback is to allow you to be easily resubscribed in the event that the connection drops and you reconnect.
> 1. Is there a synchronous / blocking mode for the API?
No, but it's on the list. I've not had much time to spend on Paho recently I'm afraid. The more significant problem with blocking calls to subscribe particularly is that you've got no idea whether the first response from the broker is going to be a SUBACK or potentially millions of PUBLISH messages.
> Otherwise it seems to > be introduce bugs to do something like the following snippet: > > - - - START SNIPPET - - - > > client.connect(….) > client.subscribe(…) > client.publish(…) > > - - - END SNIPPET - - -
There's nothing wrong with that, the connection will be started and the messages will be queued in order. If you're expecting the subscribe to have completed before the publish occurs - well yes, you'd need to check for that.
> 2. Most of the examples in git (like this file: > http://git.eclipse.org/c/paho/org.eclipse.paho.mqtt.python.git/tree/examples/sub.py) > seem to allow such a programming style. Are the examples obsolete? It seems > the sub.py for example doesn’t always work when using different broker > implementations.
The examples aren't obsolete, just pretty simple. I'm very surprised to hear that sub.py shows bugs, it could barely be any simpler - open a connection, send a CONNECT, send a SUBSCRIBE (yes, without waiting for a CONNACK admittedly) then process incoming messages.
> 3. It seems the Paho interoperability test suite also doesn’t follow the > callback based programming style but use sleep(X). This seems to introduce > race conditions sometimes. So shouldn’t the test suite use callbacks in > order to be correct?
I can't comment on that because it's unrelated to the Python client. I agree using fixed sleep() doesn't seem ideal.
> 4. Does the subscribe(…) method wait until the suback is received before the > next line in python scripts is executed? If not it would be good to add some > additional sleep(X) after subscribing, I have the impression that sometimes > race conditions occur when the client is not yet subscribed (at least the > subscription is not acked) and the client already publishes.
I presume you're not talking about the interop code here. No, the subscribe method isn't blocking. As I mentioned above, it's impossible to predict the amount of time before you receive a SUBACK. If that is something that you can predict for yourself, then a sleep() may be appropriate for you. A more robust solution would be to use the callback to let you know when the subscribe had completed. Maybe I'll put together an example showing that :)
Cheers,
Roger _______________________________________________ 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
|