I have observed a strange behaviour of newest SXC client v0.6.4.6 and also older versions. I'm using blacklist to ban nodes which are not on v0.6.4.6 and by
looking at log-file there it becomes obvious SXC client just don't want to give up attempting to connect to some nodes. It makes no sense to keep on trying
when peers.dat file is almost 900 kB big, there must be a ton of IP addresses inside yet SXC client stubornly sticks to a dozen or so. In effect, my SXC node is
connected to less than 8 other nodes even after being online for few hours. Any other cryptocoin client (have 15 of them) connects to 8 other nodes in few
minutes, especially clients with 500 kB or bigger peers.dat file.
----snip-----
Also, Coin Control would be a nice addition to client.
like Nerull said, .9 will fix the coincontrol issue and the peers.dat reconnect issue should be improved.
The peers issue is actually alot more complicated due to using the same magic as litecoin. Our magic changed at block 680K. 6.4.6 (and back at least as far as 6.4.4) work with either magic basically.
Before the .9 release we are going to look into deprecating the old magic. We are 100% sure it can be done, we just haven't worked the exact process by which to deprecate it. The blockfiles contain the old magic written between blocks..... except if we redownload the blockchain.. it may be written with the new magic? I'm not sure and need to look into it.
.9 uses leveldb for block database and a new directory structure for blockfiles on disk, so it's a perfect chance to let .9 be "new magic" only and ensure blockfiles are written with only the new magic.
I think it's going to be pretty easy now that all clients on the network are using the new magic.... but we just need to step through the process and get the new client out. The key is that .9 will want to rewrite the blockfiles and blockdb, so we want to make sure we take advantage of that to deprecate the old magic entirely or at least as much as we can in .9 first release.
Of course coincontrol is in bitcoin .9.x so it will just "be there" for us.
I have noticed with the new magic enabled in the sexcoin-seeder app, that i had no need for filtering peers by port# (9560) to get rid of other coins... like I did when I first ported sexcoin-seeder (and it used the old magic). In that case the peers list included all ips that responded. They were tracked as "bad" and ultimately retried, eventually. I found that to truly ignore them I had to drop them from the peers db if their listening port didn't match 9560.
But, like i said, now that the magic changed I was able to update the magic in sexcoin-seeder and remove the code which filtered on listening port.
What we dont' fully understand is how long, or if ever, the non sxc peers will take to drop out of peers.dat. Clients which connect, exchange their known peers so the list sortof keeps propagating around containing non-sxc nodes.
In theory I think they will eventually be dropped out, but i am not familiar enough with the peers.dat logic in *coin.
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)
Another thing to point out about what we can do on the client end, is to update the version strings or values and reject older versions.. since 6.4.4 we've had at least 2 hardforks i think and no updates to the protocol version field or rejection logic. It may be that we introduce something there to help filter out these old nodes that are not on the current fork, but yet they have "new magic" code which allows them to look like they are current... sortof , until blockheight or blocks are exchanged.. which ithink may be or may sometimes be after peers are exchanged.
Overall, we want to incorporate all the above fix(es) and deprecation logic possible into the next release since at least every release I was involved in was a rush job that was needed ASAP with no time to really think about anything... even updating the dns seeding addresses or hardcoded nodes etc.
.9 and .6.4.7 (maybe we'll call it .6.5) are hopefully going to take advantage of all improvements and deprecate all old stuff that we can.
