Return Code on Mesh.Publish

boron
xenon
argon
Tags: #<Tag:0x00007fe21e920c68> #<Tag:0x00007fe21e9208f8> #<Tag:0x00007fe21e920628>

#1

Is there anything specific in the system error codes and is this return code reliable?

Mesh.publish(const char *name, const char *data);


**Returns:**  An  `int`  indicating the result. (0 = success, non-zero = system error code)

#2

What does “reliable” mean in this regard?

Just like with Particle.publish() this function only hands the data to the system for it to treat it asynchronously from there. So the return value would only be able to report whether the system accepted the event for further process or - if not - what may have prevented that.
But anything after that won’t be finding its way back into the return value.


#3

What ScruffR said. Also, Mesh.publish is based on UDP multicast. The publish is sent off onto the private mesh IPv6 network. There’s no confirmation that anyone receives is. You’d need to layer a higher-level acknowledgement, like another Mesh.publish back, to guarantee delivery.


#4

For ‘Reliable’ read ‘Meaningful’. I understood that a while ago (in Device OS terms) the return value was neither reliable (not working) nor meaningful. When I do Mesh.subscribe() I test the return for SYSTEM_ERROR_NO_MEMORY but for Mesh.publish() to date I haven’t used the return value. It sounds from your answer that given the nature of the return value if I receive other than SYSTEM_ERROR_NONE (0) I can wait a short random time and try again? [Just seen your reply Rick] I guess what I was hoping to see would be did the Mesh.publish() succeed and if not should it be re-tried. The aim here being to have a bit more certainty about messages not being ‘lost’. Understand about the nature of UDP and need to build a reply process (ACK). How necessary is such a mechanism? Do a lot of messages never reach the subscriber and under what circumstances e.g. devices close together, many devices on the same Mesh, etc. You are typically well ahead of everyone on these matters, is this something you have considered?


#5

For ‘Reliable’ read ‘Meaningful’.

Here’s a discussion on the values it can return, Mesh.publish() successful but returns false even though gateway receives message.

I personally would love an API which includes an ACK for a specific receiver. This way a mesh could have sleepy elements which only wake up long enough to ensure their messages is delivered to the gateway, without considering if the gateway is currently able to publish the message online.

It’s trivial to build an ACK of this form, but since there is already a mechanism to ensure that a gateway gets (and forwards to the cloud) the mesh’s Particle.publish() command, it would be nice if this API could be exposed to Mesh.publish() as well.