Dear sir,

Thank you for the reply. Here's an idea that I think is worth mulling over at lunch.

What if we were to take an already extremely successful open source fractionary data transport technology, with an existing off-the-shelf code base, like bit-torrent, speed it up a bit so that it supports "live" data communications i.e., voip/udp etc., and connect it to a mesh networking system like project-byzantium? I think bit-torrent could definitely handle the work load. It's massively parrallel. In electronics as in hydraulics, the more parrallel paths you have, the more current you can source. I'm certain it could handle the backbone. Bittorrent already has a massive installed user base; it could simply be repurposed a little, or a lot... I wouldn't be at all surprised if an alpha release of "VoiceTorrent," isn't that far off.

It could be Sherman's "March-To-The-Sea" for communications privacy. Besides, it seems like it has the potential to be really really efficient. What green blooded capitalist doesn't like efficiency.

Hello,

I've been doing a thought experiment about something I'd like to call "VoiceTorrent" for now.

Here's the basic idea:

What if we were to take an already extremely successful open source fractionary data transport technology, with an existing off-the-shelf code base, like bit-torrent, speed it up a bit so that it supports "live" data communications i.e., voip/udp etc., and connect it to a mesh networking system like project-byzantium?

http://project-byzantium.org/

I think bit-torrent could definitely handle the work load. It's massively parrallel. In electronics as in hydraulics, the more parrallel paths you have, the more current you can source. I'm certain it could handle the backbone. Bittorrent already has a massive installed user base; it could simply be repurposed a little, or a lot... I wouldn't be at all surprised if an alpha release of "VoiceTorrent," isn't that far off.

It could be Sherman's "March-To-The-Sea" for communications privacy. Besides, it seems like it has the potential to be really really efficient. What green blooded capitalist doesn't like efficiency.

Currently the client stores its configuration across several files in its configuration directory by first copying the old file to *.bak and then writing the new one. This is bad because, this involves I/O on both the backup and the new file, and with the operating system or disk write cache being used, if the system crashes, both files will be corrupted by this.
It would be great if the client could:
1. Rename the configuration file, before writing the new one.
2. Flush the disk cache after or use direct I/O (i.e. writing without write caching) for every write operation on critical configuration files.
3. Keep more than just one backup (possibly a configurable amount) *.bak file
4. Check that the configuration file has been reliably written to disk
5. Enable the recovery of torrent activity configuration in <ConfigDir>\active from the original torrent file in <ConfigDir>\torrents
6. Use a more corruption resilient storage format, like redundant SQL tables in a rapid resilient configuration instead of the BEncode format files currently in use.

PS: This request is not related to the backup feature (only allows daily backups which are insufficient, and backs up everything). I am looking for better corruption and crash resilience for the files that are currently being actively used and changing by the minute or not even present in the previous days backup.
PPS: The backup feature appears broken in the latest trunk version, backups where a single file failed to copy (because it's in use and locked by the OS) aren't kept around, leaving you with no backup at all. My latest backup (runs daily) is 10 days old and I now have to fix over 150 broken torrents by hand. A working backup would at best have helped reduce that amount by half, however.