zitrax / zit Goto Github PK

And cleanup list of peers, killing of the ones that never connected and eventually connect to new that we are not already connected to.

To make them clear that they are C++ not C.

Remember to update the clang tidy header filter in CMakeLists.txt.

Resolving hosts make the output nicer, but resolving slows things down a bit. Let that be a configurable option.

The current build.yml will not work with conan 2.0, is has therefore been fixed to 1.60.2.

Should either update to use new Conan 2 compatible build, or just go with vcpkg instead.

Currently its 20 random chars, but the spec say:

There are mainly two conventions how to encode client and client version information into the peer_id, Azureus-style and Shadow's-style.

Azureus-style uses the following encoding: '-', two characters for client id, four ascii digits for version number, '-', followed by random numbers.

For example: '-AZ2060-'...

It could possibly also be configurable.

The current implementation for arg parser does not support a value without a key, thus we take the torrent file using --torrent. Would make sense if you could just pass the file directly.

Just a reminder.

Seems like we contact a lot of peers even when starting up with a finished torrent, that is probably unnecessary. Should just wait for others to contact us.

Currently using ctorrent in the integration test for a command line client leecher.

This turns out to be unreliable, since both tracker, seeder and leecher are on localhost ctorrent sometimes try to connect to itself depending on timing or random order selection:

1567357479 Connecting to 127.0.0.1:2706 (peer 0x55f12932a980)
1567357479 Connection from duplicate peer 127.0.0.1
1567357479 Connection from duplicate peer 127.0.0.1
1567357479 0x55f12932a980: remote closed

zit iself avoids this by skipping localhost.

Could either use multiple ips, or use another client for leeching. ctorrent has not maintained since 2006.

libtorrent would be a maintained modern implementation.

Investigate if it would be easier to use a default spdlogger instead of the current way that gets "console" all the time.

Also consider logging to stderr instead of stdout such that we can pipe output without getting the log messages.

See https://spdlog.docsforge.com/v1.x/0.faq/#switch-the-default-logger-to-stderr

Also have the "announce-list" which is currently not looked at.

When we cannot write pieces to disk we keep accumulating them in the FileWriter causing large memory usage. There should be a limit where we stop and choke until the FileWriter can resume moving pieces to disk. It could be a configurable max amount of bytes in queue.

It would be convenient to being able to dump the current config file to disk as a starting point.

I am not sure if this is still true, needs investigation.

Current tests are just working on a single torrent at a time.

Some torrents such as: https://distrowatch.com/dwres/torrents/tails-amd64-5.17.iso.torrent contain udp urls for the announce urls. We currently do not handle that.

They are now hardcoded, but with the recently added config support it should be easier to make it configurable.

With: "exception: filesystem error: cannot get file size: Is a directory".

It would probably fail to keep seeding it as well due to the split operation.

Check if this still is true.

Being able to download a subset of a torrent with mulitple files can be very handy.

A cli ui for this could be some work though, as a start proper support on the api level. Further tasks could be added for the cli ui.

Should nuke bad pieces instead of having to restart from 0.

The current command line interface only allows a single torrent with --torrent <file>, optimally it should be able to take more or even a directory of torrents.

Revealed by the download_dual_torrents test we currently need one listener port per torrent, this is not implemented for the main application and also does not scale.

There should optimally be one listener port that can be used by multiple torrents.

Add config file documentation to readme.

It's annoying when you only want to dump the torrent info.

Some torrents do not have any of the "announce" or "announce-list" fields. Zit currently relies on it to find peers.

I assume this is a DHT only torrent. Retest when/if that is implemented.

Example: https://distrowatch.com/dwres/torrents/archlinux-2023.09.01-x86_64.iso.torrent