I was having a conversation with sidhujag and while explaining the problem, I think I found a way to make SuperNET scalable to any number of nodes.
Some projections are having some rather large numbers of users in SuperNET and this created some possible scaling problems.
for instance if 100,000 nodes are all broadcasting just one packet, then this is making N*N packets, which is shared load among all the nodes, but still is is 100,000 packets per node (bidirectional), so even though the packet is small, at larger N, it is a very possible problem. I didnt expect such a strong response to SuperNET so fast, so I assumed that we can do some gateway hubs as SuperNET expanded to act as gateways for this peerinfo.
the following peerinfo structure is what is needed for SuperNET nodes to be able to find each other, without disclosing their IP address to any node other than their privacyServer (your can use loopback as privacyServer or get a VPS to shield your IP)
the "srv" fields are for the privacyServer which is the only thing that is disclosing its IP address. null values or loopback address means this node is publishing its IP (unless the srvipbits are 0)
the pubBTCD[] and pubBTC[] addresses and pubnxtbits are the linked addresses all derived from a single public address (the privkey is used for the other two coins relative to the orig pubADDR)
All nodes can access a particular node via any of the pubADDR. The pubkey is what is used for the encrypting data to each node
struct peerinfo // padded to 256 bytes with some room for future fields
{
uint64_t tbd[4],srvnxtbits,pubnxtbits,corecoins[4]; // this limits SuperNET to 256 coins in the core
uint32_t srvipbits;
uint16_t srvport;
uint8_t pubkey[256>>3];
char pubBTCD[36],pubBTC[36],extraspace[64];
};
the above is the info that is broadcast to all nodes and if gateways just broadcast to all the coins it was running a node on, we just, it would end up saturating all the nodes with these peerinfo packets
even though it is a small amount of data, I think that is too many packets!
So we must choke the traffic between coin networks to a linear flow.
For each coin there would be G gateways that store all the peerinfo data for that network. Well, this is automatic since all nodes for a coin are getting all peerinfo data
For a server that is in both coins A and B's networks, then it has the peerinfo for all the nodes for both coins A and B. So, if this server belonging to G(A + B) then a node in A can query G for a pubaddr and if it happened to be in B, the server can respond with the info.
To make it more efficient, each server G should list all the coins that it is belonging to so if it is known what coin a SuperNET pubaddr belongs to, only the server that already has this coin's pubaddrs would be queried. [at this point, I just added corecoins[4] so we can have a bitmap of up to 256 possible coins a node is belonging to as the solution flashed]
Now with little overhead all nodes in a coin's network can be identified as a possible gateway!
This just decentralized the peerinfo gateway function and eliminates the need for any hub servers.
This allows for peer to peer "long distance" calling.
Sometimes explaining a problem makes it go away
This is how I am reducing the problem as I learn more. I make sure there is a backstop solution (gateway hubs) and then at some point if it feels wrong, then I keep at it until a clearly better solution comes to mind. The advantage of working on so many different things is that I am getting a very general broad spectrum appreciation of the overall system, which allows to spend the time where the biggest possible issues are likely to be.
I am no waterfall process dev, so this drives the organized peoples a bit crazy, but in my mind SuperNET and all my assets are really just one project, so when people are saying I am doing too many things, it is strange as if I were to stop the one project I am doing, then I would just be a blabber blabber on the forums. The thing that seems to make it even more confusing is that I am making a combined code + monetization of traffic + user things like anon card and the asset interlocks are also part of the single project. So, it is hard to separate the code from the assets.
James
tl:dr SuperNET doesnt need any special server hubs to gateway peerinfo, each node that is running more than one coin will answer queries to other coins in its network with info it has from other coins it is also running a node. SuperNET just got decentralized peerinfo gateways!
