orzen / ertorrent Goto Github PK

Generic server for torrent process.

Following is a list of initial tasks for this issue:
-Receives metadata, regarding a certain torrent (this includes magnets).
-Support states (open/closed)
-Communicate with the tracker during .
-Provide peer lists to the peer_sup
-Provide information regarding the torrent it has been assigned.

Implement a way to measure the packet size over time in order to get the current transfer rate for the peer communication.

We should not assume that we can use local filesystem as storage. The way we save data should be pluggable. We can imagine a default implementation using local filesystem, but we can also imagine things like Amazon S3 or in-memory storage for high performance applications.

The first implementation of the file handler will use file:pwrite/3 when writing bytes to file. These writes could be improved by bundled and then written by using file:pwrite/2.

Support: DHT protocol

http://bittorrent.org/beps/bep_0005.html

See link for more information:
http://bittorrent.org/beps/bep_0015.html
http://bittorrent.org/beps/bep_0041.html (extensions)

Support: Peer wire protocol (uTP)

See link for more information:
http://bittorrent.org/beps/bep_0029.html

Set up an environment where testing becomes a necessary step in integrating changes. Like Travis or similar. This to make sure that we never introduce bad changes (as defined by our test coverage :-)).

An OTP application contains a supervision tree design.

A supervision tree design contains a supervisor process that keeps track of a server process and another supervisor process, this supervisor is referred to, as the super supervisor (visualized below). The second supervisor will keep track of workers. The supervisor will spawn and terminate workers based on internal API calls to the server process.

o super supervisor
|- server
|- supervisor
| |- worker X
| |- worker Y

In cases where there are multiple processes depending on a certain worker's existence. It becomes relevant to have a life span that is implicitly controlled by these processes. This could be handled in multiple ways and therefore this discussion. An example where it is relevant within ertorrent is the handling of tracker worker processes. Multiple torrents might want to communicate with the same tracker, the tracker worker process can therefore not get killed off when one of the torrent processes consider itself to finished with the communication.

Two suggestions is reference counting and timeout.

A passive approach is timeout. When a process is needed it is spawned and it live as long as the depending processes is feeding it. When fed, the process will reset its timer. The risks with this approach is inefficiency and it's considered a fragile design. The fragile part is that the process risk to terminate when another process is about to feed it.

In my opinion the reference counting is more robust and won't leave processes alive and awaiting termination and therefore more efficient.

Thoughts and opinions?

See link for more information:
http://bittorrent.org/beps/bep_0010.html

Support: Peer wire protocol (TCP)

See section "peer protocol" in:
http://bittorrent.org/beps/bep_0003.html

See link for more information:
http://bittorrent.org/beps/bep_0007.html