SNAP Routing¶

Reviewing the Basics¶

Consider a situation where there is a distribution of your devices across a large geographic area, such that some devices cannot communicate directly with other devices without SNAP’s automatic mesh networking assisting, by routing and delivering the messages through other devices. If the Alice device can consistently communicate with the Bob device, and the Bob device can consistently communicate with the Carol device, messages from the Alice device to the Carol device will be forwarded automatically by the Bob device if the Alice device and the Carol device cannot communicate directly.

However, the acknowledgement messages in this arrangement are incomplete, each confirming only part of the whole path. When the Alice device has a message for the Carol device, it begins by sending out a route request, essentially “Is device Carol in range, or does any nearby device know where I can find the Carol device?” Any non-Carol devices that hear the route request will forward the request: “Hey, out there! The Alice device is looking for the Carol device!”, and this will continue (within limits) until the Carol device is found. The Carol device will then reply to the device that it heard asking, which then replies to the device it heard asking, all the way back to Alice.

So, the Alice device asks for a route to the Carol device, the Bob device hears the request and asks for a route to the Carol device, device Carol responds to the Bob device, which now knows it can talk to Carol, and which then responds to the Alice device, indicating that it has a path to the Carol device.

Now the Alice device knows that if it has a message for the Carol device, it must ask the Bob device to forward the message to device Carol. When the Alice device sends a message for the Carol device, the Bob device hears the request and sends the Alice device an acknowledgement. The Bob device then forwards the message to the Carol device and waits for the Carol device to send an acknowledgement.

For either of these transmissions, if the receiving device does not send an acknowledgement packet within a configurable timeout period, the sending device resends the message up to a configurable number of times before realizing that it cannot get through.

All of this route seeking and acknowledgement protocol occurs automatically with SNAP. There is nothing the user must “turn on” in order to make it work (though much of the functionality can be fine-tuned through the use of NV parameters).

In the above configuration, imagine a situation where the Alice device has discovered a route through the Bob device to device Carol and sends the Carol device a message. The Bob device hears the message and sends the Alice device an acknowledgement, so the Alice device goes on about its business confident that its message is delivered. However, at the point that the Alice device hears the acknowledgement, the Carol device has not yet received the message from the Bob device. If the Carol device is sleeping or is otherwise unable to hear the message from the Bob device, the Bob device will attempt the configured number of retries but will eventually give up if the Carol device cannot be found – and this failure to forward the message will not be reported back to the Alice device (other than a route failure message that goes out, indicating to the Alice device that the next time it tries to communicate with the Carol device, it should first perform a new route request).

If you need to be sure that your target device has received a message, whether the message were sent by unicast or multicast, it is best to write your application to explicitly send a confirmation that the message has been received and to explicitly retry sending the message if no such confirmation comes.

Preserving Unicast Routes¶

When one device communicates directly to another, it must know how to reach the other device. If the devices are in direct radio range of each other, the route of communication between them is very simple. But if it is necessary for a message to hop one or more times between devices, the transmitting device must know how to direct the message in order for it to be properly delivered.

Consider a network of six devices, where device A is within radio range of devices B and C, device B is in range of devices A, C, and D, device C is in range of devices A, B, and E, device D is in range of devices B, E, and F, device E is in range of devices C, D, and F, and device F is in range of devices D and E.

In this network, if device A needs to send a message to device F, the message can be routed through devices B and D, through devices C and E, or even by path A-B-C-E-D-F. But when the network first comes online, device A has no way of knowing these routes.

When device A needs to send that message, the first thing it does is send a Route Request message, asking “Does anybody know where device F is?” Devices B and C hear the request, but they do not yet know how to reach device F (though they now know they can hear device A). So, devices B and C send Route Request messages asking for device F. Device D hears the request from device B, and device E hears the request from device C. Devices D and E do not yet know how to reach device F, so they send Route Request messages of their own.

Device F will hear the Route Request messages from devices E and D and respond with a “Here I am!” message. Devices D and E now have routes to device F. Additionally, device D knows device B and knows that device A can be reached through device B; device E knows device C and knows that device A can be reached through device C. Device D then replies to device B, saying “You can reach device F through me.” Device E sends device C the same message. Then, devices B and C both send device A messages saying “You can reach device F through me.”

Device A picks one of those routes to keep (based on timing and signal strength) and now knows that if it needs to send device F a message, it can send device B a message saying, “Pass this message on to device F.” Device B would send an acknowledgement to device A and then send device D a message saying, “Pass this message from device A on to device F.” Device D acknowledges device B’s message and then sends device F the message saying “Device A sent you this message.”

Typically, devices can maintain up to 10 such routes. But in networks where devices are not stationary, it may be problematic for a device to continue to attempt to use a route that is no longer stable or available. So by default, these routes time out.