Transport Nodes, storage of Public Key from Announce in large networks

[nathmo]

Hi,

I was wondering how the network will scale.

My understanding (from https://reticulum.network/manual/Reticulum%20Manual.pdf) is that any transport node contain a table of every node in the network.

Each entry to that table contains :
• The announcers' destination hash
• The announcers public key
• Application specific data, in this case the user's nickname and availability status

I can't find a definitive number, but I assume that should be around 167 byte (size examples of different packet types P.45)

That mean (If I understand it correctly) that each transport node will contain 167 byte x theNumberOfDeviceConnectedToTheNetwork
if we give 1 device to each person on earth (~8 Billion), each transport node would require 1'336 GB of storage ???

(current BGP table is less than 512 MB https://learningnetwork.cisco.com/s/question/0D53i00000Kt0wLCAR/router-memory-for-bgp, and more than 6 billion IP)

Even tho it seems like a usually large number for a network routing table, I don't see a big hardware problem there, as a decent HDD with that much capacity is rather cheap.

What I'm wondering about is what the latency when searching for a route is going to look like ?

Like, how long would it take for each transport node (max 128 hops, average of 12 on current internet) to each find the next hop to make the link?

If locally the database return a result in 1 ms that would take on average ~12 ms + network latency to create a route (and 1-2 second on the worst case scenario)

Once the link is established, it would be faster as there are way less active link than device in the network on average, so the table is much shorter. (I hope ?)

Is my deduction correct ?

[markqvist]

While the numbers do seem a bit wild at first glance, when talking about multi-billion endpoint networks, it's actually pretty tame in reality, and something even pretty mediocre hardware can handle quite easily.

Searching a hashmap is extremely fast, even for incredibly large datasets, so even in the case of path-tables that grow to several terabytes, it really shouldn't be a problem on modern hardware.

But... Not all devices net to keep a complete list of all destinations, though. In fact, nobody needs to keep a complete list, since missing announce data can always just be requested from the network. That means, that in very large networks, it will be completely suitable to just keep some percentage of the known paths in persistent memory (flash, HDD, whatever). Further segmenting this into RAM and persistent storage will work even better.

For example, the most recently used 1,000,000 paths could easily be kept in RAM, and only require around 250 megabytes of memory. Several billion other paths, that are less commonly used can be kept in a hashmap-indexed database on just relatively fast storage, and be swapped into working memory when required. Even in the case of having to search through the local database, latency for getting that paths data into RAM would be in the millisecond realm.

These kind of improvements are planned, but not currently implemented in RNS. But is definitely something that will need to be done in the future.

[nathmo]

thanks for the answer :)