Bug-Fix for the forking problem #29
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This Branch is used to test the Performance of the BAZO-Network. Therefore, certain additions are made: - Logger creates a logfile 'PerformanceLogger.log' and prints all statements to the console and the log file. - Logger includes microseconds - Logger prints the Mempool size - Logger does not print "Sent Message... " and "Received Message..." statemens. - Logger prints the total transaction number in each block.
…azo-miner into performance_test_branch
…azo-miner into performance_test_branch
…the blockchain class
…f random selection of a Block REQ
-BLOCK_REQ & TX_REQ as Broadcast and not as a random selection of one miner. With this we can probably prevent timeouts when randomly choosing a wrong miner. - after rollback write block back to received stash. so it will be deleted after 50 blocks but possible to grap for an other rollback. - logical reorganisation
This should fix the issue of a forking BAZO-Blockchain. Implemented a stash for all received blocks. After a rollback now the miner first checks those blocks before requesting one from the network. the Block request to the network is now done with a broadcast request, such that the possibility of a valid answer is maximised. When a fork occurs, the state of the fork-brnaches can quickly diverge. This results in transactions listed as invalid, despite they are valid after a rollback to the correct chain. Now we do not discard them automatically but write them in a special stash, from where they can be fetched after the rollback. This results in less network requests and a higher possibility to get a valid answer. Also here the Tx request is now a broadcast. This also ensures for the case when a transaction is not received before. With only one random selected miner the miner may has bad luck and does not get the transaction. Then the block is invalid and this should be prevented.
mchetelat
approved these changes
Feb 2, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hello All
This PR fixes issue #27 and does also write the output to a file as questioned in #23.
The exact problem is described in the added PDF-Document.
What I've done:
logger.Printf(...)statements are now printed to a .log file and saved in the project directory directly. This file will be created if not existent at the beginning.MIN_MINERSnumber to 5. Now the miners actively searches other miners until 5 are in the list. --> Better connected.panic: send on closed channel. This because in thebroacastService()function, the range gets updated only before each iteration. Meaning when we are inside one iteration and there is a removal & closure from thepeers.minerConnsorpeers.clientConns, the function may try to send on a closed channel. Therefore I inserted an IF-check, to check if the miner/client is still in the list.I know that this broadcast requests do rise the network traffic. But it is the most secure way to get a valid response for a request.
Forking Problem.pdf