Navtech Anon Beta
We’ve had a busy week at Nav Coin HQ with the first round of Beta Testing of the Navtech Anon system completed successfully. We’ve made some minor improvements to the code and have re-deployed the updates to the servers. The second round of tests have begun and the test group has been widened to all 22 members of the slack channel #navtech-anon-beta. If you are interested in helping with the test, please join us on slack and get a sneak preview of the system in action!
Now we have more users, we can start to stress test the system and I will also start to add more servers into the cluster this week. I am very pleased with the testing so far. Any adjustments we’ve made have been very minor so it is looks like everything is progressing as expected.
So what was tested ? What was succesful and what wasn't ? Not being critical. Just from interest as NAV investor.
Sure, so the issues we've encountered so far are pretty minor but i will explain.
1) Coins were returned from the incoming server to the sender. This is one of the graceful fail overs the system has in place, so it actually worked as intended. The reason why the coins was rejected was when the system went to process the transactions and send to the outgoing server, it found the outgoing server was not up to date with the latest block as visible on the network. It was only 1 block behind, but this caused the incoming server to think the outgoing server was not ready to process transactions. I have loosened this check. So it will consider an incoming or outgoing server ready to transact if it is within 5 blocks of the current block. In practice, I've only ever seen them 1 - 2 blocks out but 5 seems like a good buffer. It still has to be up to date with the latest block to process the transactions, but this should reduce the incidence of unnecessarily returned coins when there is a small block count difference.
2) The coins started being always returned to sender, the server needed to be restarted to fix this. This one was a little tricky, the reason why it was failing was because when the incoming server tried to process the transactions, it's query to the outgoing server was being rejected because the outgoing server couldn't find the incoming server's IP address in its whitelist. This error happened over time and the reason for it is an interesting nuance of programming. Basically, as the outgoing server requests to be refilled by the incoming server, it will cross servers off the list if it doesn't receive the correct response and ask to be refilled from another server. This crossing off of servers is done by looping through the whitelist and sending out requests, when a server has failed to respond it is removed from the list. The nuance of JavaScript is that even though i had created a new variable which i was looping through and deleting items from, it is actually just what is known as a pointer, so it was actually crossing items out of the main whitelist entry as well. So the next time it went to use the whitelist, there were no items on it and all requests were being rejected. I have solved this by making sure we clone the whitelist object out of the settings rather than just point to it, this means each time we fetch the whitelist, it is a new instance of the original list from the settings and when we delete items they don't get deleted from the main entry.
Everything else has worked great. All coins have either been returned to sender or made it through the system perfectly which is the intention. So I am glad that the two minor technical issues we had, resulted in no loss of coins by the sender.
There are 24 people in the test group now and I am awaiting more feedback from them over the next couple of days.
Cheers,
Craig.