RNS reliable delivery

[acehoss]

From what I can tell from the source code, I think only the resource transfer would be considered reliable delivery--it has a retry mechanism. Request/response has receipt acknowledgement but does not have retries. RNS.Packet().send() is best effort delivery like IP. If my application needs reliable delivery, I believe I would need to build a retry mechanism on top of whichever RNS interface I use.

Is this correct?

[markqvist]

You are more or less correct in your observations. The low-level Packet API is best effort, but you do have the ability to get a per-packet delivery (or failure) notification with the PacketReceipt API. The intention is that it is up to your application how to react in terms of undelivered packets. You can implement retries, or in some cases you might want to just "send and forget", for simple telemetry and status, for example.

Now, the higher-level Request API is meant to be reliable, as in having automatic retries on failure. This makes sense to have here, since it is a much higher-level function, closer to the application code, and should at least make a pretty good effort to complete the request, even in unreliable conditions.

This behaviour is partially implemented currently. In some cases, the reliability and retry mechanism is automatically inherited from the Resource class, but in some other cases, I still need to add the logic in the Request code itself.

So the gist of it is:

• Low-level APIs like Packet gives you full control of how and when to do retries/reliability
• The high-level Request API handles reliability/retries automatically, but it is not completely implemented yet. It should be before 0.5.0, though.
• You should not need to implement any reliability logic / packet retries directly in any interface code. Reticulum should be able to handle running directly over unreliable mediums.

[acehoss]

Okay, that makes sense. Developers can program with the Request API now and it will gain automatic retries in the future. And it will be reliable today where TCP is the underlying medium.

Thanks!

[markqvist]

Exactly right!