New to MQTT - create topic programmatically?

[Saify Lanewala]

Hello All.  I was wondering if there is any explicit way to create a topic in (for example) Python.

My current approach is to construct a string and invoke client.publish(...) using that string.  That seems to work, but am hoping for a better way to do it, i.e., an API that looks something like client.createTopic().

Any ideas/guidance would be greatly appreciated.

Thanks.

[Nick O'Leary]

Hi,

you don't need to create topics with MQTT.

Most client libraries will expect you to pass the topic as a string into their publish function - just as you are doing.

Nick

--
To learn more about MQTT please visit http://mqtt.org
---
You received this message because you are subscribed to the Google Groups "MQTT" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mqtt+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mqtt/cfa3038e-326a-4ac2-ab99-2a29005ace07n%40googlegroups.com.

[Saify Lanewala]

Ah, OK.  That's what I'm doing but was hoping for a more clear-cut and easy to identify ways of creating topics.  But this will work for me.  Thanks.

To view this discussion on the web visit https://groups.google.com/d/msgid/mqtt/CAF%3DvhqcSuFfOBA6jQY5kXRt6X0qVVDgqTTRBiK8q065_w4p%2BeA%40mail.gmail.com.

[Jonathan Oxer]

Hi Saify,

I think there's a conceptual issue here that may help make it clearer.

Your question is about "creating" a topic, but that's the wrong way to think about it. A better way to think about it is that topics don't really exist: a topic is more like a tag that is associated with the message.

As a client, you can subscribe to a topic that doesn't exist. There's no need to publish to it first, or do anything else to "create" it. Likewise, there's no way to "delete" a topic, because they don't exist in a persistent way.

If you think of it like a tag, you can imagine the transactions between the clients and a broker being something like this:

Subscribe: client says to broker "please tell me about any messages you receive that are tagged with 'my/topic/here'".

Publish: client says to broker "here's a message which has the tag 'my/topic/here'".

There are complications to this of course (retained messages, etc) but fundamentally it becomes clearer if you don't think of a topic as being a thing that exists, or has to be created or deleted.

Jon

To view this discussion on the web visit https://groups.google.com/d/msgid/mqtt/CAL9JGq%2BVyNP8AV0b1FJxEOuz__JQGmM6qUwFSx50Yi%2B%3DFdejkg%40mail.gmail.com.

[Saify Lanewala]

Thanks for the explanation, Jon!

I come from the world of JMS pub-sub with Topics and Queues. You probably know already how that world works.

I know now that topics are simply "transient" (for lack of a better word) until all messages are consumed (or if there are special retention attributes set).  In my appl, I need to have messages retained until a subscriber explicitly acknowledges receipt, at which time the publisher will delete that message.  The problem is I am not sure exactly how I can do this with MQTT.  The reason for this added complexity is that there may be multiple messages waiting to be consumed, and I cannot assume that I can safely send a message with a null payload; so I need to get rid of only a message that has been successfully received by a subscriber.

ANy ideas would be gratefully acknowledged.

Regards,

Saify

To view this discussion on the web visit https://groups.google.com/d/msgid/mqtt/CADBU0efeV%2BWGPWsVZXK8RSyt4BPHjsFxNky4EC2A_zY_KxV8EA%40mail.gmail.com.

[Philip Couling]

In MQTT, this is only really possible if the subscriber has subscribed first.  There’s no “inbox” for a subscriber that’s never subscribed before.

In MQTT 3.x the message broker is required to retain all undelivered QOS 1 and QOS 2 messages when the client has connected previously with “Clean Session” = 0 and then reconnects with “Clean Session” = 0.  In other words clean session =0 tells the broker to keep the session open even when the client has disconnected.

In MQTT 5 the flags and semantics are a little different but the upshot is the same.  “Session Expiry Interval” tells the broker to keep the session open for a period of time after it disconnects.  Then “Clean Start” indicates that the client want’s to use the previous session if it’s available.

So unlike JMQ or AMQP etc, there isn’t a way to abstractly declare a queue of messages before the subscriber ever connects.  The best you can achieve is to log in with a known client ID, register some subscriptions, and then have your “real” client login with the same client ID and resume the session.

Philip

To view this discussion on the web visit https://groups.google.com/d/msgid/mqtt/CAL9JGq%2B8PSq5Eg7WHKQ%2B8hwzb%2BmrDOoAxTnFiZrsHbuyYAc9CQ%40mail.gmail.com.

[Saify Lanewala]

Thanks Philip. I guess I'm thinking of a poor man's pub-sub that is light-weight like MQTT, but with a few of those bells'n'whistles.  Another way of thinking about my use case is:

New subscriber comes up, and sort-of lets the broker know that it's interested in "point-to-point" msg exchange. It does this by subscribing to a unique topic (perhaps its ip address). Question: Does the process of subscribing create a topic or is that just a placeholder pending something publishing to that topic? I'm hoping the answer is the former!

A publisher needs to "know" that this topic is "available" for it to use. Question: how would it know that?

The actual semantics of which publisher decides which topic to use (i.e., which subscriber it wants to talk to) is not (I think) particularly relevant at this juncture.

Any ideas would be gratefully welcomed.

Saify

To view this discussion on the web visit https://groups.google.com/d/msgid/mqtt/1FE271D3-8826-4BB4-B65C-E75137BEF0C5%40gmail.com.

[Philip Couling]

With the exception of "retained messages" topics are ephemeral in MQTT. A subscriber actually subscribes to patterns (which can have wildcards) on a topic. With wildcards there wouldn't be any one topic to create but an infinite number (well very large at least). So no subscriptions don't typically create a topic (I can't speak for the precise behaviour of every broker).

Negotiating topic names is (almost) entirely the application's responsibility.

MQTT5 offers a couple of tools, the broker can nominate a topic for the clients own use. The child can use that and it's children however it wants safe in the knowledge no other client will use the same one.  Without this you can construct a topic from the client I'd to try to keep it unique.

MQTT5 also has an optional property on a publish messages to specify a return address (topic).  Without this the the client must include the return address in the message body.

To view this discussion on the web visit https://groups.google.com/d/msgid/mqtt/CAL9JGq%2BJTgU_hfvGZjZvYdsLBJnsoyCD%2BE9uuUUjVhFEVa_tuw%40mail.gmail.com.

[Saify Lanewala]

Thanks for the guidance, Philip.

Your point abt optional properties on return address look interesting and I will have to play with that a bit  Will let you know outcome..

Regards,

Saify

You received this message because you are subscribed to a topic in the Google Groups "MQTT" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mqtt/fGgAidkNEIM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mqtt+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mqtt/CANWftzLVbZRuy3091vuzeY1%3DYp-q0tEXytCw1hr%2BO7Ssf90Ogg%40mail.gmail.com.