You make it sound like the file formats have been changed without proper reasons. No, the hash database format wasn't changed because of this issue (I just wanted to report my findings here while making the rewrite). Dealing with a hash index XML file that could be several gigabytes in size and being regularly rewritten on disk (or being read into memory) just became too problematic. The same applied to having the whole download queue being stored into a single file vs. splitting the data into several XML files that allows only the changed ones to be rewritten on disk.
I've also written several posts about those changes:
As written in many introductions, AirDC++ is designed to work smoothly even if the user is sharing hundreds of terabytes of data or more than 10 million files. If you don't see any difference compared to DC++ and you rather prefer compatibility with old file formats, it may not be the right client for your use case.
You make it sound like the file formats have been changed without proper reasons. No, the hash database format wasn't changed because of this issue (I just wanted to report my findings here while making the rewrite). Dealing with a hash index XML file that could be several gigabytes in size and being regularly rewritten on disk (or being read into memory) just became too problematic. The same applied to having the whole download queue being stored into a single file vs. splitting the data into several XML files that allows only the changed ones to be rewritten on disk.
I've also written several posts about those changes:
https:/ /www.airdcpp. net/forum/ viewtopic. php?f=4& t=4007 /www.airdcpp. net/forum/ viewtopic. php?f=4& t=1856
https:/
As written in many introductions, AirDC++ is designed to work smoothly even if the user is sharing hundreds of terabytes of data or more than 10 million files. If you don't see any difference compared to DC++ and you rather prefer compatibility with old file formats, it may not be the right client for your use case.