Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] API Suggestion on the Embedded Paho MQTT Client

Hi Rafael,

ah, now I understand.  That makes sense, yes.

As I started writing this client on mbed, I am using the FP class which aims to make it easy to pass in method parameters as well as global functions.  The limitation of this class is that it can only deal with one parameter, which would mean adding a field to the MessageData structure:

struct MessageData
    MessageData(MQTTString &aTopicName, struct Message &aMessage)  : message(aMessage), topicName(aTopicName)
    { }
    struct Message &message;
    MQTTString &topicName;
    void *context;
and a parameter to the subscribe method:

int subscribe(const char* topicFilter, enum QoS qos, messageHandler mh, void* context = NULL);

Oh, from your examples, it seems you're using the C version of this code.  The same principle applies.  I want to keep both these APIs in exact sync.  In fact I'd really like the C version to be generated by script from the C++.

Is there a particular reason you're not using the C++ version?


On 11/10/2014 05:49 AM, Xuejie "Rafael" Xiao wrote:

Thanks for your reply! Agreed that we should talk about this on paho mailing list in case others are also interested.

About the question: yes, I'm aware of the payload part, actually when I said "user-specific data", I was talking about the some context data used in the problem, not used by an end-user. To make this problem more complete, I will also shortly describe our use case here, in case we are using MQTT in a wrong way.

Instead of the normal pub/sub pattern, we are actually using MQTT in a slightly weirder way: in short, we implement a simple RCP on top of MQTT with the following setup:

1. We have a service (also treated as an MQTT client) that listens to certain topics of the broker(foo/+/bar for example).

2. We also have other clients that can send messages(requests) via foo/(client id)/bar channel, in the payload of the message, we include a randomly-generated message ID part.

3. When the service gets the message, it will perform certain actions, and send reply as a message through foo/(client id)/bar_response channel. The reply will also include the corresponding message ID.

4. The client gets the response from foo/(client id)/bar_response.

For this architecture to work, the client will need to subscribe to the response channel before sending the request. In addition, the client should also check if the message ID in the reply matches the message ID in the request part(to see if we have sent such a message). This means we have to maintain a list of currently-sent message IDs in the context data, which is exactly the context data I mentioned above, or "user-specific data" in my original email.

So this is the reason that I think we should add another (void*) as program-specific context data. And I think this should be included in the subscribe API function. In other words, we might want to change this API:

int MQTTSubscribe(Client* c, const char* topicFilter, enum QoS qos, messageHandler messageHandler);

to this one:

int MQTTSubscribe(Client* c, const char* topicFilter, enum QoS qos, messageHandler messageHandler, void* context);

Does this make sense to you? It might also be the case that we are using MQTT in the wrong way. Let me know what you think :)

Thanks a lot!

On Sat, Nov 8, 2014 at 7:03 PM, Ian Craggs <icraggs@xxxxxxxxxx> wrote:

I'm very happy that you are finding the library useful.  It's good to have these suggestions where everyone can view them, so I'm going to copy your question and my reply to the paho mailing list  It would be great if you could ask any follow up questions there.

I'm not sure why the type of the MessageData parameter passed into the messageHandler should force you to use global variables.  There are two parts to the data received by the library from MQTT 1) the MQTT specific parts, and 2) the user data.   The user data is part of the Message structure:

struct Message
   enum QoS qos;
   bool retained;
   bool dup;
   unsigned short id;
   void *payload;
   size_t payloadlen;

 and is called "payload".  It's type is a void *, so allowing you to cast it to any type you want.  There is no type associated with any payload in an MQTT message, so if you need one you could add that information to the MQTT topic, or to the MQTT payload, when you publish the message.


Ian Craggs

MQTT Open Source Projects
IBM United Kingdom
Hursley Park

Tel: +44 1962 818553

From: "Xuejie \"Rafael\" Xiao" <xxuejie@xxxxxxxxx>
To: Ian Craggs/UK/IBM@IBMGB
Date: 11/07/2014 02:00 PM
Subject: API Suggestion on the Embedded Paho MQTT Client

Hi there,

I was working on an MQTT-related product and found your Embedded Paho MQTT Client at here. First of all, allow me to say: thank you for creating such an awesome library! Really suitable for what I'm working now and saved a lot of development.

However, I do have one suggestion on the API, right now, the message handler used in subscribe request is only passed the message data:

typedef void (*messageHandler)(MessageData*);

My question is, is there any chance that we can change this API to allow for user-specific data, like a void*? Right now this forces us to use global variables to handle data, which may bring problems if we want to create multiple MQTT connections.

I know that this use case is very rare, I know that the API may be stable for a while, and you might not want to change it easily. However, I still wanna throw out my ideas in case you have exactly the same thing in mind. And I can always start crafting this if you feel like this is a good idea but don't have time for this.

Anyway, let me know what you think of this, and thanks again for bringing this awesome library!

Best Regards,

Xuejie "Rafael" Xiao

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Best Regards,

Xuejie "Rafael" Xiao

paho-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Ian Craggs                          
icraggs@xxxxxxxxxx                 IBM United Kingdom
Paho Project Lead; Committer on Mosquitto

Back to the top