Threading best practices

[back-40]

Hello!
I’m using RNS, LXST, and LXMF and I want to understand best practices for threading and back-to-back function calls. I've been in the source code heavily for the last several weeks as I'm progressing thru RNS integration, but definitely still have gaps in my understanding.

I'm developing a Kotlin Android application and using Chaquopy for interfacing with RNS's python. There were some challenges going that direction but overall working very well.

Please advise on:

- Threading:

1. Should the same thread of an outside application be used for making API calls to RNS/LXST/LXMF functions, such as announcing, sending LXMF msgs, audio transfers, etc. Will bad things happen if multiple threads attempt to send msgs at the same time, for example?
2. Do RNS callback threads need to be exited ‘quickly’, ie grab the callback data and move to another thread asap to prevent hindering other RNS operations due to waiting for that callback to return?

- Back-to-back function calls:

• My application frequently makes back to back calls for sending LXMF msgs to multiple destinations without waiting for confirmation of failure or success. Is this a problem?

One of the reasons for asking above is I’m having random issues of what appears to be msgs not getting sent out from the LXMF router and want to make sure I’m playing nicely.

Dev setup:

• 3 Android devices running RNS and all 3 with enable_transport = True
• All 3 can see each others announces, which is verified in the logcats.
• Device A can send msgs to Device B but not to Device C (part of the time). This does not occur all the time, typically when a new fresh install occurs. And the issue is resolved when Device C sends a msg to Device A.

Here is the log of Device A sending to Device C and B, respectively:
// This msg doesn't appear to have been sent to C:
sending msg type: lxmf.delivery to: <lxmf.delivery.f574cf1cdae1ca32f1355296636a4220:7f254eee1e9b47b8f9e291d7fe3317f4>
[2025-12-11 15:20:40] [Debug] No stamp cost set on LXM to <7f254eee1e9b47b8f9e291d7fe3317f4>, autoconfigured to 8, as required by latest announce
[2025-12-11 15:20:40] [Debug] Found generated ticket for <7f254eee1e9b47b8f9e291d7fe3317f4> with 20d, 23h, 52m and 22.32s of validity left, re-using this one

// This msg delivered to B:
sending msg type: lxmf.delivery to: <lxmf.delivery.1db754732739381f471dcc797bad5d94:9bb86a3e38b07e11c8d0da311400f7eb>
[2025-12-11 15:20:44] [Debug] No stamp cost set on LXM to <9bb86a3e38b07e11c8d0da311400f7eb>, autoconfigured to 8, as required by latest announce
[2025-12-11 15:20:44] [Debug] Deferred stamp generation was requested for , but outbound ticket was applied, processing immediately
[2025-12-11 15:20:44] [Debug] A ticket for <9bb86a3e38b07e11c8d0da311400f7eb> was already delivered 7m and 33.96s ago, not including another ticket yet
[2025-12-11 15:20:44] [Debug] Generated stamp with outbound ticket d1:c8:6c:4e:58:68:38:a1:95:e2:78:9e:85:82:62:a5 for <LXMessage 0ad7517751a5cf4d40dea1f06a11830ac0b1d49dd9c18a46eb8aec0039a28483>
[2025-12-11 15:20:44] [Debug] Outbound processing for <LXMessage 0ad7517751a5cf4d40dea1f06a11830ac0b1d49dd9c18a46eb8aec0039a28483> to <9bb86a3e38b07e11c8d0da311400f7eb>
[2025-12-11 15:20:44] [Debug] Using available direct link <96bb105651c2ab54d3c5bc285eb9f697> to <9bb86a3e38b07e11c8d0da311400f7eb>
[2025-12-11 15:20:44] [Debug] Starting transfer of <LXMessage 0ad7517751a5cf4d40dea1f06a11830ac0b1d49dd9c18a46eb8aec0039a28483> to <9bb86a3e38b07e11c8d0da311400f7eb> on link <96bb105651c2ab54d3c5bc285eb9f697>
[2025-12-11 15:20:44] [Extra] Compressing resource data...
[2025-12-11 15:20:44] [Extra] Compression completed in 0.002 seconds
[2025-12-11 15:20:44] [Extra] Compression did not decrease size, sending uncompressed
[2025-12-11 15:20:44] [Extra] Starting resource hashmap computation with 1 entries...
[2025-12-11 15:20:44] [Extra] Hashmap computation concluded in 0.001 seconds
[2025-12-11 15:20:44] [Extra] Sent resource advertisement for <9d66fa0b77c7fefc050eb51af8b55b5cc51ccf3e095a775f22e602c4c0f0b050>
[2025-12-11 15:20:44] [Debug] Received delivery notification for <LXMessage 0ad7517751a5cf4d40dea1f06a11830ac0b1d49dd9c18a46eb8aec0039a28483>
[2025-12-11 15:20:44] [Verbose] Msg delivered.

