(06-08-2017, 06:40 PM)z3bra Wrote: The main disadvantage is that you will have a lot of I/O upon concatenation, and that would be a single threaded process.
This would also use a shitons on inodes, but that's not the biggest issue.

Thanks, I did not think about this.

(06-08-2017, 06:40 PM)z3bra Wrote: Writing directly to the file [...] this is not atomic, and require a "cache file"

I mostly thought about concurrent seeding and leeching. I asked "is it possible to read and write a file at the same time" ? If not, one big torrent file open for writing one piece could not be used for reading another piece. But z3bra said on irc: "you can do that by mmap'ing the file".

So no real advantage to save the parts on different files, a big buffer file can provide everything needed.

The cache file will contain a list of completed pieces, this will bring atomicity back: a not fully written piece will not be in this cache file, and will be downloaded again if something went wrong.

(06-08-2017, 06:40 PM)z3bra Wrote: I think there is no urge to settle this now.

Let's begin with the beginning. I can get started with UTF-8, as discussed with z3bra:
http://bittorrent.org/beps/bep_0003.html tells us that:

Quote:All strings in a .torrent file that contains text must be UTF-8 encoded.

And the clients using the library may have broken locale, or simply use a different encoding. The wchar.h (C90) standard library can convert the currently running operating system encoding whatever it is to a encoding independent number (character position in Unicode).

(06-08-2017, 06:40 PM)z3bra Wrote: I chose to implement all the points in the RFC one by one, in the order they appear. It might not be the best way to handle this project, but at least I can easily know where I'm at, and what needs to be done.

We will need to notify each other our progress and self-assignments.