You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently a node always has the full route table. This might not always be desirable, especially for nodes with limited memory. After #94, we can essentially run with only a minimal list of routes, based on a LRU policy. When a route is needed for a subnet which is not locally present, peers are queried with a route request, and the best route is used as it comes in. This will incur some startup latency, but avoid the memory usage of the route table. A startup parameter could be used to specify how long an idle route should be kept.
The text was updated successfully, but these errors were encountered:
One major issue is receiving data, since we don't have a route table we will likely not have the keys needed to decrypt either. We could employ a similar strategy and send a route request to neighbours when we receive a packet from a subnet we don't have the decryption key for.
Hmm .. I don't see that as a big feature, but the framwork to do so might come in handy when we want to split routing tables in bigger chunks through concentrators (a bit like IXes)
Currently a node always has the full route table. This might not always be desirable, especially for nodes with limited memory. After #94, we can essentially run with only a minimal list of routes, based on a LRU policy. When a route is needed for a subnet which is not locally present, peers are queried with a route request, and the best route is used as it comes in. This will incur some startup latency, but avoid the memory usage of the route table. A startup parameter could be used to specify how long an idle route should be kept.
The text was updated successfully, but these errors were encountered: