Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] Paho Python Client

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. :)

Best,
Dominik

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

Back to the top