Что: b35e390fb27533c78ba6b4c415e0ace7b9bffcec
Когда: 2022-11-26 23:32:47+03:00
Темы: bittorrent
Написал BitTorrent клиент Сегодня вот полностью стал им (8357328821a1a6859a268197a618554b875a87c6) seed-ить все свои торренты. При запуске можно указать IPv4, IPv6 адреса, DHT bootstrap адреса, ну и где слушать. github.com/anacrolix/torrent DHT тоже обслуживает на том же самом порту что и торренты. На экран будет выводиться общее кол-во принятого/переданного трафика и скорости раз в секунду. Создаются "add", "del", "list" FIFO файлы. Если записывать строчку с путём от .torrent или magnet: ссылку в "add", то он будет добавлен в клиент. Запись (info) хэша торрента в del -- удалит его из клиента. cat list покажет (с цветами) вывод аналогичный godiana (0c40b3f99ee554b301bd40b1b4d4c6390c746834). Для каждого торрента создаются также "files/HASH" и "peers/HASH" FIFO, который выдают цветастый вывод с информацией о peer-ах и файлах. Для хранения информации о проверенных кусочках всё продолжает использоваться BoltDB, но по отдельному файлу на каждый торрент. По идее, конечно же, overhead, но раз оно уже написано, занимает мало коду, работает, не надо париться с консистентностью при обновлении этого файла, то, боюсь что так и оставлю. Если добавить совершенно новые торренты для seed-а, то их проверка будет идти параллельно, что плохо для производительности на HDD. Для себя проблему решил добавлением -verify флага к клиенту, где можно указать .torrent и он только проверит целостность торрента, с созданием БД, и выйдет. Просто в shell цикле пройдя по torrent-ам их можно подготовить для вставки в клиент. Пока совершенно нет никакого сохранения знания о seed ratio. Возможно буду его писать в уже имеющийся BoltDB для каждого торрента. Но и без этого уже можно использовать. Ну и пока нет возможности выбора директории для скачивания торрента. У меня два больших ZFS pool-а с торрентами и сейчас я банально запустил два клиента на разных портах параллельно. Стоит, конечно, заняться этим вопросом плотнее. Для этого надо собственный storage написать будет, но вроде выглядит довольно легко. По uTP общается, шифрование peer-ов есть, с трэкерами и DHT, IPv4/IPv6 -- все летает и существенно быстрее находит peer-ов. Если aria2 перезапустить, то она с минуту может начать хоть что-то кому-то отдавать. CPU жрёт при этом немного поболее: ~12% одного ядра одним клиентом, и ~4% другим, в котором только шесть торрентов. Listen queue нулевой: никто не ждёт в очередях (35f498b93a95b1d620889197042db8a941aa0428). Но потребление памяти клиентом растёт со временем неспешно. Утром посмотрю до каких значений вырастет, если не упадёт с какой-нибудь паникой за ночь. Но все 100Mbps с сотнями активных peer-ов заняты. Пока это писал, то размер занимаемой памяти вообще стал уменьшаться -- так что возможно это и не утечки. В общем, пока очень очень доволен получившимся результатом. По сути то я конечно просто сделал незатейливый frontend для библиотеки. Хотя пару мест в ней пришлось подправить и сделать данные публично доступными. Например крайне мало чего можно узнать о peer-е было. Отображение информации о торрентах происходит моментально, тогда как aria2 можно было ждать (ответа от её RPC) в течении секунд десяти. На будущее: ещё знаю что надо будет рано или поздно добавлять в storage на тему переименования файлов (cdc44c7a1bb63c5822313ac73e99a39bda088bff), так как могут быть имена настолько длинные, что не уместятся в ФС. Уже сделал коммит, но не стал ничего никуда push-ить, потому что ещё не знаю как обозвать репозиторий. Ведь придумывание названия дело ответственное и сложное, так что на свежую голову надо. Изначально хотел просто github.com/anacrolix/torrent добавить как зависимость к отдельному Go проекту. Но раз пришлось править саму библиотеку (из-за приватных методов), то это будет уже fork-ом.
Сгенерирован: SGBlog 0.34.0