If to summarize this post up: "Whooray! The guilty bug that screwed the network-transfer speed found, fixed and helped to reveal some less major ones."
So, indeed it turned out that the mentioned bug lived in PacketSender and was in the wrong nextActionTime calculation. This value is used to determine the idle period of PacketSender after sending a packet before sending the next one. After tracing the PeerNode.getNextUrgentTime() and lining up all the logic of nextActionTime-estimation-related code it turned out that it did not correctly include the possibility of sending the fully-sized packet. In the if-branch that corresponded to the situation when messageQueue had at least one full packet, the corresponding nextActionTime adjustment relied solely on the urgent time of the next packet in the queue: "wait() until the deadline of the most prioritized message in the queue", whereas in that branch it should be "If there is enough bandwidth to send fully-assembled package - don't wait(), go directly to the next iteration". After finding the cause the bugfix was quite straightforward. While re-writing this part, found some other minor faults, added some explanation in comments and fixed them. All bulk file transfers got the speedup in 10-15 times depending of the quality of the connection. Now at last able to move onward. https://github.com/Quadrocube/fred-staging/compare/transport-layer-modifications- actual transport layer changes https://github.com/Quadrocube/fred-staging/compare/freenet:next...link-stats-tracking- testing tools, merge them together if you want to have a look at some samples _______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
