When the clients exchange peers, the problem I found with sexcoin-seeder is that there was 50K or more litecoin or non-sexcoin nodes and less than 100 sexcoin nodes..... so as the local client chose a peer from db to retry every minute or two, odds are it would chose a non-sxc node.... which used the same magic, allowing an initial connection to succeed which caused the list of bad peers to be exchanged again, since one of the first things on connect was to exchange peers. (in fact like the only thing sexcoin-seeder did)
Why bother with retrying the same connection when there are thousands other IPs available? For example, most Torrent P2P clients try just once and drop IP after 15
seconds or so of no reply. They will not attempt connection to already "pinged" IP again unless IP pool is used up and at that point they'll start all over again, randomly.
Perfect scenario would be to intentionaly drop some percentage of connections at random intervals, it would help against
traffic analysis and strengthen the network.
Having all nodes "permanently" connected to other nodes makes it easy to monitor the traffic and create a list of transaction senders, all it takes is nodes at few key
locations within network. But if all user nodes drop some percentage of connections after every transaction sent or relayed then it is much harder to analyse traffic.
Or just give us a way to manualy "kill" connections, right now there is no such feature within SXC or other crypto wallets (
addnode IP remove is not working properly).
I don't fully understand the logic or algorithm for selecting nodes to connect to, so I can't say much for sure.
Except, the nodes do try other ips randomly, and keep track of recently tried ones. As I understand it, once they have not been seen in some minimum interval, they are in the pool of "can be chosen to reconnect to".
the biggest problem we have and had was that the pool contains tens of thousands of nodes that DO reply with valid messages and message responses. At least up to a point. That was the purpose of blockheight limits, proto version limits, etc that were coded in, to try and reject nodes that were replying, but were not sexcoin nodes.
I dont disagree with your logic, but what we have a is a situation where the peer logic as coded is straight from bitcoin, we did not create the process by which nodes are retried, archived, graded etc. and I'm not inclined to alter that logic that works for bitcoin considering we haven't finished migrating to a single sxc-only magic.
It seems that with the new dedicated sxc-only magic we have greatly improved the situation and now what remains may very well be due to sxc client specific issue(s)... namely that peers.dat is 99% full of non-sxc nodes and keeps getting propagated from node to node on every connect, plus current clients accepting both magics which means they can still connect to non-sxc nodes enough to exchange peers with them
I, or we, need to read through the magic handing code and almost for sure create a client that does NOT accept old magic and infact has no knowledge of old magic etc. This may require either a conversion process for any preexisinting blockfiles on the client or a redownoad of the blockchain.
Anyway, the goal is to elminate all your concerns, which are shared by the devs, but we just havne't gotten it done.