As it looks like mesh publish/subscribe send UDP datagrams to accomplish its task.
This function will return true once the device is connected to the network and has been assigned an IP address, which means that it’s ready to open TCP sockets and send UDP datagrams. Otherwise it will return false.
But as UDP doesn’t guarantee messages are always delivered.
_Note that UDP does not guarantee that messages are always delivered, or that they are delivered in the order supplied. In cases where your application requires a reliable connection, TCPClient is a simpler alternative.
Doest that mean mesh publish/subscribe will also not guarantee messages are always delivered ?
Mesh.publish() will eventually go the same way as
Particle.publish() (if it’s not already doing it) you will be able to choose between unacknowledged and acknowledged publishes.
If you need a delivery but can accept multiples you’d use
As long that’s not implemented, you can conjure up your own acknowledge scheme with bi-directional pub/sub.
At this time, Mesh.publish is not reliable. It uses UDP multicast, and thus Mesh.publishes could be lost.
What are the future intentions re. this Rick ? Obviously Particle.publish() with ACK being a single endpoint is quite different. Will there be a targeted mesh publish ? Should I implement my own ‘ACKs’ to Mesh.publish() messages ?
The UDP multicast is repeated across the Mesh I assume ?
New to this but can I specifically ‘identify’ and connect to another mesh device using TCP and can that device easily identify from which device the message came ? Like static IP’s, name, MAC or something.
But as I understand it Partial Mesh is build on Thread , from the thread groups own web page at https://www.threadgroup.org/BUILT-FOR-IOT/Home
- Thread networks allow both multicast (flooding) and unicast (routed) messaging which provide for network scalability and a reliability network.
So the lower level functionality for this should be in place ?