RTNode v1.0.40

Three major changes to the engine

Memory Leak Fix - How ever slowly, the device would eventually have to clear its tables or reboot once fragmentation shedded enough of the tiny ESP32 RAM. Now memory is reused as much as possible in order to stay running more stably for longer

All interfaces are now set to MODE_FULL - RTNode uses a Firewall filter to separate the WAN and LAN sides of the network. This is not just for the purpose of managing bandwidth. It is for managing the very limited ESP32 CPU and RAM. Gateway and Access Point modes were interfering with LAN side communication, so they have been switched to Full

Bounded Multi-path table - The canon Reticulum protocol has a comment suggesting the possibility of more complex handling of paths

# TODO: This might result in the path re-resolution
# only being able to happen once, since new path found
# after allowing update from higher hop-count path, after
# marking old path unresponsive, might be more than 1 hop away,
# thus deadlocking us into waiting for a new announce all-together.
# Is this problematic, or does it actually not matter?
# Best would be to have full support for alternative paths,
# and score them according to number of unsuccessful tries or
# similar.

I am personally a fan of this simplicity, so I have no interest in expanding it any more than I feel is beneficial. But here's the rules:

A max number of paths per destination is set (default: 3)
Unresponsive paths are removed
Paths are scored by Bitrate / Hops

The benefits of this are:

Poor quality paths don't automatically replace high quality paths
An unresponsive path doesn't always need to trigger an expensive path request on all interfaces
There's a built in fast failover mechanism (which I find particularly useful when responsiveness is expected)

It'll go into practice in RTNode, RFed, and Retichat and we'll see how it helps or doesn't help stability (I don't think it could hurt, but we'll see)

rns.recipes