I have been wondering why the nodes connect to hundreds of other nodes. In my opinion, a lot less would be better. I can be wrong, so please correct me. There might be some good reason for the current amount.
But anyway, here is an example:
Setup 1; nodes connect to 100 other nodes. They reach 1 million nodes in 2 hops.
Setup 2; nodes connect to 10 other nodes. They reach 1 million nodes in 5 hops.
So setup 2 needs 2.5 times more hops to reach the same amount of other nodes. But it need only 10% of the connections.
A pc can usually handle a few thousands of tcp connections concurrently by default. You can easily tweak it to handle a few tens of thousands. But the amount of connections causes heavy load also on the other parts of the sydtem, specially on network infrastructure.
Have anybody tried to optimize the amount of connections a node tried to accomplish? I would bet a few tens would be a lot more efficient than current a few hundreds.
The lower the number the higher the risk of islands of nodes that are only connecting to themselves. 10 would see this happen in too many places. 100 should not but maybe a few times and 200 it is going to be very rare.
Its not just the hops but connectivity when some nodes drop off as well.
UDP
Have you simulated or is it only assumption?
How about some algorithm to avoid islands, ie drop connections that have duplicated 2nd level peers etc.
Edit: Or simply rotate the connections so there will be 200 different connections within a certain time window?
Yes and no. There are similar things and different things. I am unsure how Bitcoin does its stuff so not able to comment on the difference.
One difference is that the network is built to have unlimited number of nodes and thus connections are designed for that. Also the purpose of the connections are different which also adds to the difference in connection.
For fear of being mistaken. Autonomi is to be distributed to a very high degree and connections are an important part of that. For speed, for security of connectivity. For instance if 5 hops and in a worse case scenario the nodes in the hops are the maximum distance away. Thus approx 400mS ping time means it is 2 seconds with 5 hops and for speed sake this is extremely slow. Downloads of a chunk would require 2 seconds (5 hops) just to contact the node with the chunk, hmmm not fast. With more connections the faster this on average will be.
For uploads where the client gets 5 quotes for each chunk then this delay is very important to consider. As opposed to Bitcoin, Autonomi is a data network where chunks are small and highly distributed, and living on only a small number of nodes (at least 5). The number of connections affect churning where chunks are being redistributed. The long the delay the more the cascading effect that happens and while it a reducing cascade the speed of reduction is dependant on the number of connections and hop time.
Bitcoin network doesn’t need to hurry, it tries to be synced every 10 minutes on average, Autonomi runs async tries to make the network propagation time make as low as possible.
Let’s try to estimate the island problem:
-we have an imaginary network where nodes makes 5 outbound connections and since have 5 incoming on average
network size before:1000 nodes
10 nodes to be added.
there will be 50 new outbound connections
what is the likelihood that all those 50 new connections are made to the same 10 node group (island)?
For every new connection the likelihood is 10/1000, ie 1%. For this unfortunate even to repeat 50 times, the likelihood is 0.00000…(totally 50 zeros)…1% That means it is not going to happen in this universe.
Besides, the first connection is 100% not to an island.
The key is fix what’s an issue, QUIC is designed to handle many thousands of connections concurrently and the more the more stable things are. It’s always a trade off with cpu etc. but it’s not an issue for us that we are seeing right now. I think we are OK here. It would be. a bug if nodes kept connections without dropping them etc. but we would see that.
I am not saying such bugs could not appear, they could, but not right now.
So my node joins the network to 5 nodes (inbound and outbound connection is to same node) then nodes leave. Depending on the rate of leaving and location in network it is possible to end up with the 6 nodes talking to each other.
IE Node A connects to nodes 1, 2, 3, 4, 5. Then a node that 5 connects to leaves, node 5 restores its 5th connection and chooses one of the 6 nodes (A,1,2,3,4) in this future island. So if a certain number of the connections are already between each other then there is a finite number of nodes leaving that in some cases will cause all the 6 nodes to only be connected to each other.
The rate of these islands forming will depend on the algorithms used to select a new connection to make up the 5 connections.
10 connects will be a lesser rate.
100 even less and rare if decent algorithms are used.
But the island effect is only one aspect. The other is trying to maintain as distributed a network as possible. There has been a lot of work done to determine the best sizing. I have not gone into depth and do not know if 100 is best or 200 or 300, but I do realise that even 50 is getting too low and dangerous.
Also remember that it is not expected people are running hundreds of nodes on the one box. A decentralised and distributed network is not being designed to centralise nodes within devices.
At first it was 1 node behind one router, then that was changed with new designs to allow multiple, but to have hundreds or thousands at one location is not best for decentralised and distributed networks. SO the design choice will always be for faster connectivity and more secure connectivity
The problem is with home routers (ISP provided). They can handle only a relatively small number of concurrent sessions before they start causing problems with “normal” home internet usage and many concurrent connections can also trigger ISP warning notices. Best to minimize number of connections if possible - no? Would be a shame if the main impediment to Autonomi adoption ended up being ISP paranoia.
I have 150 well behaved nodes until end of rewards today
They still seem to be healthy except they each only see 500-1500 nodes according to the /metrics figures. And the number of Routing Table peers is ranging from 75 to 200 nodes each.
Is this the Island effect happening where the network has a number of loosely connected groups of nodes? Interesting effect.
I went to start a new node, but it won’t start because the contacts file cannot retrieved and if I use an old copy, it seems the actual contact nodes are not working right (maybe upgraded to a new version already as the error is saying versions do not match).
FYI, Today I got my second Abuse Notice from my ISP regarding a possible violation of their Terms of Service on one of my PC’s running nodes exclusively. This is on a business internet account. The ports cited in the email were custom safenode ports I assigned to Launchpad.
Probably something that should receive some attention as it’s possible local ISP’s could unwittingly become a deterrent to the success of the network.
“ Any future violation will result in further action being taken, up to, and including, the termination of your service.”
This is the detailed complaint, followed by the IP’s and ports in question.
On December 4, 2024 , your account was reported to have been used in an attempt to gain unauthorized access to another system, or to transmit malicious traffic to another Internet user.
It is possible that a device connected to your network may have been infected by a virus or a botnet that is causing this action.
I had Netcup, a german provider, send me a similar message and shut me down. They turned the service back on. I was down for a week.
Recently I had Contabo throttle my bandwidth without explanation. I’m pretty sure it is the same issue where they think this is a bot net or something like that.