The log indicates "Found generated ticket for" but I don't know what causes this to happen and have looked thru the source code but not understanding why.

Thanks!

[back-40]

Sorry to bump this up, but if someone has input on the topic it will be much appreciated.
Thanks!

[skyguy]

I don't have definitive answers for you, but I can tell you the approach I'm taking in writing applications for Reticulum: + Assume Reticulum isn't re-entrant and avoid calling the same function from multiple threads simultaneously. Same for message submission - try and submit one at a time. + Give LXMF time to process and send messages - don't exit the application immediately after submission. + Exit callbacks as quickly as possible - these definitely do delay packet processing. Skyguy

…

--- https://codeberg.org/skyguy

[back-40]

@skyguy Thanks for the above.
By 'one at a time', are you waiting for the callback in self.router.register_delivery_callback(self.lmxf_delivery_callback) before sending the next?

[skyguy]

So far I've just queued the calls to handle_outbound() but my messaging app isn't very far advanced yet!

[back-40]

@markqvist can you help me understand why the log below occurs which causes the msg not to be sent? More of the logs are above in the first post.

"Found generated ticket for <7f254eee1e9b47b8f9e291d7fe3317f4> with 20d, 23h, 52m and 22.32s of validity left, re-using this one"

[markqvist]

Should the same thread of an outside application be used for making API calls to RNS/LXST/LXMF functions, such as announcing, sending LXMF msgs, audio transfers, etc. Will bad things happen if multiple threads attempt to send msgs at the same time, for example?

No, RNS is designed to be fully multi-threaded. You can call any RNS, LXMF and LXST API function from any thread you wish.

Not directly RNS related, but: Take note though, that some frontend frameworks require UI-updating API calls to happen on the main thread. RNS-triggered callbacks can also occur from any thread launched by RNS internally, and if your frontend framework requires a specific thread to call updates, you will need to handle this internally in your application, with a message queue or similar.

Do RNS callback threads need to be exited ‘quickly’, ie grab the callback data and move to another thread asap to prevent hindering other RNS operations due to waiting for that callback to return?

In general, no. A while back I refactored most of the callback code to ensure that triggering callbacks that could potentially block RNS-internal logic flow would themself happen in a newly spawned thread. It is possible I missed something, though, so if you found something where a callback blocks packet processing, please let me know.

My application frequently makes back to back calls for sending LXMF msgs to multiple destinations without waiting for confirmation of failure or success. Is this a problem?

No, not at all. If you use the provided message dispatch functions of the LXMF Router instance you've created, it will handle all queuing and scheduling automatically, and you will get callbacks on success or failure.

typically when a new fresh install occurs.

This is the root cause of the problems. It looks like you are using the stamp system. This is what happens:

• When a destination is configured to require stamps, it will include the required stamp cost in its announces.
• Any peer trying to message it will adhere to this, and dynamically generate a stamp when an outbound message for that peer is queued.
• Unless the stamp-requiring peer has marked that sending peer as trusted, in which case it will automatically ensure that it periodically sends a valid cryptographic ticket to the trusted peer.
• The trusted peer can now use this ticket to instantly generate a valid stamp, without having to expend CPU resources on this.
• When you wipe the sending peers config (fresh install), you're most likely deleting or restoring an invalid version of it's cache of ticket data.
• This will result in an non-synchronized state, where the peer cannot correctly generate stamps for the destination.
• You will see the message as being "delivered", but the receiving peer will reject and silently drop it (unless you have log level turned up high enough to see this event).
• This could occur in either direction of the peer data wipe / fresh install.
• As you've noted, this will generally self-heal as soon as an announce and message has been exchanged in the direction where the sync-state was broken.

Hope that clears it up! Otherwise, let me know.

[back-40]

Awesome, thanks!

That is great to hear there are no API thread considerations needed on application side to prevent RNS-side issues.

Yes, thanks for the UI-thread reminder when dealing with processes kicked off from an RNS callback. Most, if not all, of the callbacks hit a dedicated Kotlin coroutine scope that directs data to Room db which is thread-safe. But will double check my code.

Also great on the built-in queuing of LXMF. Very glad no queuing-response mechanism is needed application side. I’ve found LXMF to be powerful in ‘just-handling’ the messages. Recently, I had need of another destination outside of lxmf.delivery and quickly found out that more is involved than just using the LXMF router. And that using more than one destination with the router doesn’t work, because lxmf.delivery is baked into the API.

And while on that topic… if the API allowed for passing in a destination name string, (other than lxmf.delivery which could be the default), it would allow the application to have multiple instances of the router for different destination names. I’m not sure if LXMF router was meant for multiple instances, but a thought.

Stamps: yes, that makes sense. I need to dig more into the stamp-mechanism to understand if I really need to enable it. Soon, I will need to setup a propagation node, which some of your other info discusses the use of stamps with it. I’ll do more reading but in the meantime ensure caches are cleaned up during the development cycles of install/delete, etc.

Much appreciated!