Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"После пятилетнего перерыва выпущен BitTorrent-клиент rTorrent 0.10.0"	+/–
Сообщение от opennews (??), 29-Сен-24, 23:22
Спустя пять лет после формирования прошлого выпуска доступен релиз консольного BitTorrent-клиента rTorrent 0.10.0. Интерфейс программы построен с использованием библиотеки ncurses и может использоваться при подключении через SSH в  мультиплексорах терминала, таких как  tmux и screen. Возможен перевод клиента в фоновый режим, управляемый при помощи XMLRPC (например, для управления может использоваться web-интерфейс  ruTorrent или утилиты  pyrocore). rTorrent  совместим почти со всеми  BitTorrent-трекерами, поддерживает Magnet-ссылки, PE (Protocol Encryption), суперсид (Super-seeding), DHT (Distributed Hash Table) и PEX (Peer exchange). Код проекта написан на языке C++ и распространяется под лицензией GPLv2... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=61954
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

1. Скрыто модератором	–26 +/–
Сообщение от Аноним (1), 29-Сен-24, 23:22
Помню, всегда отвратно (не)работал, так и не написали нормального клиента за 20+ лет, хотя казалось бы. Мюторрент хоть и проприетарь, вообще ни разу проблем не создавал (2ка), да и по ресурсам намного лучше был (с протоколом правда тоже были вопросы).
Ответить | Правка | Наверх | Cообщить модератору

	3. Скрыто модератором	+8 +/–
	Сообщение от Аноним (3), 29-Сен-24, 23:31
	Трансмиссия работает отлично. Но зачем оно тебе?
	Ответить | Правка | Наверх | Cообщить модератору

	4. Скрыто модератором	–11 +/–
	Сообщение от Аноним (1), 29-Сен-24, 23:38
	Трансмиссия не работает отлично. Я лично пару десятков критических багов собрал. Большинство уже исправили, но перехешировать переодически всё ещё приходится, слетает почему-то (данные на диске все на месте и не повреждены, я проверял). Но альтернативы ещё хуже. А зачем, не знаю, скачивать линукс можно и aria2. Раньше держал фоном, но потом решил, что в гробу видел пиявок.
	Ответить | Правка | Наверх | Cообщить модератору

	53. Скрыто модератором	+/–
	Сообщение от ryoken (ok), 30-Сен-24, 07:32
	https://github.com/BiglySoftware/BiglyBT
	Ответить | Правка | Наверх | Cообщить модератору

	88. Скрыто модератором	+/–
	Сообщение от Аноним (88), 30-Сен-24, 10:47
	Про такой клиент вообще не знал, спасибо! Выглядит фичасто, есть смысл переходить с qBittorrent?
	Ответить | Правка | Наверх | Cообщить модератору

	121. Скрыто модератором	+/–
	Сообщение от ryoken (ok), 30-Сен-24, 16:38
	> Про такой клиент вообще не знал, спасибо! > Выглядит фичасто, есть смысл переходить с qBittorrent? Я до прошлых выходных сам не знал :). А насчёт переходить - погоняйте с неделю, сделаете выводы.
	Ответить | Правка | Наверх | Cообщить модератору

	104. Скрыто модератором	+/–
	Сообщение от Аноним (104), 30-Сен-24, 11:56
	BiglyBT написан на Яве. Интересно, как у него со скоростью и жором памяти, по сравнению с qBittorrent.
	Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

	106. Скрыто модератором	+/–
	Сообщение от ryoken (ok), 30-Сен-24, 12:17
	> BiglyBT написан на Яве. Интересно, как у него со скоростью и жором > памяти, по сравнению с qBittorrent. Ну зато он съел торрент-файл, которым подавился Трансмишен :). Долго не гонял, но так вроде и не сказать чтоб всё раком вставало.
	Ответить | Правка | Наверх | Cообщить модератору

	55. Скрыто модератором	+8 +/–
	Сообщение от X86 (ok), 30-Сен-24, 07:34
	QBittorrent чем не нравится?
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	54. Скрыто модератором	+/–
	Сообщение от timur.davletshin (ok), 30-Сен-24, 07:32
	Для раздачи множества торрентов её надо рихтовать напильничком немного, лично я подгружаю modprobe tcp_lp и указываю "peer-congestion-algorithm": "lp" в settings.json, чтобы не было жалоб у домашних, когда идёт раздача на полный канал.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	61. Скрыто модератором	+/–
	Сообщение от Аноним (61), 30-Сен-24, 07:49
	Чтобы не было жалоб у домашних, шейпинг на роутере - правильное решение, насколько я понимаю.
	Ответить | Правка | Наверх | Cообщить модератору

	63. Скрыто модератором	–1 +/–
	Сообщение от timur.davletshin (ok), 30-Сен-24, 07:54
	> Чтобы не было жалоб у домашних, шейпинг на роутере - правильное решение, > насколько я понимаю. На практике заставить это работать сложнее (реализовать просто, но оно не будет работать, как ожидается), т.к. почти все провайдеры режут или переобозначают поле DSCP (ToS/QoS) в пакетах. Поэтому использование менее агрессивного алгоритма (в сравнении со стандартными Cubic и Reno) куда эффективнее. Но, опять же, AQM (Active Queue Management) частично помогает в борьбе с проблемой даже и в том случае, когда нет возможности указывать алгоритм. Вопрос многогранен и каждый выбирает действенное решение сам. У меня есть и AQM, и DSCP, и возможность указывать менее агрессивный алгоритм.
	Ответить | Правка | Наверх | Cообщить модератору

	67. Скрыто модератором	+/–
	Сообщение от robot228 (?), 30-Сен-24, 08:33
	Она не может нормально работать. Она вообще вся кривая.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	8. Скрыто модератором	+/–
	Сообщение от Аноним (8), 29-Сен-24, 23:50
	qbittorrent?
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	10. Скрыто модератором	–11 +/–
	Сообщение от Аноним (1), 29-Сен-24, 23:54
	Полчаса запускается, проблемы с подключением других клиентов, постоянно насилует диски, последней каплей было осознанное обнуление существующих тегов при обновлении. Софт, разрабатываемый низкоуровневыми чертями, не для меня.
	Ответить | Правка | Наверх | Cообщить модератору

	14. Скрыто модератором	+/–
	Сообщение от Аноним (14), 30-Сен-24, 00:15
	> Софт, разрабатываемый низкоуровневыми чертями А можно подробнее?
	Ответить | Правка | Наверх | Cообщить модератору

	17. Скрыто модератором	+1 +/–
	Сообщение от Аноним (1), 30-Сен-24, 00:26
	Удалять данные пользователей без предупреждения это последнее дело. Ну и видно, что вообще не понимают, что и зачем делают. Такое обычно случается, когда за разработку берутся дилетанты без малейшего опыта.
	Ответить | Правка | Наверх | Cообщить модератору

	68. Скрыто модератором	+1 +/–
	Сообщение от Аноним (68), 30-Сен-24, 08:45
	>осознанное обнуление существующих тегов при обновлении Можно про это подробнее? Когда и где такое происходило? Я его использую несколько лет и ничего подобного не видел. У меня к нему одна претензия - очень долго грузится с большим количеством торрентов.
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	75. Скрыто модератором	+/–
	Сообщение от Аноним (75), 30-Сен-24, 09:57
	Я не знаю что там надо делать, чтоб qBittorrent запускался полчаса или насиловал диски. Раздаю 5К+ торрентов на рутрекере, суточный трафик более трёх терабайт. Всё работает как часы на протяжении последних пяти лет, что конфиг существует - на 4 Гб оперативы и дисках в обычном RAID0.
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	78. Скрыто модератором	+1 +/–
	Сообщение от Аноним (78), 30-Сен-24, 10:10
	Попробуйте ради интереса выбрать сто из них и нажать "Проверить принудительно". У меня в таком случае он помечает случайные торренты как недокачанные на 4 MiB, хотя файлы все на месте и по хеш-суммам проверку проходят. После этого он начинает докачивать эти самые 4 MiB, снова проверяет торрент и опять помечает как недокачанный. Кое-как с матами и тысячей перезапусков удалось вернуть все торренты обратно в состояние "Раздаётся". Про это также писали на реддите и в issues на гитхабе, но какого-то чёткого решения нет.
	Ответить | Правка | Наверх | Cообщить модератору

	79. Скрыто модератором	+/–
	Сообщение от Аноним (75), 30-Сен-24, 10:13
	Регулярно рехэшу обновляемые раздачи (самая жирная из них на 1.2 Тб), с таким поведением не сталкиваюсь. Всё время живу на ночниках автособираемых раз в сутки той же машиной, что раздаёт торренты.
	Ответить | Правка | Наверх | Cообщить модератору

	91. Скрыто модератором	–2 +/–
	Сообщение от Аноним (1), 30-Сен-24, 11:05
	Я думаю, дело вовсе не размере, а в количестве файлов. Иногда ещё в том, как и чем было создано (некоторые даже не каждая программа откроет). Тысячи маленьких куда серьёзнее, чем 1 большая. >Всё время живу на ночниках Тут видно, что живёшь ты очень недолго и плохо. Либо врёшь, либо даже не беспокоишься о серьёзных багах с перманентной потерей данных. Все эти проблемы несколько раз лезли через пару лет накопления миллиардов файлов. Но у трансмиссии с таким же поведением сталкивался. Она не проверят все файлы при каждом запуске, поэтому, сложнее словить.
	Ответить | Правка | Наверх | Cообщить модератору

	94. Скрыто модератором	+/–
	Сообщение от Аноним (75), 30-Сен-24, 11:16
	>> Я думаю, дело вовсе не размере, а в количестве файлов. Значительная часть из раздач - это распакованные игори и копии библиотек, поэтому мелких файлов там предостаточно. >> Тут видно, что живёшь ты очень недолго и плохо Откуда видно, из комнаты с мягкими стенами? >> либо даже не беспокоишься о серьёзных багах с перманентной потерей данных Ты видимо не заметил, но я и диски держу в массиве без резервирования.
	Ответить | Правка | Наверх | Cообщить модератору

	129. Скрыто модератором	+1 +/–
	Сообщение от Аноним (-), 30-Сен-24, 17:14
	Спасибо вам за раздачу!
	Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

	81. Скрыто модератором	+1 +/–
	Сообщение от Аноним (81), 30-Сен-24, 10:25
	>Полчаса запускается Так твоя проблема, видимо, в железе из каменного века. Обнови кампуктер и проблемки сами исчезнут. Что трансмиссия, что кубитторент - все прекрасно работают у меня почему-то. И да, кубитторрент запускается 10 сек, проверил ради интереса. С моим-то допотопным железом...
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	83. Скрыто модератором	+/–
	Сообщение от Аноним (81), 30-Сен-24, 10:27
	Про 10 сек соврал. Там гораздо меньше, я его подержал открытым секунды три-четыре. Не подумал, что команда time будет считать уже работающую прогу.
	Ответить | Правка | Наверх | Cообщить модератору

	89. Скрыто модератором	–2 +/–
	Сообщение от Аноним (1), 30-Сен-24, 10:54
	Теперь заведи хотя бы 10000 торрентов и полюбуйся на время запуска. Перехешировать всё при каждом запуске это не нормально.
	Ответить | Правка | К родителю #81 | Наверх | Cообщить модератору

	96. Скрыто модератором	+1 +/–
	Сообщение от Аноним (75), 30-Сен-24, 11:20
	Да никто не перехеширует всё при каждом перезапуске, тебе ещё раз говорят. На моём конфиге, что я описал выше, полный рехэш происходит только на активных раздачах которые ещё не завершились, находятся на закачке, и только если процесс был завершён аварийно. Перестань выдёргивать кудахтер из розетки вместо выключения, и всё у тебя будет хорошо.
	Ответить | Правка | Наверх | Cообщить модератору

	100. Скрыто модератором	–3 +/–
	Сообщение от Аноним (1), 30-Сен-24, 11:29
	Но ведь это нормально, что не завершились. У меня всего пара завершились за всё время и то мне надоело с них петабайты раздавать и всё равно полтора сида. Пару раз трансмиссия кстати потеряла данные и на них (но они вернулись после перехеширования без докачивания). У кубитторента постоянно перехешируется всё на каждом запуске.
	Ответить | Правка | Наверх | Cообщить модератору

	110. Скрыто модератором	+/–
	Сообщение от Аноним (75), 30-Сен-24, 13:08
	>> Но ведь это нормально, что не завершились Говоря "завершились" имеется в виду "докачались полностью". >> У кубитторента постоянно перехешируется всё на каждом запуске. Ещё раз - нет. Рехэшится либо те раздачи, что явно писали что-то на диск при аварийном завершении процесса самого клиента, либо те что были перенесены на диске физически после восстановления ФС или журнала. При штатном завершении записи и останове процесса qbittorrent никаких принудительных рехэшей на каждом запуске не происходит. Чини свой конфиг.
	Ответить | Правка | Наверх | Cообщить модератору

	115. Скрыто модератором	–2 +/–
	Сообщение от Аноним (1), 30-Сен-24, 14:44
	В интернете говорят, что у всех так. И не при аварийном завершении, а со вполне обычным (это можно было бы ещё понять). Это наиболее мерзкий недостаток сразу после обнуления пользовательских данных при обновлении (теги, локации на диске теряются и скачивает сначала). То что есть проблемы с подключением других клиентов это такая мелочь уже.
	Ответить | Правка | Наверх | Cообщить модератору

	119. Скрыто модератором	+/–
	Сообщение от Аноним (75), 30-Сен-24, 16:27
	А в газетах говорят, что конец света скоро. Нет ссылок на конкретные issue - значит, уходи.
	Ответить | Правка | Наверх | Cообщить модератору

	122. Скрыто модератором	–1 +/–
	Сообщение от Аноним (1), 30-Сен-24, 16:39
	Я с ходу нашёл с десяток "issue" с конкретно этой проблемой, всем плевать. Что ты там хочешь увидеть?
	Ответить | Правка | Наверх | Cообщить модератору

	124. Скрыто модератором	+2 +/–
	Сообщение от Аноним (75), 30-Сен-24, 16:52
	Ссылки на баги на гитхабе прикладывай, пустозвон.
	Ответить | Правка | Наверх | Cообщить модератору

	141. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Аноним (104), 30-Сен-24, 18:11
	> При штатном завершении записи и останове процесса qbittorrent никаких принудительных рехэшей на каждом запуске не происходит. Подтверждаю, у меня тоже qBittorrent при нормальном завершении следующем запуске ничего не перехеширует.
	Ответить | Правка | К родителю #110 | Наверх | Cообщить модератору

	16. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+4 +/–
	Сообщение от Аноним (16), 30-Сен-24, 00:26
	Может проблема с Вами, поскольку rtorrent прекрасно работает?
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	30. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+5 +/–
	Сообщение от Аноним (30), 30-Сен-24, 01:26
	Проблема не с ним, а с тем, что на компе винда.
	Ответить | Правка | Наверх | Cообщить модератору

	45. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	–2 +/–
	Сообщение от Ivan_83 (ok), 30-Сен-24, 05:02
	Я думал одно время написать "нормальный клиент" для себя. Но: 1. вроде как торрент обещают что вот вот умрёт (уже лет 15 как :) ) 2. это надо кучу времени/сил, а rTorrent+ruTorrent не настолько плохи чтобы мотивировать И честно говоря, uTorrent как идеал - это скорее привычка/эффект утёнка. Трансмисия - соеобразное, aria не пробовал, qbittorrent тоже не пробовал из за QT да и хотелось решение с вебмордой на домашнем сервере, чтобы не разводить зоопарк и не бегать потом: "кто там торрентом весь канал забил!?".
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	46. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+1 +/–
	Сообщение от merv (?), 30-Сен-24, 05:23
	qbittorrent может работать как демон, без gui, но с веб-интерфейсом.
	Ответить | Правка | Наверх | Cообщить модератору

	48. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от timur.davletshin (ok), 30-Сен-24, 07:17
	> вроде как торрент обещают что вот вот умрёт (уже лет 15 как :) Ну вообще-то аудитория упала. Хотя ничего удобнее для быстрой раздачи информации нет (без привлечения доп. ресурсов). Даже ойтишнеги про это забывают. Тут вот недавно товарищ: "Ща, на Яндекс Диск закину и скачаешь". - "Зачем на диск? Запили раздачу и ссылку кинь". - "За 20 лет в IT ни разу так не делал" )))
	Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

	51. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Аноним (51), 30-Сен-24, 07:23
	Из-за NAT оно как, хорошо будет раздаваться?
	Ответить | Правка | Наверх | Cообщить модератору

	56. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от timur.davletshin (ok), 30-Сен-24, 07:34
	> Из-за NAT оно как, хорошо будет раздаваться? Я за NAT и реальный IPv4 и префикс на роутере. За CGNAT тоже не должно быть проблем, но большинство айтишников сидят за ванильным miniupnpd, а там есть нюанс из-за позиции разработчика, который отказывается запиливать функцию из-за отсутствия её в стандарте UPnP. Короче, надо указывать вручную айпишник внешний, т.к. STUN, вопреки ожиданиям, не будет работать.
	Ответить | Правка | Наверх | Cообщить модератору

	116. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Аноним (51), 30-Сен-24, 15:03
	Удобно, не передать словами. > реальный IPv4 Вымирающий вид.
	Ответить | Правка | Наверх | Cообщить модератору

	126. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от timur.davletshin (ok), 30-Сен-24, 17:08
	> Удобно, не передать словами. В вотсапе удобнее, не спорю.
	Ответить | Правка | Наверх | Cообщить модератору

	195. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Аноним (-), 04-Окт-24, 04:27
	>> Удобно, не передать словами. > В вотсапе удобнее, не спорю. Торенты то качать? И что, хорошо получается? Туда таки и это уже встроили? :)
	Ответить | Правка | Наверх | Cообщить модератору

	199. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Аноним (199), 04-Окт-24, 20:46
	> Ну вообще-то аудитория упала. Хотя ничего удобнее для быстрой раздачи информации нет > (без привлечения доп. ресурсов). Даже ойтишнеги про это забывают. Тут вот > недавно товарищ: "Ща, на Яндекс Диск закину и скачаешь". - "Зачем > на диск? Запили раздачу и ссылку кинь". - "За 20 лет > в IT ни разу так не делал" ))) Есть некая разница между сначала закачаю, потом скачаешь и "передал файл". Во втором случае эти процессы идут одновременно, и результат имеет основания быть раньше. А кроме того - если файл был допустим виртуалкой с диском на 10 гигз, и чего-то чексум не сошелся - теперь чего, перекачивать все 10 гигз? О, круто. А можно и 1 блок. Небось айтишник из яндекса, будущее которое вы заслужили...
	Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

	49. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от timur.davletshin (ok), 30-Сен-24, 07:20
	>>> Трансмисия - своеобразное... Она везде есть, простая и большинству её за глаза. Хотя к некоторым сидам может и не подключиться. Но вроде как в новых версиях пофиксили, но у меня Debian и там 3.*.
	Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

	59. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+1 +/–
	Сообщение от Ivan_83 (ok), 30-Сен-24, 07:40
	Скажем так, после uTorrent всё смотрится не так. То что оно есть везде - как бы не важно когда ищешь то к чему привык. Да и во все эти клиенты я смотрел лет 15 назад, когда искал замену uTorrent, тогда запилил rtorrent+rutorrent и больше ничего не искал. Aria кажется уже после появилась. Конкретно в трансмисии не понравилось то что оно всё качает только в одну папку. У меня уже до того было распихано по разным папкам откуда я и раздавал. Одно время приходилось при каждом обновлении rtorrent лезть внутрь и отпиливать его TUI руками, ибо у него не было варианта просто работать демоном. И обновлялся он раньше часто. Вот кажется в прошлом обновлении 5 лет назад режим демона наконец то втащили в кодовую базу.
	Ответить | Правка | Наверх | Cообщить модератору

	60. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+1 +/–
	Сообщение от timur.davletshin (ok), 30-Сен-24, 07:45
	> Скажем так, после uTorrent всё смотрится не так. Видел пару раз лет 10 назад. Кроме рекламы ничем не запомнилась. > Конкретно в трансмисии не понравилось то что оно всё качает только в > одну папку. > У меня уже до того было распихано по разным папкам откуда я > и раздавал. Мне вообще не нравится, как именуют торренты. Руки бы поотбивал. Но это мои личные проблемы, на практике это проблем не создаёт. Не знаю, может есть торрент-клиент, который позволяет раздавать переименованный файл (хэш-суммы от этого никак не меняются же)?
	Ответить | Правка | Наверх | Cообщить модератору

	82. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Анонус (-), 30-Сен-24, 10:26
	Проверил в своём Qbittorrent 4.6.3. Переименовывать можно, на диске при этом хранится в прежнем виде. Но надеюсь, никому не придёт в голову сделать возможность переименовывания файлов на диске. Ведь эти файлы будут раздаваться, что преведёт к хаосу.
	Ответить | Правка | Наверх | Cообщить модератору

	85. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от timur.davletshin (ok), 30-Сен-24, 10:37
	> Проверил в своём Qbittorrent 4.6.3. Переименовывать можно, на диске при этом хранится > в прежнем виде. Но надеюсь, никому не придёт в голову сделать > возможность переименовывания файлов на диске. Ведь эти файлы будут раздаваться, что > преведёт к хаосу. Какой хаос, если хэш-суммы у блоков не зависят от имени файла? Но опять же, это мои хотелки. Технических препятствий нет.
	Ответить | Правка | Наверх | Cообщить модератору

	102. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Анонус (?), 30-Сен-24, 11:44
	Нашёл как переименовывать файлы в qbittorrent. Реально полезная фича. Делается в контекстном меню по правой кнопке на содержимом торрента.
	Ответить | Правка | Наверх | Cообщить модератору

	108. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от timur.davletshin (ok), 30-Сен-24, 12:25
	> Нашёл как переименовывать файлы в qbittorrent. Реально полезная фича. Делается в контекстном > меню по правой кнопке на содержимом торрента. Отлично же!
	Ответить | Правка | Наверх | Cообщить модератору

	164. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Аноним (164), 01-Окт-24, 03:16
	> И честно говоря, uTorrent как идеал - это скорее привычка/эффект утёнка. Его лю за то что мелкая прога в 300 кил делала полный фарш, резво и круто. Кохем после того как скупил его - изгадил просто в хлам, разумеется. > Трансмисия - соеобразное, aria не пробовал, Aria2 - тоже своеобразный. Это универсальная качалка и торент там больше до кучи. Но вообще работает, даже симпотные вебморды есть. Но все же специфичная штука. > qbittorrent тоже не пробовал из за QT да и хотелось решение с вебмордой > на домашнем сервере, чтобы не разводить зоопарк и не бегать потом: "кто там торрентом весь > канал забил!?". А пробовал то что?! А то не видев ни 1 клиента писать свой... ну... ээ.... попробуй. Только протокол довольно навороченый, BEPов есть, всякие там шифрования, PEX, DHT, magnet links (metadata xfer - скачка по только хешу), кеширование диска надо кастомное особенно на механике, в общем сложная прога так то :)
	Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

	180. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Ivan_83 (ok), 02-Окт-24, 02:53
	Я проблему для себя закрыл 15 лет назад сабжем :) А по коду, у меня есть: - uTP своя реализация - BEP или чего то там парсер, чтобы с трекерами общатся и как я понимаю там эта кодировка и для торрент файлов и где то ещё И мне трудно будет сделать API и вебгуй как rutorrent или просто совместимое API, всмысле это потребует усилий больше чем сетевая часть с протоколами.
	Ответить | Правка | Наверх | Cообщить модератору

	196. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Аноним (-), 04-Окт-24, 04:35
	> Я проблему для себя закрыл 15 лет назад сабжем :) Сабж вроде uTP не умеет. Что довольно иронично для плюсатой программы, но вот как он 15 лет был так примерно и застрял по фичам. > А по коду, у меня есть: > - uTP своя реализация И что, вы ее прикрутили к сабжу? Это так то довольно канительно. И кроме того - поведение "своей реализации" догнать до желаемого, как то - с 1 стороны приличный перфоманс, с другой back off при нагрузке на канал ибо это ФОНОВЫЕ трансфееры, и отсутствие факапов типа ухода в мелкие пакеты оптом - порой добивающие роутер/линк окончательно - тот еще рокетсайнс. Вы утверждаете что вы обставили всю тиму Кохема, которые таки основательно попахали над либой и адекватно у них вышло далеко не сразу? Не забываем про синдром "свое не пахнет", если что. > - BEP или чего то там парсер, чтобы с трекерами общатся и > как я понимаю там эта кодировка и для торрент файлов и где то ещё Ну я понял, тот извращенский формат торентовской полубинарнополутекстовой лабуды :) > И мне трудно будет сделать API и вебгуй как rutorrent или просто > совместимое API, всмысле это потребует усилий больше чем сетевая часть с > протоколами. Ну вот именно XML в апях сейчас даже в вебе уже так-то из фавора - выпал. И хотя XHR называется так в честь XML, вот именно XML через него уже почти никто и не гоняет, что иронично. А сабж - ну он просто застрял в состоянии 15-летней давности, да...
	Ответить | Правка | Наверх | Cообщить модератору

	202. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Ivan_83 (ok), 05-Окт-24, 05:15
	Мне uTP не нужен, его отсутствие не проблема для меня. Я не фанат этого протокола и считаю что TCP намного лучше работает и что с ним проблем никаких нет, которые бы стоило решать корябая uTP, HTTP/3 и прочие поделки. Под моей реализацией uTP понимается именно реализация парсера протокола и кажется у меня RST сообщение умеет генерить. http://netlab.dhis.org/wiki/software:article:utp_dpi Congestion Control и Socket API я к нему не делал и не собирался. Собственно CC нужен исключительно на отдачу, если делать только качалку то можно и без него обойтись. И авторы этого всего вроде как выложили готовую либу, судя по моим старым записям :) Насчёт рокетсаенса - фигня, берём простенький hybla из линуха и радуемся жизни, он отлично работает даже на фоне более современного RACK.
	Ответить | Правка | Наверх | Cообщить модератору

	76. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Аноним (76), 30-Сен-24, 10:04
	>  так и не написали нормального клиента за 20+ лет qBittorrent — для тех, кому нужен полноценный клиент со всем возможным функционалом. Transmission — для тех, кому просто качать. Оба надёжны как топор. А первый, похоже, и лидер на рынке. Ты что такое говоришь?!..
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	130. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от чайковски (?), 30-Сен-24, 17:19
	есть ведь ариа че еще нужно?
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

2. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+1 +/–
Сообщение от Аноним (3), 29-Сен-24, 23:28
Проблему с трекером решили? Ах ну да, кому это нужно? Коллективная ответственность за неизвестных людей небось пугает. Кто ж будет децентрализовать трекер? Да ещё и гарантировать правильную его работу. Только сиды и личи децентрализованы
Ответить | Правка | Наверх | Cообщить модератору

	5. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+2 +/–
	Сообщение от НяшМяш (ok), 29-Сен-24, 23:45
	Если использовать магнет ссылки и DHT - трекер не нужен.
	Ответить | Правка | Наверх | Cообщить модератору

	13. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	–4 +/–
	Сообщение от Аноним (-), 30-Сен-24, 00:14
	Та это частичное решение, на грани законов.
	Ответить | Правка | Наверх | Cообщить модератору

	71. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+5 +/–
	Сообщение от Аноним (71), 30-Сен-24, 09:05
	>>  Та это частичное решение, на грани законов. Ты ничо не попутал? Не соблюдая авторские права ты в любом случае идёшь против законов. И не важно каким способом это делаешь. Другое дело что нарушать подобные законы есть право и долг человека и гражданина.
	Ответить | Правка | Наверх | Cообщить модератору

	150. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Аноним (150), 30-Сен-24, 18:38
	Ну от координатор вполне прекрасно знает зачем он создаёт трекер и идёт против законов. А то что он делегирует ответственность на общество, которое пользуется DHT, это скорее недостаток законов - это же соучастие, разве нет? Опять таки тот кто делает трекер - занимается политикой и дальше нет смысла писать что, зачем и почему, так как трекера закон не касается.
	Ответить | Правка | Наверх | Cообщить модератору

	21. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	–2 +/–
	Сообщение от Аноним (-), 30-Сен-24, 00:32
	DHT все равно же координирует трекер? Не так давно с помощью статистического анализа вычислили сайт из даркнета. Какие проблемы вычислить трекер и накрыть медным тазом все эти DHT? Ну через время, если там не один трекер используется.
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	77. Скрыто модератором	+/–
	Сообщение от Аноним (76), 30-Сен-24, 10:05
	Нет.
	Ответить | Правка | Наверх | Cообщить модератору

	109. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+2 +/–
	Сообщение от ProfessorNavigator (ok), 30-Сен-24, 13:04
	> DHT все равно же координирует трекер? Нет. Трекер может выступать, как один из узлов DHT (или не один - зависит от ПО и настроек). Данный узел может использоваться для бутстрапа (первичного подключения к сети DHT). Но как только вы подключились к DHT, то в вашем распоряжении фактически все узлы DHT с белыми ip, работающие по протоколу, описанному здесь: http://bittorrent.org/beps/bep_0005.html. Потому что каждый узел по протоколу должен иметь собственную таблицу маршрутизации, где хранятся адреса "хороших" узлов (ответивших хотя бы на один запрос за последние 15 минут). Всего таких узлов насчитывается порядка нескольких миллионов (число постоянно варьируется). Кроме того, даже узел, находящийся за NAT, можно превратить в частично "хороший". Поскольку DHT работает через UDP, можно отправлять примерно каждые 55-60 секунд "пинг"-запросы на узлы из собственной таблицы маршрутизации, тогда они в свою очередь смогут достучаться до вас. Потому что по протоколу UDP роутеры должны 1 минуту хранить данные в таблице соответствия внутренних и внешних адресов - на случай возможного ответа. Т.е. на 1 минуту за вами резервируется порт, с которого был отправлен исходящий UDP пакет. В свете всего вышесказанного ничто не мешает кешировать известные вам узлы и при следующем подключении к DHT пытаться бутсрапиться не к узлу трекера, а к узлам из кеша. Кроме того, по протоколу DHT данные (например активыне пиры) хранятся не только на разместившем их узле (что на самом деле вовсе не обязательно), а на узлах с наиболее близким ID (20 байт, по протоколу должен зависеть от внешнего IP). Т.е. для торрента это работает примерно так: берётся торрент файл, вычисляется его SHA1 хеш. Далее в сети DHT ищутся 8 наиболее близких узлов (близость вычисляется через операцию XOR над хешем и ID узла, чем меньше результирующее число, тем узел "ближе"), и на них анонсируется пир (т.е. размещаются внешние ip и порт, которые поддерживаются "открытыми" например через описанный выше механизм для UDP). Иными словами в большинстве случаев пиры в DHT хранятся вовсе не на узле трекера, а на каких-то других узлах. И в теории вы конечно можете их все "прихлопнуть" (несколько миллионов постоянно меняющихся адресов и портов, ага). Но на каком основании? Через торренты раздаётся много чего легального. Например образы некоторых дитсрибутивов Линукс. А узел DHT и вовсе не в курсе, что у него там хранится - он "знает" лишь SHA1 хэш и пары ip-порт. А может и вовсе этого не знать, потому что в торрент клиентах поддерживается протокол размещения в DHT произвольных данных (ограничение только по размеру - 1000 байт). А там в качестве идентификатора используется SHA1 хэш публичного ключа ed25519 и "соли" ("соль" в данном случае - любой небольшой набор байт, обычно - также хеш чего-нибудь). Данные же вообще могут быть чем угодно, главное - чтобы размер вписывался в ограничения.
	Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

	139. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Аноним (150), 30-Сен-24, 18:08
	> Данный узел может использоваться для бутстрапа Ну от и все.
	Ответить | Правка | Наверх | Cообщить модератору

	149. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+1 +/–
	Сообщение от ProfessorNavigator (ok), 30-Сен-24, 18:32
	> Ну от и все. Что "все"? Как я написал, узлов - несколько миллионов. Подключайтесь к любому. Трекерный узел только один. Да и в целом - его может вообще не быть, или он может не иметь информации о данной конкретной раздаче вообще. Потому что в соответствии с SHA1 хешем торрент-файла информация о пирах размещается вообще на других узлах. Которые например принадлежат трекерам, раздающем те же образы дистрибутивов Линукс. Причём всё это ещё и динамически меняется буквально каждую секунду - кто отключается, кто-то подключается.
	Ответить | Правка | Наверх | Cообщить модератору

	151. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Аноним (150), 30-Сен-24, 18:40
	Не подключился ты к любому просто так, только к тем что описаны в файле
	Ответить | Правка | К родителю #109 | Наверх | Cообщить модератору

	154. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+1 +/–
	Сообщение от ProfessorNavigator (ok), 30-Сен-24, 19:01
	> Не подключился ты к любому просто так, только к тем что описаны > в файле Вы путаете с трекерной раздачей. Когда раздача идёт с помощью DHT, механизм другой. Вы изначально имеете только SHA1 хеш торрент-файла (именно он идёт в magnet-ссылке). Далее по этому хешу подбираются 8 наиболее близких по ID узлов из вашей собственной таблицы маршрутизации и им отправляется запрос на наличие пиров для данной конкретной раздачи. В ответ вы получаете либо имеющиеся у них адреса пиров, либо 8 наиболее близких узлов из их таблицы маршрутизации, либо и то и другое сразу. Далее запрос циклически повторяется, пока в ответах не закончатся уникальные (т.е. отсутствующие в вашей таблице маршрутиации) узлы. Обычно в процессе вы получаете набор пиров и токенов (они необходимы для анонса себя самого в качестве пира). После чего уже вы на 8 наиболее близких узлах анонсируете себя в качестве пира. Дальше вам остаётся ждать и периодически посылать запросы на полученные адреса пиров, чтобы они в свою очередь могли отправить информацию вам. Когда соединение установлено, то вы в первую очередь получаете отсутствующий у вас торрент-файл с описанием раздачи. И вот в нём уже может и должен содержаться адрес трекера, если таковой имеется. Если я правильно помню спецификацию, то в magnet-ссылку может включаться адрес для начального бутсрапа в DHT. Но никто вас не заставляет им пользоваться.
	Ответить | Правка | Наверх | Cообщить модератору

	157. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Аноним (-), 30-Сен-24, 20:12
	> Далее по этому хешу подбираются 8 наиболее близких по ID узлов из вашей собственной таблицы маршрутизации и им отправляется запрос на наличие пиров для данной конкретной раздачи. Таблица маршрутизации откуда берется? Та что собирается сетевой картой или от того же трекера? Получил я допустим файлик через мессенджер без трекера. К кому он обратиться? Ко всем кто в таблице маршрутизации, опрашивая а нет ли возможности соединения?
	Ответить | Правка | Наверх | Cообщить модератору

	159. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от ProfessorNavigator (ok), 30-Сен-24, 21:07
	> Таблица маршрутизации откуда берется? В ответ на ваши запросы через DHT вам так или иначе присылаются списки узлов. Их можно кешировать. Для начального бутсрапа вы можете использовать любой узел. Некоторые из них широко известны (можете поискать DHT bootstrap nodes). Однако, как уже писал, на сегодня DHT торрент сеть - несколько миллионов узлов. Сколько точно - вряд ли кто-то вам скажет, поскольку количество меняется буквально ежесекундно. Бустрапиться можно к любому узлу, который имеет "белый" ip, нужно лишь узнать его адрес. В общем случае обычно достаточно подцепиться к абсолютно любой раздаче - того же Arch Linux например, чтобы ваш торрент-клиент пополнил собственную таблицу маршрутизации (она - не совсем то же самое, что таблица маршрутизации на роутерах, в DHT - это просто список ip адресов и портов узлов с их ID). > Та что собирается сетевой картой или от того > же трекера? Может - с трекера, если на нём запущен DHT узел (что совершенно не обязательно). Может - просто с произвольного DHT узла. > Получил я допустим файлик через мессенджер без трекера. К > кому он обратиться? Ко всем кто в таблице маршрутизации, опрашивая а > нет ли возможности соединения? Как уже писал выше, это работает не так. Допустим вы получили торрент-файл. Чтобы получить пиров для него через DHT, нужно прохешировать этот торрент файл, получив его SHA1 хеш, затем отправить запрос на анонс вашего пира на узлы, имеющиеся в вашей таблице маршрутизации. Запрос на анонс в свою очередь должен предваряться запросом на получение пиров (таков протокол). Запрос на получение пиров отправляется на 8 ближайших к хешу торрент-файла узлов из вашей таблицы маршрутизации (можно на большее количество, но особого смысла нет, только зря сеть нагрузите). Узлы имеют ID размером 20 байт (проще говоря - номер в диапазоне 0 - 2^160). Близость узла вычисляется через операцию XOR для хеша торрент-файла и ID узла. Чем меньше полученное в результате XOR число, тем узел "ближе". В ответ на ваши запросы узлы присылают вам либо адреса пиров, либо 8 наиболее близких узлов из их таблиц маршрутизации, либо и то, и другое сразу. Адреса узлов присылаются в любом случае. Далее вы циклически повторяете операцию с полученными узлами, пока вам присылаются отсутствующие в вашем списке узлы. В процессе вы пополняете свою таблицу маршрутизации, получаете пиров для ваше раздачи и токены (набор байт, длина может быть различной, в спецификации рекомендуется использовать хеш ip адреса запрашивающего узла в сочетании со случайным числом, они необходимы, чтобы анонсировать вашего пира на других узлах, токены действют 10 минут). Далее уже из списка полученных узлов вы выбираете 8 наиболее близких узлов (не обязательно столько, но опять же данное число оптимально) и анонсируете вашего пира. Т.е. отправляете ваш внешний ip адрес и порт, чтобы другие участники раздачи узнали про вас и могли к вам подключиться. Параллельно начинаете слать запросы на полученные адреса пиров - это необходимо для преодоления NAT с помощью техники UDP hole punch. Все вышеописанные операции большинство торрент-клиентов выполняют автоматически. Достаточно подсунуть им торрент-файл или magnet-ссылку (основной частью которой является SHA1 хеш торрент-файла). Если используется magnet-ссылка, то сначала от полученных из DHT пиров скачивается торрент-файл - он нужен, чтобы получить структуру файлов и разбивку на части, а также чтобы получить хеши частей.
	Ответить | Правка | Наверх | Cообщить модератору

	169. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	–1 +/–
	Сообщение от timur.davletshin (ok), 01-Окт-24, 07:15
	Вот дался тебе этот UDP hole punch. Его даже не все клиенты поддерживают. Например, rtorrent, в новости о котором ты пишешь, его не поддерживает.
	Ответить | Правка | Наверх | Cообщить модератору

	175. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от ProfessorNavigator (ok), 01-Окт-24, 13:06
	> Вот дался тебе этот UDP hole punch. Его даже не все клиенты > поддерживают. Например, rtorrent, в новости о котором ты пишешь, его не > поддерживает. Он не мне дался, оно просто так работает)) И rtorrent его скорее всего таки поддерживает, но не так, как вы думаете - там поддерживать особо нечего. BEP 55, если что, как уже говорил - это для трекеров, а также скорее всего для PEX.
	Ответить | Правка | Наверх | Cообщить модератору

	200. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Аноним (200), 04-Окт-24, 20:56
	> Таблица маршрутизации откуда берется? Та что собирается сетевой картой или от того > же трекера? Это другая, блин, таблица, лолка. Абстракция такая, софтварная, к таблицам маршрутизации в IP это отношения не имеет. Смотри, допустим ты что-то захешировал, и хэш 2345...CDEF. Клиент знал несколько nodes, скажем, 01234...., 2345...., 4567.... (в случае торента все эти числа 160 битов шириной, как хэщ sha1). При желании опубликовать (или найти) хэш 2345...CDEF мы смотрим кто у нас из узлов DHT есть, выбираем с ID самым близким к этому (2345.... в этом примере) и пуляем запрос - в него. Он либо финальное назначение, либо пришлет более близкие узлы. После чего процесс можно повторить уже с ними. И так за несколько итераций оно "роутит" запрос находя тех кто близок к искомому хэшу, на них и сохраняется, они же возвращают результат. Близость определяется как правило путем XOR двух 160 бит чисел (ID узла VS интересующий хеш) и рассмотрением результата как 160-bit числа. Чем меньше это число - тем "ближе к назначению" этот узел. Это не имеет никакого отношения к физической близости узлов и является абстракцией, по которой те или иные узлы решают что они (не)будут индексировать на себе. > Получил я допустим файлик через мессенджер без трекера. К > кому он обратиться? Ко всем кто в таблице маршрутизации, опрашивая а > нет ли возможности соединения? Питекантроп, рассматривая микроволновку: "так, черт, а почему в моем лесу у нее табло не светится? Надо духов свечения вызвать, не иначе."
	Ответить | Правка | К родителю #157 | Наверх | Cообщить модератору

	160. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Аноним (160), 30-Сен-24, 22:23
	Ага, ну понятно, спасибо ща пояснение.
	Ответить | Правка | К родителю #154 | Наверх | Cообщить модератору

	165. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Аноним (-), 01-Окт-24, 04:09
	> Нет. Трекер может выступать, как один из узлов DHT (или не один > - зависит от ПО и настроек). В случае DHT никакие трекеры вообще нафиг не уперлись. Хэш лукапается прямо в распределенной хэштаблице (DHT - distributed hash table). И что там какие-то трекеры делают - всем пофиг. > Данный узел может использоваться для бутстрапа (первичного подключения к сети DHT). Бутстрапается DHT обычно с "well known" узлов, а то и просто файлика с долгоиграющими нодами в комплекте. Вон то разве что до кучи. > за последние 15 минут). Всего таких узлов насчитывается порядка нескольких миллионов > (число постоянно варьируется). Более того - поэтому его нереально ТОЧНО измерить.. > В свете всего вышесказанного ничто не мешает кешировать известные вам узлы и > при следующем подключении к DHT пытаться бутсрапиться не к узлу трекера, > а к узлам из кеша. И все нормальные клиенты - так и делают. Записывают несколько сотен известных nodes из своих таблиц в файло - и стартуют с них. Никакие трекеры и проч при этом нафиг не. Если это почему-то не прокатилось, обычно старт с router.bittorrent.com:6881 и тому подобных. А если и это почему-то не катит - ну вот тогда запустить закачку с трекера можно, а клиенты до кучи - могут пробовать бутстрапаться и с клиентов: обычно подразумевается что кроме порта TCP на котором торент конект принимает, на равном ему UDP может быть DHT часть, и она могет дать старт. Трекеры и в этом случае - только клиентов накидывают. TCPшных. Которые к DHT сами по себе не относятся - но могут гонять DHT на таком же UDP порту. Технически это по сути 2 разные технологии, почти независимые. DHT для TCP части - типа виртуального трекера, берущего TCP пиров торента "фиг знает откуда". > "ближе"), и на них анонсируется пир (т.е. размещаются внешние ip и > порт, которые поддерживаются "открытыми" например через описанный выше механизм для UDP). Профессор неплохо понял как это работает. Похвально. > А там в качестве идентификатора используется SHA1 хэш публичного ключа ed25519 > и "соли" ("соль" в данном случае - любой небольшой набор байт, > обычно - также хеш чего-нибудь). Данные же вообще могут быть чем > угодно, главное - чтобы размер вписывался в ограничения. В принципе есть даже "dynamic DNS" и тому подобное на основе этого факта. Ну вот такой DNS - лукапают в DHT айпишник - не торента, а - скажем - сервака. И еще ряд использований DHT. Минус у торентового DHT - один. Делан питонистом. Поэтому протокол не удобен ни для машин, ни для человека, ни два ни полтора этакое. Он уже и не особо читаемый, но еще и не особо эффекитвный в парсинге.
	Ответить | Правка | К родителю #109 | Наверх | Cообщить модератору

	171. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от ProfessorNavigator (ok), 01-Окт-24, 11:50
	> В случае DHT никакие трекеры вообще нафиг не уперлись. Хэш лукапается прямо > в распределенной хэштаблице (DHT - distributed hash table). И что там > какие-то трекеры делают - всем пофиг. Да. При условии, что вам известен искомый хеш. > Бутстрапается DHT обычно с "well known" узлов, а то и просто файлика > с долгоиграющими нодами в комплекте. Вон то разве что до кучи. Да. > Более того - поэтому его нереально ТОЧНО измерить.. О том и речь. > И все нормальные клиенты - так и делают. Записывают несколько сотен известных > nodes из своих таблиц в файло - и стартуют с них. > Никакие трекеры и проч при этом нафиг не. Да, я в курсе. > Если это почему-то не прокатилось, обычно старт с router.bittorrent.com:6881 и тому подобных. router.bittorrent.com:6881 последнее время не отзывается, если что. По крайней мере у меня ни на один ping так и не ответил. Похоже заблокировали. Но это так, к слову. Есть и другие. > А если и это почему-то не катит - ну вот тогда запустить > закачку с трекера можно, а клиенты до кучи - могут пробовать > бутстрапаться и с клиентов: обычно подразумевается что кроме порта TCP на > котором торент конект принимает, на равном ему UDP может быть DHT > часть, и она могет дать старт. Трекеры и в этом случае > - только клиентов накидывают. TCPшных. Которые к DHT сами по себе > не относятся - но могут гонять DHT на таком же UDP > порту. Да. Я вообще не уверен, что TCP где-то на практике сейчас в торрентах используется. Потому что все сидят за NAT. А пробивать NAT для p2p TCP соединения - тот ещё фокус. Без гарантии на успех. Насколько мне известно, там сначала отправляется исходящий UDP пакет, потом на тот же порт вешается TCP сокет в режиме listen, в надежде на то, что оппонент пробьётся через NATы. При том, что этот трюк режется на роутерах обычно. UDP p2p соединение куда проще установить. > Профессор неплохо понял как это работает. Похвально. Как писал в другом посте, я просто пару дней назад закончил собственную реализацию DHT сервера - поэтому в курсе, что там и как)) > В принципе есть даже "dynamic DNS" и тому подобное на основе этого > факта. Ну вот такой DNS - лукапают в DHT айпишник - > не торента, а - скажем - сервака. И еще ряд использований > DHT. Да, я в курсе. Я на этом p2p мессенджер написал. > Поэтому протокол не удобен > ни для машин, ни для человека, ни два ни полтора этакое. > Он уже и не особо читаемый, но еще и не особо > эффекитвный в парсинге. Да, так и есть. Лично я бы сделал по-другому. Например что-то типа "1 байт - тип атрибута, 2 байта (big endian - функции htons и ntohs есть сегодня буквально везде) - длина атрибута, атрибут". В принципе - все эти спецификации открыты для всех желающих, можно попробовать внести предложение.
	Ответить | Правка | Наверх | Cообщить модератору

	177. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Аноним (-), 02-Окт-24, 00:20
	> Да. При условии, что вам известен искомый хеш. Для чего-то такого и придуманы magnet-ссылки и тому подобное :) > router.bittorrent.com:6881 последнее время не отзывается, если что. По крайней мере у меня > ни на один ping так и не ответил. Похоже заблокировали. Но > это так, к слову. Есть и другие. Я где-то от него видел ответ, так что вопросы к вашему прову, имхо. Более интересный список well known который тут же кто-то и постил, dht.libtorrent.org:25401, dht.transmissionbt.com:6881, router.bittorrent.com:6881, router.utorrent.com:6881 и dht.aelitis.com:6881 А лично я и как-то пинал бутстрап прям с 1 из своих серваков, где порой до кучи и торенты бывают. Конечно, 100% легальные только, иначе можно и на вынос виртуалки нарваться. > Да. Я вообще не уверен, что TCP где-то на практике сейчас в > торрентах используется. Используется. Местами uTP скажем блочат. Поэтому стандартная логика клиентов это попробовать сперва то, если не прокатило TCP. В трансмишне вообще выбирается - allow uTP или нет. В TCP-only прекрасно все пашет. > Потому что все сидят за NAT. А пробивать NAT для p2p TCP соединения - тот ещё фокус. Это и правда не особо работает, НО сидеры как правило на белом айпишнике с жирным каналом. Для UDP большая часть торентклиентов тоже не заморачивается этим. У uTorrent есть какое-то расширение для этого, НО оно проприетарное и недокументированное толком. Поэтому в клиентах кроме uTorrent этого вроде бы и нет как правило. +1 причина хотеть IPv6 для торента. В v6 много пиров. И конективити шустрая и без всех этих извратов. А с v4 CGN стали нынче прикалываться и могут разным flow разные src ip ставит, так что понятие внешнего айпишника у юзера вообще по сути - отпадает. Очень доставляет потому что например забанить такого юзера по айпи малореально - он все время с разных IP, и надо весь пул ISP накрывать. > успех. Насколько мне известно, там сначала отправляется исходящий UDP пакет, потом > на тот же порт вешается TCP сокет в режиме listen, Вот тут я не в курсе, в обычных торент клиентах так никто не заморачивается. > Как писал в другом посте, я просто пару дней назад закончил собственную > реализацию DHT сервера - поэтому в курсе, что там и как)) Уточнение: в DHT нет "серверов" и "клиентов" как таковых. Там все и вся - node. Это одноранговое взаимодействие by design. Чем оно и круто. Мир без богов и слизняков уповающих на добрую волю первых - намного лучше. > Да, я в курсе. Я на этом p2p мессенджер написал. Хехе, похвально :). Мне впрочем tox понравился - элегантно сделали: ключ DHT шириной в ключ 25519, так что если есть хэш контакта, по сути это уже завершенный D-H exchange, можно с места в карьер шифрование запустить. И DHT примерно аналогично, для бутстрапов надо знать IP:Port:KEY - и с места в варьер можно шифрование поднимать. Если что их DHT ID != long term client ID. Нормальные клиенты берут DHT ID рандомным. Бутстрапы - "well known" на пару с IP:port. Это решение имеет свои особенности... > Да, так и есть. Лично я бы сделал по-другому. Например что-то типа > "1 байт - тип атрибута, 2 байта (big endian - функции > htons и ntohs есть сегодня буквально везде) - длина атрибута, атрибут". На данный момент big endian платформы по сути сдохли, так что это будет ничем не оправданый процессинг на большей части систем. LE таки победил. А у bt протокола и длина по дурацки парсится, из десятичных печатных чисел, так что 123 занимает 3 байта. Хотя влезло бы в 1. При том смысла в этом ноль ибо хеши скажем шлют как есть IIRC - и это уже совсем не читаемо. > В принципе - все эти спецификации открыты для всех желающих, можно > попробовать внести предложение. Сейчас уже поздно это переделывать - кто ж будет переделывать 100500 клиентов?
	Ответить | Правка | Наверх | Cообщить модератору

	183. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от ProfessorNavigator (ok), 02-Окт-24, 13:13
	> Для чего-то такого и придуманы magnet-ссылки и тому подобное :) Да. > Я где-то от него видел ответ, так что вопросы к вашему прову, > имхо. Более интересный список well known который тут же кто-то и > постил, dht.libtorrent.org:25401, dht.transmissionbt.com:6881, router.bittorrent.com:6881, > router.utorrent.com:6881 и dht.aelitis.com:6881 Да, вопросы к провайдеру. Но тут как бы вариантов особых нет - только Ростелеком. Остальные либо хуже по соотношению цена/качество, либо покупают трафик у того же Ростелекома. > А лично я и как-то пинал бутстрап прям с 1 из своих > серваков, где порой до кучи и торенты бывают. Конечно, 100% легальные > только, иначе можно и на вынос виртуалки нарваться. С "белым" ip и широким каналом жить естественно проще, кто ж спорит)) > Используется. Местами uTP скажем блочат. Поэтому стандартная логика клиентов это попробовать > сперва то, если не прокатило TCP. В трансмишне вообще выбирается - > allow uTP или нет. В TCP-only прекрасно все пашет. Если есть сиды с "белым" ip - то естественно проще к ним цепляться по TCP. Но таких обычно немного. > Это и правда не особо работает, НО сидеры как правило на белом > айпишнике с жирным каналом. Для UDP большая часть торентклиентов тоже не > заморачивается этим. У uTorrent есть какое-то расширение для этого, НО оно > проприетарное и недокументированное толком. Поэтому в клиентах кроме uTorrent этого вроде > бы и нет как правило. Да там особо заморачиваться нечего, главное, чтобы исходящие UDP пакеты по времени +/- совпали (в пределах минуты) и адреса/порты правильные были. Могут, конечно, встречаться разные варианты NAT. Но тут любой VPN или proxy поможет. > +1 причина хотеть IPv6 для торента. В v6 много пиров. И конективити > шустрая и без всех этих извратов. А с v4 CGN стали > нынче прикалываться и могут разным flow разные src ip ставит, так > что понятие внешнего айпишника у юзера вообще по сути - отпадает. > Очень доставляет потому что например забанить такого юзера по айпи малореально > - он все время с разных IP, и надо весь пул > ISP накрывать. Да, ipv6 решит множество проблем. Но не хотят. Почему - есть мысли, но достоверно я на самом деле не знаю. Правда, в любом случае ни один из возможных вариантов к положительным не относится)) > Вот тут я не в курсе, в обычных торент клиентах так никто > не заморачивается. Я исходники не смотрел, так что не знаю. Может где и есть. Но, как уже писал, смысла особого нет. UDP канал при отсутствии сидов с "белым" ip пробить куда проще. А эффективность +/- та же будет: ну потеряется пара пакетов, да и интернет с ними - всё равно при получении проверяется хеш загруженной части. Если не совпадёт, пару сотен килобайт перекачать не сложно.   > Уточнение: в DHT нет "серверов" и "клиентов" как таковых. Там все и > вся - node. Это одноранговое взаимодействие by design. Чем оно и > круто. Мир без богов и слизняков уповающих на добрую волю первых > - намного лучше. Под "сервером" в данном случае подразумевается, что реализация может обрабатывать и хранить и "входящие" запросы, вроде анонса пиров или размещения произвольных данных. Можно ведь реализацию написать таким образом, что она будет отправлять только исходящие запросы, а всё остальное - отфутболивать. > Хехе, похвально :). Мне впрочем tox понравился - элегантно сделали: ключ DHT > шириной в ключ 25519, так что если есть хэш контакта, по > сути это уже завершенный D-H exchange, можно с места в карьер > шифрование запустить. И DHT примерно аналогично, для бутстрапов надо знать IP:Port:KEY > - и с места в варьер можно шифрование поднимать. Если что > их DHT ID != long term client ID. Нормальные клиенты берут > DHT ID рандомным. Бутстрапы - "well known" на пару с IP:port. > Это решение имеет свои особенности... Да у меня примерно также всё работает. За тем исключением, что используется торрентовская DHT и свои протоколы передачи и шифрования. Так-то - тоже ed25519 ключи, но используются несколько по-другому. > На данный момент big endian платформы по сути сдохли, так что это > будет ничем не оправданый процессинг на большей части систем. LE таки > победил. Да, но встречаются и разные другие варианты, не только LE. Впрочем - для двух байт никакой разницы нет. Так-то мне тоже кажется более уместным использовать LE. Просто в сети по традиции везде big endian. > А у bt протокола и длина по дурацки парсится, из > десятичных печатных чисел, так что 123 занимает 3 байта. Хотя влезло > бы в 1. При том смысла в этом ноль ибо хеши > скажем шлют как есть IIRC - и это уже совсем не > читаемо. Да. При этом есть ещё и совпадающие ключи. В частности версия ПО - это "1:v", и ключ для обозначения произвольных данных - тоже "1:v". При этом, что одного, что другого может не быть, порядок их появления не гарантирован. Поэтому приходится дополнительно извращаться, чтобы оно всё корректно работало. > Сейчас уже поздно это переделывать - кто ж будет переделывать 100500 клиентов? Так можно же не так в лоб. Предложить, как расширение к уже существующему протоколу. С возможной заменой в будущем и переходным периодом в пару-тройку лет, когда должно поддерживаться и то, и другое.
	Ответить | Правка | Наверх | Cообщить модератору

	189. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Аноним (-), 03-Окт-24, 06:43
	> Да, вопросы к провайдеру. Но тут как бы вариантов особых нет - Я на такое и на виртуалках у хостеров нарывался, есссно не российских. Хрен знает что мрет или блочится, 50/50 работает на некоторые вещи. > С "белым" ip и широким каналом жить естественно проще, кто ж спорит)) Там удобно "initial seeding" своих штук подпирать. Хотя если что-то реально нужное, после отгрузки 2...5 копий - оно потом живет условно-вечно само по себе. До сих пор живы раздачи которые сто лет устарели, на которые я давно забил. А народ всем равно качает. Ну, качают и качают, мало ли у кого какие причуды. > Если есть сиды с "белым" ip - то естественно проще к ним > цепляться по TCP. Но таких обычно немного. Почти все нормальные сидеры делают см выше что... > Да там особо заморачиваться нечего, главное, чтобы исходящие UDP пакеты по времени > +/- совпали (в пределах минуты) и адреса/порты правильные были. Могут, конечно, > встречаться разные варианты NAT. Но тут любой VPN или proxy поможет. Я бы сказал что IPV6 от этого отлично помогает. При том если навтивного нет - накрайняк есть и тунели, типа теред, впнов и проч. Но да, это ессно хуже. > но достоверно я на самом деле не знаю. Правда, в любом > случае ни один из возможных вариантов к положительным не относится)) Кто вас там знает что у вас "положителное". > Но, как уже писал, смысла особого нет. UDP канал при отсутствии > сидов с "белым" ip пробить куда проще. Пробить двойной нат реально только очень хитрой и специфичной процедурой через 3rd party. И вот ЭТО как раз вроде как максимум только сильно некоторые умеют. И даже так дофига допушений о свойствах ната. > же будет: ну потеряется пара пакетов, да и интернет с ними > - всё равно при получении проверяется хеш загруженной части. Если не > совпадёт, пару сотен килобайт перекачать не сложно. В случае uTP это lossless протокол. Он сам перепошлет продолбаное. Это типа фоновой версии TCP, который должен отваливать в туман при нагрузке на канал. > Под "сервером" в данном случае подразумевается, что реализация может обрабатывать и хранить > и "входящие" запросы, вроде анонса пиров или размещения произвольных данных. Без этого оно вообще по сути не есть реализация DHT. Ибо подразумевается что каждый узел умеет и лукапы и хранение. То что к энному их числу запросы не пройдут - да и фиг с ним - отвалятся естественным способом: оно периодически пингует всех кого добавило и если оно не отвечает, бай-бай, более полезными таблицы заполнят. > Можно ведь реализацию написать таким образом, что она будет отправлять только исходящие > запросы, а всё остальное - отфутболивать. Это какая-то ужасная экзотика которая обычно не практикуется. Т.е. нет никакого смысла написать почти всю протокольную логику и зачем-то сам себе подпортить сеть. Впрочем на практике ессно допускать добронамереннность хз кого - такое себе, поэтому раскидывают индекс на N разных, и периодически повторяют это. Некоторые варианты специально де-идеализируют раскидывание и по рандому на чуть менее подходящих фигачат. > Да у меня примерно также всё работает. За тем исключением, что используется > торрентовская DHT и свои протоколы передачи и шифрования. Так-то - тоже > ed25519 ключи, но используются несколько по-другому. У вас DHT шириной 160 битов! Вы в это НИКАК не вгоните 256 бит ключ "direct'ом". Это когда эти байты - одно и то же, 1:1 mapping множеств. Если DHT шириной 256, публичный ключ НАПРЯМУЮ лезет как ID DHT. И кроме всего прочего - "транспортные" коммуникации с ремотой можно шифровать только на основании знания их DHT ID. И еще curve 25519 != ed25519. У вон тех и perfect forward secrecy есть, т.е. почти все пары ключей 25519 - эфемерные и после их уничтожения трафик расшифровке не подлежит в принципе: в нем только пары публичных ключей, а приватные с обоих сторон уже грохнуты и секрета нет ни у той стороны, ни у другой. С другой стороны, явных digital signatures как раз нет - и MITM не может что либо доказать. Кто угодно мог послать траф претендуя что он - некий публичный ключ. Расшифровал ли получатель сие по факту, или там мусор получился - кто ж его знает, кроме получателя?! Однако пока пары ключей еще не грохнуты - системы могут проверить что они те кто заявлены: если некто может зашифровать своим ключем нечто, так что мы расшифровали - окей, это и правда владелец того публичного ключа. В этом смысле хотя там и нет подписей, вклиниться все равно не получится - оно не расшифруется правильно. Т.е. в принципе у господ были достаточно здравые идеи как это делать стоит. > Да, но встречаются и разные другие варианты, не только LE. Впрочем - > для двух байт никакой разницы нет. В случае p2p 2 байта помноженные на дохрена - постепенно таки некую разницу могут и представлять. Хотя портабельный код всяко должен кодировать транспортные сообщения независимо от этого, конечно. > уместным использовать LE. Просто в сети по традиции везде big endian. Эта традиция несколько протухла - и ведет к подгрузке большинства популярных систем нафигнужным байтсвопом. > Да. При этом есть ещё и совпадающие ключи. В частности версия ПО > - это "1:v", и ключ для обозначения произвольных данных - тоже "1:v". Ну вот блин видно - что делано, таки, питонистом. А потом - потом уже поздняк менять было, заставлять всех переписывать кучу клиентов - такое себе, замесят с какахами. > Так можно же не так в лоб. Предложить, как расширение к уже > существующему протоколу. Так блин еще хуже станет - надо парсить и то и другое и будет XKCD#927 во весь рост - теперь вы парсите и то, и это, и багов, глюков и непоняток - в 2 раза больше.
	Ответить | Правка | Наверх | Cообщить модератору

	192. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от ProfessorNavigator (ok), 03-Окт-24, 13:43
	> Я на такое и на виртуалках у хостеров нарывался, есссно не российских. > Хрен знает что мрет или блочится, 50/50 работает на некоторые вещи. Да у нас к сожалению всё так. Собственно оно вон с youtube наглядно видно. Вроде бы никаких официальных документов на его запрет нет. Но тот же Ростелеком  даже не замедляет, а просто наглухо его режет. Официальная причина - кеширующие серверы Гугла не работают в России. Ну, как говорится - ОК, вон некоторые операторы стали ускорять через свои кеширующие серверы. Так на них тут же Роскомнадзор наехал. Хотя опять же, насколько мне известно, никаких официальных документов на этот счёт не существует (не говоря уже о том, что затея сама по себе - квинтэссенция глупости). Ни распоряжений того же Роскомнадзора, ни тем более законов. Т.е. всё по принципу "бояре сказали - холопы должны брать под козырек и выполнять, а не вопросы задавать". Нет, какое-то время оно так может быть даже проработает, но потом все просто начнут выдавальщиков распоряжений по разным непечатным адресам посылать. Оно собственно уже происходит по большому счёту. Но это так, к слову. Всё в общем-то на самом деле идёт, как оно и должно. С учётом действий всех причастных. Другой вопрос, что закончится всё это достаточно печально. Но оно и хорошо. Лучше ужасный конец, чем ужас без конца. > Там удобно "initial seeding" своих штук подпирать. Хотя если что-то реально нужное, > после отгрузки 2...5 копий - оно потом живет условно-вечно само по > себе. До сих пор живы раздачи которые сто лет устарели, на > которые я давно забил. А народ всем равно качает. Ну, качают > и качают, мало ли у кого какие причуды. Если есть сиды, то так оно и будет потихоньку жить. Что в общем и хорошо)) > Почти все нормальные сидеры делают см выше что... По всякому бывает. Я бы тоже в углу серверок поставил коптить потихоньку, благо есть вещи, которые стоит раздавать. Но возможности пока нет. > Я бы сказал что IPV6 от этого отлично помогает. При том если > навтивного нет - накрайняк есть и тунели, типа теред, впнов и > проч. Но да, это ессно хуже. Да. > Кто вас там знает что у вас "положителное". "Положительное" - это когда людям жить нормально не мешают)) Но это уже из области "я за всё хорошее, против всего плохого". Как и написал выше - реальные причины я не знаю, могу лишь предполагать. Но обычно за всем стоят чьи-то корыстные интересы. Например всяким "владельцам авторских прав" и контролёрам жить станет очень некомфортно, если каждый получит возможность подымать у себя дома сервер с прямым выходом в сеть. Или общаться напрямую, минуя централизованные серверы всяких "супер защищённых" мессенджеров (реклама во всех возможных и невозможных местах прилагается). Но это, как уже сказал, лишь мои предположения. > Пробить двойной нат реально только очень хитрой и специфичной процедурой через 3rd > party. И вот ЭТО как раз вроде как максимум только сильно > некоторые умеют. И даже так дофига допушений о свойствах ната. Количество натов в цепочке роли не играет. Имеют значение лишь их свойства. Проблемы может составить только т.н. симметрический нат (если название не путаю). Это когда для любого исходящего пакета, идущего на адрес, отличный от предыдущего, назначается новый порт. Или вообще через другой ip пропускается. Но такие если и есть, то стоят скорее всего в специфических местах, типа шлюзов между внутренней и внешней сетями в богатых корпорациях. Обычные провайдеры с таким заморачиваться не будут - тут сразу и ip телефония во всех мессенджерах отвалится, и геймеры взвоют: и там, и там UDP hole punch используется в полный рост. > В случае uTP это lossless протокол. Он сам перепошлет продолбаное. Это типа > фоновой версии TCP, который должен отваливать в туман при нагрузке на > канал. Да, я знаю. Потому и написал. А также потому, что сам подобное реализовывал, когда мессенджер писал. > Без этого оно вообще по сути не есть реализация DHT. Ибо подразумевается > что каждый узел умеет и лукапы и хранение. То что к > энному их числу запросы не пройдут - да и фиг с > ним - отвалятся естественным способом: оно периодически пингует всех кого добавило > и если оно не отвечает, бай-бай, более полезными таблицы заполнят. Да. Но вон под соседней новостью про qbittorrent товарищ выложил адрес ресурса, который занимается мониторингом DHT на предмет кто и что скачал. Что-то мне сомнительно, что в их реализации оно работает полноценно. Хотя утверждать не возьмусь - не проверял. > Это какая-то ужасная экзотика которая обычно не практикуется. Т.е. нет никакого смысла > написать почти всю протокольную логику и зачем-то сам себе подпортить сеть. Зависит от задач. Возможно у вас цель например отлавливать торрентовиков или затруднить работу DHT. Впрочем, последнее на сегодня уже малореально - слишком много узлов, один "плохой" (да даже и сотня) погоды не сделают. > Впрочем на практике ессно допускать добронамереннность хз кого - такое себе, поэтому > раскидывают индекс на N разных, и периодически повторяют это. Некоторые варианты > специально де-идеализируют раскидывание и по рандому на чуть менее подходящих фигачат. Да. > У вас DHT шириной 160 битов! Вы в это НИКАК не вгоните > 256 бит ключ "direct'ом". Это когда эти байты - одно и > то же, 1:1 mapping множеств. Если DHT шириной 256, публичный ключ > НАПРЯМУЮ лезет как ID DHT. И кроме всего прочего - "транспортные" > коммуникации с ремотой можно шифровать только на основании знания их DHT > ID. Как и сказал, у меня всё работает немного по-другому. А по размерам проблем нет - для этого существуют хеш суммы. Их размер как раз фиксированный, а прохешировать вы можете хоть Войну и мир. > И еще curve 25519 != ed25519. У вон тех и perfect forward > secrecy есть, т.е. почти все пары ключей 25519 - эфемерные и > после их уничтожения трафик расшифровке не подлежит в принципе: в нем > только пары публичных ключей, а приватные с обоих сторон уже грохнуты > и секрета нет ни у той стороны, ни у другой. Разница между этими двумя алгоритмами небольшая и непринципиальная. И ни один не используется для шифрования напрямую, насколько я помню, только для подписывания. Шифрование в данном случае производится через другие алгоритмы, где публичные ключи и shared secrets могут использоваться например в качестве векторов инициализации и паролей. И опять же не напрямую - обычно перед использованием всё хешируется. > С другой стороны, явных digital signatures как раз нет - и MITM > не может что либо доказать. Кто угодно мог послать траф претендуя > что он - некий публичный ключ. Расшифровал ли получатель сие по > факту, или там мусор получился - кто ж его знает, кроме > получателя?! Это работает немного не так. Обычно перед передачей значимой информации вы обмениваетесь одноразовыми публичными ключами, которые действуют только на протяжении этого обмена. Эти ключи могут использоваться как для шифрования симметричными алгоритмами (в паре с shared secrets), так и для подписей. Смотря что требуется. > В случае p2p 2 байта помноженные на дохрена - постепенно таки некую > разницу могут и представлять. Хотя портабельный код всяко должен кодировать транспортные > сообщения независимо от этого, конечно. Речь про то, что кроме little и big endian существуют и другие (почитайте например про историю этого дела на ARM чипах). Но для двух байт это роли не играет, потому что для них существует всего два варианта последовательного расположения. > Эта традиция несколько протухла - и ведет к подгрузке большинства популярных систем > нафигнужным байтсвопом. Да там не такая уж большая нагрузка. Но да, лишние такты процессоров идут, и на больших объёмах это уже становится сильно заметно. Но тут всё ещё сложнее чем с торрентами - торренты по факту нигде официально не стандартизированы, BEP - это просто частная инициатива, да ещё и на программном уровне, где что-то поменять - проблем нет особых. Протокол же ip менять - это менять стандарты на уровне ISO, да ещё и чуть не три четверьти железа на свалку отправлять. Потому что оно много где вшито наглухо, без возможности изменения "в полевых условиях". Тут вон никак на ipv6 перейти толком не могут, хотя стандарт существует с 1996 года, если мне склероз не изменяет. > Ну вот блин видно - что делано, таки, питонистом. А потом - > потом уже поздняк менять было, заставлять всех переписывать кучу клиентов - > такое себе, замесят с какахами. Да нет, поскольку это всё на программном уровне, поменять не особо сложно будет. Да, вонь стоять будет до небес, но так это дело привычное - повоняют пару лет, а потом всё равно перепишут. > Так блин еще хуже станет - надо парсить и то и другое > и будет XKCD#927 во весь рост - теперь вы парсите и > то, и это, и багов, глюков и непоняток - в 2 > раза больше. Ну так это характерно для любых изменений любого протокола. Или API в каких-нибудь библиотеках. И опять же всё зависит от прямоты рук реализаторов.
	Ответить | Правка | Наверх | Cообщить модератору

	197. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Аноним (-), 04-Окт-24, 05:22
	> Да у нас к сожалению всё так. Я не в рф, и виртуалки - на нидерландских и германских хостингах. Может бутстрап ддоснули, мало ли. > Собственно оно вон с youtube наглядно видно. Это видно не только с youtube. Но, увы, тут модеры жестят, может пора сменить площадку где рты не затыкают? > его режет. Официальная причина - кеширующие серверы Гугла не работают в России. Мне тут знакомые хомы расстроеные этим дали доступ к мыльницам с опенврт, через 5 минут экспериментов кеширующие серверы "магически ожили" ;) > Если есть сиды, то так оно и будет потихоньку жить. Что в общем и хорошо)) Они и живут. Хотя зачем кому-то античный опенсорс софт я не понимаю. > По всякому бывает. Я бы тоже в углу серверок поставил коптить потихоньку, > благо есть вещи, которые стоит раздавать. Но возможности пока нет. Я понаставил мелких железок, и на вон те VM они так то изначально грузят зачастую. И мне пофиг сколько сие занимает: это вообще фоновая активность, машины никуда не торопятся. > авторских прав" и контролёрам жить станет очень некомфортно, если каждый получит > возможность подымать у себя дома сервер с прямым выходом в сеть. > Или общаться напрямую, минуя централизованные серверы всяких "супер защищённых" мессенджеров Тотму же tox'у это никак не мешает. Даже через tor пашет, если надо. Хоть и в урезаном режиме. > Количество натов в цепочке роли не играет. Wrong. Когда NAT у только 1 из 2 - проще. > телефония во всех мессенджерах отвалится, и геймеры взвоют: и там, и > там UDP hole punch используется в полный рост. Жирные месенджеры умеют релей через свои сервера накрайняк. Tox впрочем тоже умеет через TCP релеи из самих юзерей (кто разрешил это ессно). > Да. Но вон под соседней новостью про qbittorrent товарищ выложил адрес ресурса, > который занимается мониторингом DHT С учетом что CGN может уже айпи разным flow разный вешать порой - это теряет смысл, там бред. > Зависит от задач. Возможно у вас цель например отлавливать торрентовиков или затруднить > работу DHT. Упомянутое действо противоречит этому goal, опять же. Там вообще выделяться из толпы чревато тем что - и отловят и заблочат и в блеклисты "antip2p" контор определят. > Как и сказал, у меня всё работает немного по-другому. А по размерам > проблем нет - для этого существуют хеш суммы. Их размер как > раз фиксированный, а прохешировать вы можете хоть Войну и мир. Там прелесть в том что хешировать как раз и не надо. Наиболее лобовой immediate mode. Это все упрощает. > Разница между этими двумя алгоритмами небольшая и непринципиальная. В 25519 явных подписей нет, это большое достоинство, "plausible deniability". Кто угодно может кидать такие же на вид пакеты. А расшифровались ли они, или это обмен мусором, никто кроме ремоты не знает. С другой стороны каждая сторона линка может проверить во время сессии что они это они как раз по способности что-то зашифровать. Неявная аутентификация. Не дающая инфо MITM. > И ни один не используется для шифрования напрямую, насколько я помню, > только для подписывания. 25519 это DH такой по сути: secret от cryptobox(our priv, their pub) == secret от cryptobox(their priv, our pub) (с другой стороны линка). С authenticated encryption - можно проверить что расшифровалось ОК. А MITM понятия не имеет - расшифровалось или нет. Ему это не видно. В силу рамезра ключей этот key exchange легко делается по side channel. Ключ tox - уже готовый DH exchange. И добавление DHT включает ключ, IP:port:123456...CDEF. Можно СРАЗУ слать ШИФРОВАНЫЙ мсг узлу. Будучи увереным что это именно он (иначе он это не расшифрует). Достаточно элегантно, относительно просто и относительно эффективно по свойствам. > Это работает немного не так. Обычно перед передачей значимой информации вы обмениваетесь > одноразовыми публичными ключами, Да. Я упростил. Но кроме всего прочего в DHT любой может взять эфемерный ключ, и зашифровать свой пакет -> 1.2.3.4:9876:123456....CDEF, и либо это ОН и у него привкей был, расшифрует, либо impostor в пролете, привкея от 12345...CDEF у него ж нет. Прелесть в том что это "secure DHT": DHT ID узла == его 25519 публичный ключ. Если вы знаете узел, можете секурно коммуницировать с ним. Примерно та же идея и по части Tox ID. Реально сложнее ессно. > с shared secrets), так и для подписей. Смотря что требуется. А зачем мне требуется информировать MITM это я подписью? Вон то "активной аутентификацией" могет проверить что стороны линка такие как пубкеи заявляют (чтобы шифровать с кеем надо приватную половину от него). А mitm понятия не имеет - удалась ли расшифровка. Это иной подход к аутентификации. Впервые вроде OTR идею опробовал. На 25519 это элегантнее делается из-за мелких ключей, которые можно через дупло (SMS, бумажку, QR, ...). Накрайняк 32 байта + немного extras можно с клввы вбить даже. И это готовый DH. > Речь про то, что кроме little и big endian существуют и другие Да это их проблемы так то уже :) > Да там не такая уж большая нагрузка. Но да, лишние такты процессоров > идут, и на больших объёмах это уже становится сильно заметно. Зависит от того кто и что. В роутерах MIPS по этой причине были. Бутстрапы и проч постепенно начинают получать много трафа. > "в полевых условиях". Тут вон никак на ipv6 перейти толком не Я на него уже - от и до. > привычное - повоняют пару лет, а потом всё равно перепишут. Или просто забьют и останется гражданин в чистом поле, автор битторента сам так чуть не лишился контроля, когда uTorrent его обставил. > Ну так это характерно для любых изменений любого протокола. Или API в > каких-нибудь библиотеках. И опять же всё зависит от прямоты рук реализаторов. Просто соотношения в результате - не очень.
	Ответить | Правка | Наверх | Cообщить модератору

	198. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от ProfessorNavigator (ok), 04-Окт-24, 13:23
	> Это видно не только с youtube. Но, увы, тут модеры жестят, может > пора сменить площадку где рты не затыкают? А такие есть?)) Везде +/- одно и то же с вариациями на тему. Тут скорее пора "реконструировать площадку". Пока совсем поздно не стало. > Мне тут знакомые хомы расстроеные этим дали доступ к мыльницам с опенврт, > через 5 минут экспериментов кеширующие серверы "магически ожили" ;) Да я нисколько и не сомневаюсь)) Словосочетание "официальная причина" в данном случае употребляется не зря. Поскольку обычно официально объявляемое в большинстве случаев... немного отличается от того, что есть на самом деле. И не только в РФ, что характерно - оно в общем-то везде так. > Они и живут. Хотя зачем кому-то античный опенсорс софт я не понимаю. Да вы вон по opennet пройдитесь - ретроградов полно. Ну и желзки всякие встречаются. Я своими глазами видел работающие компьютеры под управлением MS-DOS и с живыми floppy дисководами. И не так давно - в 2016 году буквально. > Я понаставил мелких железок, и на вон те VM они так то > изначально грузят зачастую. И мне пофиг сколько сие занимает: это вообще > фоновая активность, машины никуда не торопятся. Так я и говорю - так-то сервер организовать не проблема. Проблема в доступе в интернет, а также в возможных изменениях... локации. Стараюсь пока барахлом не обрастать - есть нехилая вероятность в любой момент сняться с места в режиме "навсегда". > Wrong. Когда NAT у только 1 из 2 - проще. В этом случае проблем вообще 0. Тот, кто с прямым доступом, просто работает в режиме "сервер". > Жирные месенджеры умеют релей через свои сервера накрайняк. Да, но оно накладно. > С учетом что CGN может уже айпи разным flow разный вешать порой > - это теряет смысл, там бред. Да, поставленные задачи оно не особо выполняет. > Там прелесть в том что хешировать как раз и не надо. Наиболее > лобовой immediate mode. Это все упрощает. С одной стороны - да. С другой, DHT сеть для торрентов куда как обширнее, т.е. её для p2p связи использовать лучше. А в ней везде в качестве ID - SHA1 хеши. Узлов tox для бутстрапа тоже хватает, насколько я знаю, но тут ещё другой фактор: заводя узел в DHT сети вы помимо всего прочего способствуете раздачам торрентов. > В 25519 явных подписей нет, это большое достоинство, "plausible deniability". Кто угодно > может кидать такие же на вид пакеты. А расшифровались ли они, > или это обмен мусором, никто кроме ремоты не знает. Так подпись - оно по желанию. Ну и если у вас данные изначально шифрованные (включая подпись), то оно без особой разницы. Просто ещё одна гарантия, что пакет пришёл от того, от кого ожидалось. Я например в новой версии своего мессенджера сделал так, что данные подписываются только при обмене одноразовыми ключами - чтобы точно быть уверенным, что ключ пришёл от того, от кого надо. > С другой стороны каждая сторона линка может проверить во время сессии что > они это они как раз по способности что-то зашифровать. Неявная аутентификация. > Не дающая инфо MITM. Да. У меня оно просто примерно также работает - каждый контакт вешается на свой порт, после чего при расшифровке пакета сверяются ключи: тот что пришёл в пакете, и имеющийся (полученный по другим каналам и использующийся в качестве уникального идентификатора контакта). > Прелесть в том что это "secure DHT": DHT ID узла == его > 25519 публичный ключ. Если вы знаете узел, можете секурно коммуницировать с > ним. Примерно та же идея и по части Tox ID. Реально > сложнее ессно. Да, идея понятна. В этом варианте можно шифровать весь DHT трафик, кроме изначального обмена ключами. У меня это решается несколько по другому: используются DHT mutable items, и само содержимое, помещаемое в DHT, шифруется (да и нет там ничего значимого, только ip адрес). > Я на него уже - от и до. Это вы)) А интернет обширен и разнообразен. > Или просто забьют и останется гражданин в чистом поле, автор битторента сам > так чуть не лишился контроля, когда uTorrent его обставил. Зависит от удобства предложенного нового варианта. > Просто соотношения в результате - не очень. Да по-всякому бывает. Тут просто ещё вопрос в том, что существующие BEP - реально неудобны. Не в плане концепции, а в плане конкретных вещей в протоколе. Т.е. всё равно переделывать рано или поздно придётся. Да и несуразности там попадаются. Например по изначальному протоколу DHT - это один запрос и один ответ (в штуках пакетов UDP). Однако при этом например ограничение для mutable items - 1000 байт. Хотя безопасный размер UDP пакета для передачи через интернет - 508 байт. Всё, что больше - передача не гарантирована, зависит от многих факторов. Но тут, конечно, могу ошибаться.
	Ответить | Правка | Наверх | Cообщить модератору

	36. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Ахахоним (?), 30-Сен-24, 03:02
	Если ничего не качать, то торрент не нужен. Нинужен - так.
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	142. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Аноним (150), 30-Сен-24, 18:14
	Попытался скачать ЮТ и детские книжки дошкольного образования на русском для ребенка, словил вирус. У нас просто запретили на русском. Что тут сказать? Спасибо господа за отключение инета. Хорошо хоть не ограбили. Была бы возможность купить без блокировки денег и проблем с товарищем майором, я бы купил.
	Ответить | Правка | Наверх | Cообщить модератору

	50. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от timur.davletshin (ok), 30-Сен-24, 07:22
	Не знаю, какая причина, но большинство .torrent файлов с rutracker выдают недоступность трекера. Но DHT спасает ситуацию.
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	145. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Аноним (150), 30-Сен-24, 18:23
	Рутрекер за пределами России хорошо работает.
	Ответить | Правка | Наверх | Cообщить модератору

	201. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Аноним (-), 05-Окт-24, 01:45
	> Рутрекер за пределами России хорошо работает. Однако многие торенты - живут дольше чем трекеры в них. Кроме рф трекеры еще гасят и другие копирасы. Так что трекеры довольно лего лишаются домена, хостинга, или просто денег на существование - и бай-бай.
	Ответить | Правка | Наверх | Cообщить модератору

	6. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Аноним (6), 29-Сен-24, 23:46
	Трекеров может быть больше чем один если что.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	9. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+1 +/–
	Сообщение от Аноним (1), 29-Сен-24, 23:51
	Почему-то популярные клиенты так и не догадались добавить список, в который можно поместить всю произвольную тысячу дополнительных ретрекеров (какие-то будут не забанены для одной части пользователей, какие-то для другой).
	Ответить | Правка | Наверх | Cообщить модератору

	11. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+3 +/–
	Сообщение от Аноним (11), 29-Сен-24, 23:57
	В qBittorrent есть возможность поместить все твои трекеры и добавлять к каждой раздаче В некоторых других(Deluge и пр.) это решается через плагины Так что поздравляю, гражданин соврамши
	Ответить | Правка | Наверх | Cообщить модератору

	20. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+2 +/–
	Сообщение от BrainFucker (ok), 30-Сен-24, 00:31
	ЕМНИП в rtorrent была проблема с тем что он выбирал один из трекеров, прописанных в торрент файле и остальные игнорировал, если выбранный отвечает, не отправляя инфу другим трекерам из этого же торрент-файла Таким образом другие пиры, висящие на других трекерах, тебя могут не увидеть. Из-за этого ушёл на Transmission в своё время. Сейчас это всё конечно уже не нужно, качать просто нечего. Да и мне IPFS больше нравится, хоть там и ничего нет.
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	37. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Ахахоним (?), 30-Сен-24, 03:05
	> качать просто нечего Да. Теперь всё есть в пакетном менеджере LFS.
	Ответить | Правка | Наверх | Cообщить модератору

	112. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Аноним (112), 30-Сен-24, 13:31
	Для такого поведения нужно чтобы были активные подключенных пиров для торрента при включенном обмене пирами.
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

23. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+1 +/–
Сообщение от name (??), 30-Сен-24, 00:40
Ура, он живой! Супергодный клиент с красивым tui, всем советую.
Ответить | Правка | Наверх | Cообщить модератору

	26. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	–6 +/–
	Сообщение от Аноним (26), 30-Сен-24, 01:03
	Фигня для пердолинга, в мультиюзер не умеет, сидбокс на нем не построишь, интерфейса нет, апи нет. Ну и зачем?
	Ответить | Правка | Наверх | Cообщить модератору

	27. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от seyko (??), 30-Сен-24, 01:07
	На BitTorrentWeb seed box построить можно?  (не спец в BitTorrent)
	Ответить | Правка | Наверх | Cообщить модератору

	44. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	–1 +/–
	Сообщение от Ivan_83 (ok), 30-Сен-24, 04:17
	ruTorrent же! Там и мультиюзер есть.
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

	62. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+3 +/–
	Сообщение от Аноним (61), 30-Сен-24, 07:54
	>интерфейса нет TUI. Или под интерфейсом понимается исключительно GUI? >апи нет XMLRPC
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

31. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	–2 +/–
Сообщение от Аноним (31), 30-Сен-24, 01:34
aria2c --seed-time=0 'magnet-ссылка' и ничего другого не нужно.
Ответить | Правка | Наверх | Cообщить модератору

32. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
Сообщение от denispopov (?), 30-Сен-24, 02:24
Что он умеет такого чего не умеет qbittorrent-nox? Если ничего то не нужен.
Ответить | Правка | Наверх | Cообщить модератору

40. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
Сообщение от Аноним (40), 30-Сен-24, 03:22
Умеет ли он BEP-55?
Ответить | Правка | Наверх | Cообщить модератору

43. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+1 +/–
Сообщение от Ivan_83 (ok), 30-Сен-24, 04:17
Пользуюсь им уже лет 10-15, совместно с ruTorrent.
Ответить | Правка | Наверх | Cообщить модератору

	52. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+1 +/–
	Сообщение от timur.davletshin (ok), 30-Сен-24, 07:26
	Elementum addon к Kodi просто бомба. Выбираешь фильм, клацаешь, ждёшь секунд 20-30 на первичную буферизацию и смотришь. Все новинки киноиндустрии в одном месте.
	Ответить | Правка | Наверх | Cообщить модератору

	57. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+2 +/–
	Сообщение от ryoken (ok), 30-Сен-24, 07:36
	А шо, щас таки есть что посмотреть и не плеваццо? :)
	Ответить | Правка | Наверх | Cообщить модератору

	58. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+1 +/–
	Сообщение от timur.davletshin (ok), 30-Сен-24, 07:40
	> А шо, щас таки есть что посмотреть и не плеваццо? :) Хотел сам дописать подобное в оригинальном сообщении, но сдержался, ибо вкусовщина. Но вообще упадок, тут ты прав.
	Ответить | Правка | Наверх | Cообщить модератору

	114. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от 12yoexpert (ok), 30-Сен-24, 13:55
	мультики и аниме ещё делают, но фильмов и сериалов без жирных иранок и джинсы уже нет
	Ответить | Правка | Наверх | Cообщить модератору

	69. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Аноним (68), 30-Сен-24, 08:50
	А на раздаче Пушкин стоять будет? Всё жду, когда разработают какой-то способ блокировать такие клиенты.
	Ответить | Правка | К родителю #52 | Наверх | Cообщить модератору

	70. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от timur.davletshin (ok), 30-Сен-24, 08:53
	> А на раздаче Пушкин стоять будет? > Всё жду, когда разработают какой-то способ блокировать такие клиенты. А он на раздаче и стоит... Он всего лишь качает в последовательном порядке.
	Ответить | Правка | Наверх | Cообщить модератору

	74. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Аноним (68), 30-Сен-24, 09:55
	Значит я перепутал с той фигнёй, которая качает торрент с видео, но не сохраняет его после просмотра.
	Ответить | Правка | Наверх | Cообщить модератору

	80. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от timur.davletshin (ok), 30-Сен-24, 10:17
	> Значит я перепутал с той фигнёй, которая качает торрент с видео, но > не сохраняет его после просмотра. Нет, тут тоже такой режим есть. Но его всё же включить надо специально.
	Ответить | Правка | Наверх | Cообщить модератору

	103. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от 1 (??), 30-Сен-24, 11:46
	Вроде как в uTorrent - тоже такой режим есть (попасть в настройки при зажатых Shift+F2)... Но не все форматы "гладко" воспроизводит.
	Ответить | Правка | К родителю #70 | Наверх | Cообщить модератору

	170. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Аноним (51), 01-Окт-24, 09:09
	Чтобы все форматы гладко воспроизводил, нужно «хвост» файла скачивать. В qBittorrent есть такая опция, насчёт uTorrent не знаю, сто лет его не трогад.
	Ответить | Правка | Наверх | Cообщить модератору

	113. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Аноним (75), 30-Сен-24, 13:39
	Ну как, "стоит". На настройках по умолчанию Elementum практически нихрена не раздаёт, а чтобы он раздавал нормально, дешёвой ТВ-коробки будет мало - большинство идёт с 1-2 Гб, чего едва хватает для рамдиска под кэш раздачи и собственно работу всего софта. Я отчасти сидбоксы поднял как раз потому, что меня уже жаба душила за то, что торренты я на телек стримлю, а раздавать не раздаю.
	Ответить | Правка | К родителю #70 | Наверх | Cообщить модератору

	117. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Аноним (51), 30-Сен-24, 15:06
	Ну я, допустим, скачиваю обычным клиентом и останавливаю раздачу, и что ты мне сделаешь?
	Ответить | Правка | К родителю #69 | Наверх | Cообщить модератору

	65. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	–2 +/–
	Сообщение от timur.davletshin (ok), 30-Сен-24, 08:12
	> Пользуюсь им уже лет 10-15, совместно с ruTorrent. Ещё одна проблема bittorrent в нелюбви к IPv6. Вроде как формально она есть, но на практике, если у тебя IPv6 only, то почти ничего ты не скачаешь.
	Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

	111. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от ProfessorNavigator (ok), 30-Сен-24, 13:10
	> Ещё одна проблема bittorrent в нелюбви к IPv6. Вроде как формально она есть, но на практике, если у тебя IPv6 only, то почти ничего ты не скачаешь. Дело не в нелюбви, а в доступности этого самого IPv6. Не знаю, как в других странах, а в РФ мало какие провайдеры выдают IPv6. Соответственно пиров в ipv6 сети немного. Тем более, что торренты качают по большей части на ПК, а IPv6 лично я видел в основном только у мобильных операторов.
	Ответить | Правка | Наверх | Cообщить модератору

	125. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	–1 +/–
	Сообщение от timur.davletshin (ok), 30-Сен-24, 16:58
	> Дело не в нелюбви, а в доступности этого самого IPv6. Не знаю, > как в других странах, а в РФ мало какие провайдеры выдают > IPv6. Уже даже блокировки по IPv6 от РКН завезли, даже Ростелеком префиксы раздаёт, а линуксоиды всё ещё сидят на десктопах с вендой, uTorrent'ом и белым IPv4, как в 2010-ом 😂
	Ответить | Правка | Наверх | Cообщить модератору

	128. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от ProfessorNavigator (ok), 30-Сен-24, 17:12
	> а линуксоиды всё ещё сидят на десктопах с вендой Эм-м... Не понял, а это как?)) Ну и да - белый ip, чтобы торренты качать и раздавать, на самом деле не нужен. Я непосредственно в сам протокол не лазил, только с DHT разбирался. Но насколько мне известно в торрент-клиентах давно уже сделана поддержка UDP. Поэтому вам ни трекер не нужен на самом деле, ни белый ip. DHT + UDP hole punch - и всё работает. Но с ipv6 конечно удобнее.
	Ответить | Правка | Наверх | Cообщить модератору

	131. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от timur.davletshin (ok), 30-Сен-24, 17:40
	> Эм-м... Не понял, а это как?)) Ну и да - белый ip, > чтобы торренты качать и раздавать, на самом деле не нужен. Я > непосредственно в сам протокол не лазил, только с DHT разбирался. Но > насколько мне известно в торрент-клиентах давно уже сделана поддержка UDP. Поэтому > вам ни трекер не нужен на самом деле, ни белый ip. > DHT + UDP hole punch - и всё работает. Но с > ipv6 конечно удобнее. Я вот в соседнем топике писал, что линуксоиды в IPv6 не умеют в своей массе. Простите, а как вам наличие IPv6 адреса поможет раздавать, если на роутерах по умолчанию всё зарезано кроме ICMP и ряда служебных портов? А UDP как поможет? uTP вообще изобретали по другой причине. А ещё многие линуксоиды IPv6 боятся, т.к. думают, что вот он небезопасен и все их службы на локальном компе будут в Интернеты торчать. Сейчас кто-то к моему CUPS на 631 порту цепанётся через этот ваш IPv6 и всё мне тут хакнет через эксплойт 😂 А ещё проффэсор...
	Ответить | Правка | Наверх | Cообщить модератору

	132. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от ProfessorNavigator (ok), 30-Сен-24, 17:56
	> Я вот в соседнем топике писал, что линуксоиды в IPv6 не умеют > в своей массе. Простите, а как вам наличие IPv6 адреса поможет > раздавать, если на роутерах по умолчанию всё зарезано кроме ICMP и > ряда служебных портов? А UDP как поможет? uTP вообще изобретали по > другой причине. А ещё проффэсор ))) Чего?)) Вам не кажется, что у нас странный какой-то разговор получается? Во-первых, не обобщайте за всех линуксоидов. Потому что они разные бывают. И уметь там в ipv6 особо нечего - адрес просто в 4 раза длиннее, остальное +/- то же самое. Во-вторых, включить/отключить что-то на роутере - не проблема вообще. Главное, чтобы провайдер вам выдавал ipv6, остальное - дело техники и прямых рук. UDP мне поможет очень просто - через протокол UDP гораздо проще создавать p2p соединения. Особенно, если у вас доступен только ipv4. И причём тут ICMP вообще? Чем больше умных слов - тем лучше? Вы мысль свою ясно сформулируйте - а то я не пойму, чего вы от меня хотите. И да, я в своё время написал p2p мессенджер, и прямо сейчас работаю над новой его версией. Буквально вчера закончил писать реализацию DHT сервера для него - так что подумайте, прежде чем писать что-то ещё.
	Ответить | Правка | Наверх | Cообщить модератору

	133. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от timur.davletshin (ok), 30-Сен-24, 17:58
	> адрес просто в 4 раза длиннее, остальное +/- то же самое Ну я же говорю, что в IPv6 не умеют местные линуксоиды )))
	Ответить | Правка | Наверх | Cообщить модератору

	134. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от ProfessorNavigator (ok), 30-Сен-24, 18:00
	> Ну я же говорю, что в IPv6 не умеют местные линуксоиды ))) Ну так просветите нас, сирых, да убогих))
	Ответить | Правка | Наверх | Cообщить модератору

	137. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от timur.davletshin (ok), 30-Сен-24, 18:06
	> Ну так просветите нас, сирых, да убогих)) Не-не, вы эти приёмы перекидывания оставьте для студентов. У вас был тезис о том, что "но с ipv6 конечно удобнее". Рассказывайте, как оно помогает с раздачей торрентов. Как порты на роутере там открываются и кем. А потом мы ещё к uTP vs TCP перейдём и расчехлим специалиста.
	Ответить | Правка | Наверх | Cообщить модератору

	143. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Аноним (-), 30-Сен-24, 18:18
	Уменьшает проблемы с NAT.
	Ответить | Правка | Наверх | Cообщить модератору

	144. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от timur.davletshin (ok), 30-Сен-24, 18:21
	> Уменьшает проблемы с NAT. Попрошу подсказочки из аудитории прекратить!
	Ответить | Правка | Наверх | Cообщить модератору

	146. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от ProfessorNavigator (ok), 30-Сен-24, 18:23
	> Не-не, вы эти приёмы перекидывания оставьте для студентов. У вас был тезис > о том, что "но с ipv6 конечно удобнее". Рассказывайте, как оно > помогает с раздачей торрентов. Как порты на роутере там открываются и > кем. Начнём с того - а кем порты закрываются?)) Возможны два варианта: 1) провайдер вам выдаёт диапазон ipv6 адресов для вашего "домашнего" использования, 2) вы получаете один адрес. В первом случае никаких проблем вообще, ваши устройства в рамках выданного количества адресов имеют прямой доступ в сеть. На роутере можно настроить фильтрацию пакетов, чтобы прям голым афедроном в сеть не светить. Но лично я в этом особого смысла не вижу. Во втором случае придётся немного повозиться с настройкой трансляции адресов вашей внутренней сети во внешнюю. А может и нет - зависит от многих факторов. Но да, в таком случае у вас появляется примерно та же проблема, что и с ipv4 - NAT. Решается она относительно просто: в соответствии с протоколом UDP, роутер должен держать зарезервированным за вами порт в течении минуты после отправки исходящего пакета. Если в течение минуты вам прилетит ответка - вы её получите. Если определить ваш внешний порт с помощью например STUN сервера и затем опубликовать его в DHT, то можно установить p2p соединение. Если коротко - то примерно так.
	Ответить | Правка | К родителю #137 | Наверх | Cообщить модератору

	152. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от timur.davletshin (ok), 30-Сен-24, 18:48
	>> Не-не, вы эти приёмы перекидывания оставьте для студентов. У вас был тезис >> о том, что "но с ipv6 конечно удобнее". Рассказывайте, как оно >> помогает с раздачей торрентов. Как порты на роутере там открываются и >> кем. > Возможны два варианта: 1) провайдер вам выдаёт диапазон ipv6 адресов для вашего "домашнего" использования Это называется делегированием префикса. Профессор должен использовать правильную терминологию. Но бог с ним. > 2) вы получаете один адрес. На практике ISP такое практически не используют. > В первом случае никаких проблем вообще, ваше устройства в рамках выданного > количества адресов имеют прямой доступ в сеть. Простите, а что значит "в рамках выданного количества адресов"? А за рамками выданного кол-ва доступ не имеют? Ну чушь же опять несёте. > На роутере можно настроить фильтрацию пакетов, чтобы прям голым афедроном в > сеть не светить. Там уже всё настроено создателями прошивки, чтобы вы никуда ничем не светили. Надо настраивать, чтобы светить. > Во втором случае придётся немного повозиться с настройкой трансляции адресов > вашей внутренней сети во внешнюю. NAT для IPv6 не надо мучить, достаточно прокси настроить, чтобы остальные устройства тоже получали IPv6. В 90% случаев делают так. Какой прокси? Это наводящий вопрос к вам. Вы же там ещё и уточните, прокси он или релей. > Решается она относительно просто: в соответствии с протоколом UDP, роутер должен держать > зарезервированным за вами порт в течении минуты после отправки исходящего пакета. > Если в течение минуты вам прилетит ответка - вы её получите. BEP-55 на самом деле работает немного не так, да и не минута там. Я уже не говорю о том, что не все клиенты его поддерживают. Ну да бог с ним. > ... затем опубликовать его в DHT Чем дальше в лес, тем больше вопросов. Самый главный из них в том, что про то, чем IPv6 проще в данном процессе, вы так и не рассказали. Уходите от ответа. Я, когда студентом был, тоже иногда вместо вопроса из билета рассказывал о том, как подготовка образцов для электронной микроскопии подвела под монастырь американского президента. Даже с вашими коллегами, с профессорами, работало.
	Ответить | Правка | Наверх | Cообщить модератору

	155. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от ProfessorNavigator (ok), 30-Сен-24, 19:40
	> Это называется делегированием префикса. Профессор должен использовать правильную терминологию. > Но бог с ним. Я с терминологией не заморачиваюсь особо  - я не сисадмин ни разу, и ВУЗ заканчивал совсем по другому профилю. Меня больше интересует, как оно на практике работает, каковы принципы действия, чтобы писать программы. Так что - да, в терминах могу ошибаться. Можно, конечно, порыться в сети и найти правильные названия всех протоколов и т.п., но мне, откровенно говоря, лень - для работы оно мне не требуется, а ради вас стараться... Извините, но ваше мнение об мне и моей квалификации меня не особо волнует. Особенно в свете ваших других ответов. > На практике ISP такое практически не используют. Ну не знаю)) Я 2 года жил в одной деревне, в интернет ходил через мобильный модем. И там таки мобильный оператор выдавал ровно один ipv6 адрес, и хоть ты тресни. Дальше, если хочешь, можешь плясать танцы с настройкой. Возможно даже получится. Но я опять же особо не заморачивался - мне ipv6 не особо был нужен, поскольку всё равно ходить с него особо некуда, а торренты качать и вовсе можно было только очень сильно исхитрившись, поскольку оператор пытался всё это дело резать наглухо на уровне протокола. > Простите, а что значит "в рамках выданного количества адресов"? А за рамками > выданного кол-ва доступ не имеют? Ну чушь же опять несёте. И снова вы пытаетесь собеседника оскорбить. Зачем? Мне что, нужно обязательно писать, что да, если у вас устройств больше, чем выданных адресов, то выход есть. Тот самый NAT - настройте его, и будет вам счастье, только чуть медленнее (но не факт). Если, конечно, у вас роутер такое позволяет. На моём например такой фокус проделать не получится - он шибко древний и шибко простой.   > Там уже всё настроено создателями прошивки, чтобы вы никуда ничем не светили. > Надо настраивать, чтобы светить. Это если повезёт. Могут быть разные варианты. > NAT для IPv6 не надо мучить, достаточно прокси настроить, чтобы остальные устройства > тоже получали IPv6. В 90% случаев делают так. Какой прокси? Это > наводящий вопрос к вам. Вы же там ещё и уточните, прокси > он или релей. Вам надо - вы и уточняйте. Мне до лампочки)) И в целом - не говорите мне, что делать, и я не скажу, куда вам пойти. > BEP-55 на самом деле работает немного не так, да и не минута > там. Я уже не говорю о том, что не все клиенты > его поддерживают. Ну да бог с ним. А для DHT оно и не нужно, этот BEP на случай, если вы с помощью трекера соберётесь p2p соединения устанавливать, на сколько я понимаю. И опять же в другом месте я писал - я разбирался только конкретно с BEP относящимся напрямую к DHT, остальные меня не особо интересовали. > Чем дальше в лес, тем больше вопросов. Самый главный из них в > том, что про то, чем IPv6 проще в данном процессе, вы > так и не рассказали. Уходите от ответа. Я, когда студентом был, > тоже иногда вместо вопроса из билета рассказывал о том, как подготовка > образцов для электронной микроскопии подвела под монастырь американского президента. > Даже с вашими коллегами, с профессорами, работало. Проще в том, что если у вас есть ipv6, то вы имеете прямой доступ в сеть. Т.е. вам не надо преодолевать NAT (причём обычно не один, но количество тут особой роли не играет). Публикуете ваш адрес и порт в DHT - и ждёте входящих соединений. Если упрощённо. Или же сами подключаетесь к другим, кто также имеет ipv6 адрес. Нет, реально всё разжёвывать надо? Если да, то так прямо и скажите. А я подумаю, возможно даже найдётся время вас просветить - от этого все выиграют.
	Ответить | Правка | Наверх | Cообщить модератору

	168. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от timur.davletshin (ok), 01-Окт-24, 07:08
	Не распаляйся проффэсор. Я просто расчитывал, что ты, как человек с претензией на обладание научной степени, расскажешь что-то новое. Пересказывать содержание RFC умеют многие. А ты даже 2-3 года в аспирантуре профилонить не осилил.
	Ответить | Правка | К родителю #155 | Наверх | Cообщить модератору

	174. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от ProfessorNavigator (ok), 01-Окт-24, 12:57
	> Не распаляйся проффэсор. Я просто расчитывал, что ты, как человек с претензией > на обладание научной степени, расскажешь что-то новое. Пересказывать содержание RFC умеют > многие. А ты даже 2-3 года в аспирантуре профилонить не осилил. Ключевое здесь "пофилонить". Потому что ничем полезным с учётом состояния российской (да и в целом по миру) науки вы там скорее всего заниматься не будете. Но это отдельный разговор. А по остальному - ну так вот такое вот оно всё скучное, никакой магии, всё работает по RFC и прочим нудным писулькам. Смиритесь - чудес в этом мире не бывает. А если они всё же случаются - то тут нужно на самом деле очень серьёзно пугаться, потому что любое чудо означает ровно одно - вы чего-то сильно неправильно понимаете в законах, по которым работает окружающая вас реальность. А это очень опасно, потому что результат ваших действий - непредсказуемый.
	Ответить | Правка | К родителю #168 | Наверх | Cообщить модератору

	148. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Аноним (104), 30-Сен-24, 18:28
	А просветите меня тоже, я не профессор. > У вас был тезис о том, что "но с ipv6 конечно удобнее". А разве нет? Я знаю, что к IPv6 в современных роутерах прилагается stateful firewall, но ведь по крайней мере нет NAT и не надо адреса транслировать. И нет проблем с потенциальным двойным NAT-ом. Разве это не добавляет удобства? Реализаторам пробивания файрвола, не конечным пользователям, конечно.
	Ответить | Правка | К родителю #137 | Наверх | Cообщить модератору

	135. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	–1 +/–
	Сообщение от timur.davletshin (ok), 30-Сен-24, 18:02
	> И да, я в своё время написал > p2p мессенджер, и прямо сейчас работаю над новой его версией. Буквально > вчера закончил писать реализацию DHT сервера для него - так что > подумайте, прежде чем писать что-то ещё. Для первокурсников эти понты оставьте.
	Ответить | Правка | К родителю #132 | Наверх | Cообщить модератору

	136. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от ProfessorNavigator (ok), 30-Сен-24, 18:04
	> Для первокурсников эти понты оставьте. Ясно, т.е. конструктивного разговора не получится. А жаль. И да, понты здесь ни причём - я просто вам написал, чтобы вы понимали уровень моей квалификации в данном вопросе.
	Ответить | Правка | Наверх | Cообщить модератору

	140. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Аноним (-), 30-Сен-24, 18:09
	Simple GTK 4 based p2p messenger: https://github.com/ProfessorNavigator/communist (сделайте версию для Android, пожалуйста).
	Ответить | Правка | К родителю #135 | Наверх | Cообщить модератору

	172. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от ProfessorNavigator (ok), 01-Окт-24, 12:41
	> Simple GTK 4 based p2p messenger: https://github.com/ProfessorNavigator/communist (сделайте > версию для Android, пожалуйста). Касательно Коммуниста. Прямо сейчас разрабатывается новая версия. С нуля. Интерфейс будет на Qt, поэтому по идее адаптация для Андроида будет вполне возможна. С сетевой частью там вообще проблем быть не должно - препятствие только GUI. Но тут есть нюансы. Я никогда на уровне разработки с Андроидом не сталкивался, нужно разбираться. Потяну ли я это один - не знаю, зависит от объёма работы и наличия у меня времени (желание имеется). В целом на данный момент для новой версии полностью готова p2p часть, возможно ещё что-то подшлифуется в процессе, но не сильно. Также уже есть более-менее готовый для использования GUI, но тут работы ещё много (в том числе с учётом возможной адаптации для Андроида). На днях приступлю к реализации работы в локальных сетях. Если всё будет нормально, то там по моим прикидкам - недели на две с учётом тестирования. Затем планируется добавление полноценной части для работы через централизованный сервер (клиентская и серверная части). Это будет чуть дольше, но не на много скорее всего - на уровне концепции и кое-каких практических наработок уже понятно, что и как делать, осталось только реализовать. После этого планируется добавление групповых чатов и, возможно, каналов по аналогии с Телеграм, только в p2p режиме. После чего - расширение всего этого дела на остальные режимы работы (локальные сети, централизованный сервер). Затем адаптация сетевого стека и GUI для работы в том числе на Windows, и, возможно, на системы семейства *BSD. Примерно такой фронт работ. Хотелось бы ещё добавить стриминговый протокол для аудио и видео звонков, но это уже скорее всего в следующей версии - с сетевой частью там в целом понятно, как и что делать, оно не особо сложно, весь вопрос в записи звука и видео.
	Ответить | Правка | Наверх | Cообщить модератору

	182. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Ivan_83 (ok), 02-Окт-24, 03:23
	Тимур, не хорошо обижать тех кто знает меньше :)))) Для раздачи/качания на роутере без разницы 4 или 6 - у него и 4 будет с большой вероятностью белым. Для внутри локалки 6 - при адекеватных настройках (читай без фильтрации аля NAT) даст возможность прямых входящих подключений. С IPv6 в целом сложнее, я бы сказал что очень трудно всё потому что нет единого манагемент центра, так чтобы одна софтина с вебгуем была которая и 4 и 6 адреса выдаёт всеми способами и в днс регает. И если 4 у меня в днсмаск конфиге маки прибиты к адресам и я знаю как пройти на какой то хост то в6 - полная анархия: оно там какие то адреса получило, нагенерило кучу временных и я вообще хз как до соседнего дома хоста по в6 подключится и какой хост на каком адресе. К этому всему ещё добавляется низкая культура понимания принципов фаерволинга, да и в принципе концептуально не всегда легко определится с тем какую чусть в6 трафика втнурь сети пропускать без фильтрации.
	Ответить | Правка | К родителю #131 | Наверх | Cообщить модератору

	166. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Аноним (-), 01-Окт-24, 04:12
	> вам ни трекер не нужен на самом деле, ни белый ip. > DHT + UDP hole punch - и всё работает. Но с > ipv6 конечно удобнее. Не просто удобнее - но и полноценнее. Скажем к вам без белого IP новый клиент не сконектится. И вы к нему - тоже. И возможна ситуация когда "девочка от девочки не беременеет" особенно пока стая мелкая. И будете вот так вот пытаться что-то изобразить до упора...
	Ответить | Правка | К родителю #128 | Наверх | Cообщить модератору

	173. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от ProfessorNavigator (ok), 01-Окт-24, 12:48
	> Не просто удобнее - но и полноценнее. Скажем к вам без белого > IP новый клиент не сконектится. И вы к нему - тоже. Тут возможны варианты - DHT собственно в том числе для этого и изобрели, чтобы подключаться без "белого" ip. Но да, p2p соединение через NAT - то ещё удовольствие. И без помощи внешнего сервера в любом случае невозможно. > И возможна ситуация когда "девочка от девочки не беременеет" особенно пока > стая мелкая. И будете вот так вот пытаться что-то изобразить до > упора... Да, такое есть.
	Ответить | Правка | Наверх | Cообщить модератору

	178. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Аноним (164), 02-Окт-24, 00:31
	> Тут возможны варианты - DHT собственно в том числе для этого и > изобрели, чтобы подключаться без "белого" ip. WRONG! Его изобрели - чтобы можно было раздавать торенты без всяких трекеров. Там еще есть небольшой довесок протокола - "metadata xfer". Зная инфохэш с тех кто понимает сие можно получить сначала торентфайл, прочекать что его инфохэш и правда такой (так что левак в критичных частях ремота впарить не сможет по простому) и потом качать как обычно уже. Оттуда же и наезды на трансмишн что он видите ли не дает файло выбрать. А этого инфо в магните нет, это надо даунлоад начать, получить метаданные, и потом уже можно выбирать будет. С этой технологией - сервера не нужны. Ни трекеры, ни что там еще. Достаточно на самом деле знать только инфохэш. Некоторые клиенты типа transmission кроме magnet ссылки могут и просто хэш сожрать. > Но да, p2p соединение через NAT - то ещё удовольствие. И без помощи внешнего сервера в > любом случае невозможно. Этим "сервером" могут быть и сами клиенты как таковые. Ну да, соседние. В tox это красиво обыграли. Там желающие могут даже TCP-relay разрешить если у них трафа завались. Бутстрапы так по дефолту делают обычно (при душняке с трафом бутстрапы не ставят). > Да, такое есть. Ну врт бывает. В этом смысле IPv6 торентовщикам друг и товарищ. И вообще-то его уже завались. У меня иной раз в торентах v6 больше чем v4 качают уже.
	Ответить | Правка | Наверх | Cообщить модератору

	185. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от ProfessorNavigator (ok), 02-Окт-24, 14:02
	> WRONG! Его изобрели - чтобы можно было раздавать торенты без всяких трекеров. > Там еще есть небольшой довесок протокола - "metadata xfer". Зная инфохэш > с тех кто понимает сие можно получить сначала торентфайл, прочекать что > его инфохэш и правда такой (так что левак в критичных частях > ремота впарить не сможет по простому) и потом качать как обычно > уже. Оттуда же и наезды на трансмишн что он видите ли > не дает файло выбрать. А этого инфо в магните нет, это > надо даунлоад начать, получить метаданные, и потом уже можно выбирать будет. Ну собственно трекер вам и нужен в основном для того, чтобы установить p2p соединение. Посредник, обмен адресами и всё такое. DHT его просто заменяет. А так - я в курсе, как это работает (можете почитать другие мои комментарии здесь же). > С этой технологией - сервера не нужны. Ни трекеры, ни что там > еще. Достаточно на самом деле знать только инфохэш. Некоторые клиенты типа > transmission кроме magnet ссылки могут и просто хэш сожрать. Да, я в курсе. > Этим "сервером" могут быть и сами клиенты как таковые. Ну да, соседние. > В tox это красиво обыграли. Там желающие могут даже TCP-relay разрешить > если у них трафа завались. Бутстрапы так по дефолту делают обычно > (при душняке с трафом бутстрапы не ставят). Не только в tox)) > Ну врт бывает. В этом смысле IPv6 торентовщикам друг и товарищ. И > вообще-то его уже завались. У меня иной раз в торентах v6 > больше чем v4 качают уже. Вам повезло. У меня провайдер выдавать ipv6 сам не хочет, а ругаться с ним - не настолько оно пока надо. Впрочем, жизнь меняется. Всякие *надзоры со своим тупизмом уже откровенно доставать начинают, так что в скором времени весьма вероятно придётся переезжать целиком в сегмент p2p. А в этом варианте с ipv6 куда проще.
	Ответить | Правка | Наверх | Cообщить модератору

	186. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Аноним (-), 03-Окт-24, 05:52
	> Ну собственно трекер вам и нужен в основном для того, чтобы установить > p2p соединение. Посредник, обмен адресами и всё такое. Трекер нужен чтобы знать - у кого вообще есть такой же торрент. DHT изначально решает ту же самую задачу, только делая вместо запроса в центральный ауторити - распределенный лукап. DHT это распределенный индекс, типа кусочков B-дерева раскиданых по разным участникам. Все остальное опционально, до кучи, и в случае торента сильно варьируется. > DHT его просто заменяет. А так - я в курсе, как это работает (можете > почитать другие мои комментарии здесь же). Его первичная функция это индекс. Все что сверх того - до кучи и очень опционально. >> если у них трафа завались. Бутстрапы так по дефолту делают обычно >> (при душняке с трафом бутстрапы не ставят). > Не только в tox)) Ну я как бы так сходу не назову иныз DHT систем готовых нашару как TCP-relay работать для других в наиболее душном случае. Господа увлекались скайпом и это ну вот что-то типа супернод по смыслу в таком обвесе. На самом деле конфигуряется, разрешать сие или нет. >> У меня иной раз в торентах v6 больше чем v4 качают уже. > Вам повезло. У меня провайдер выдавать ipv6 сам не хочет, а ругаться > с ним - не настолько оно пока надо. Ну я тут не виноват. IPv6 вообще в целом штука популярная уже довольно. Душняк с v4 дошел до того что CGN наты делают жесточайшую фигню уже, размазывая 1 юзера по эн айпи пула, видимо портов не хватает на все оказии конкретному юзеру гарантированно отдавать. > Всякие *надзоры со своим тупизмом уже откровенно доставать начинают, так что > в скором времени весьма вероятно придётся переезжать целиком в сегмент p2p. > А в этом варианте с ipv6 куда проще. Вообще переезжать надо - в другую страну скорее. Но там тоже есть любители указывать что хорошо и плохо, типа MAFIAA всяких.
	Ответить | Правка | Наверх | Cообщить модератору

	191. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от ProfessorNavigator (ok), 03-Окт-24, 12:16
	> Трекер нужен чтобы знать - у кого вообще есть такой же торрент. > DHT изначально решает ту же самую задачу, только делая вместо запроса > в центральный ауторити - распределенный лукап. > DHT это распределенный индекс, типа кусочков B-дерева раскиданых по разным участникам. > Все остальное опционально, до кучи, и в случае торента сильно варьируется. > Его первичная функция это индекс. Все что сверх того - до кучи > и очень опционально. Как уже написал - я в курсе, как это работает)) > Ну я как бы так сходу не назову иныз DHT систем готовых > нашару как TCP-relay работать для других в наиболее душном случае. Господа > увлекались скайпом и это ну вот что-то типа супернод по смыслу > в таком обвесе. На самом деле конфигуряется, разрешать сие или нет. В Communist это тоже есть))   > Душняк с v4 дошел до того что CGN наты делают > жесточайшую фигню уже, размазывая 1 юзера по эн айпи пула, видимо > портов не хватает на все оказии конкретному юзеру гарантированно отдавать. Дело не в портах скорее всего, а в мобильных операторах. Владелец телефона/планшета перемещается, поэтому его периодически с вышки на вышку перебрасывает, соответственно цепочка роутеров для выхода в "большой" интернет меняется. Или просто сигнал плохой на границе зон обслуживания разных вышек, и пользователя кидает с одной на другую. Или на вышке большая нагрузка, и часть пользователей автоматом выкидывает на другую (в какой-нибудь Москве например). Поэтому ip и меняется постоянно. > Вообще переезжать надо - в другую страну скорее. Но там тоже есть > любители указывать что хорошо и плохо, типа MAFIAA всяких. Оно везде +/- одинаково, поэтому *надзоры со звёздочкой. И переезд тут не поможет. Потому что проблемы опять же +/- одинаковые везде - это просто кризис общественно-экономической системы в частности и развития общества в целом. Такие вещи решаются совсем другими методами.
	Ответить | Правка | Наверх | Cообщить модератору

	181. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Ivan_83 (ok), 02-Окт-24, 03:13
	Что ж вы за люди то такие, ничем не интересуетесь, всё вам должны принести готовое. Для того чтобы иметь IPv6 уже 15 лет как достаточно иметь IPv4 интернет и желание, и желательно белый IPv4, можно динамический. Хуриката электрик очень давно осчастливливает всех желающих, да и другие есть. У нас дома IPv6 так и появился, и наши подсети с нами при всех переездах. Из не удобств в последний год сети HE стал банить гугол, пришлось на unbound покрутить чтобы отдельные домены только по IPv4 были. OpenAI туда же подался.
	Ответить | Правка | К родителю #111 | Наверх | Cообщить модератору

	184. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от ProfessorNavigator (ok), 02-Окт-24, 13:47
	> Что ж вы за люди то такие, ничем не интересуетесь, всё вам > должны принести готовое. А вы уверены, что я (и не только я) про что-то не в курсе?)) Если человек чего-то не делает, это совершенно не означает, что человек чего-то не умеет или не знает. Может быть вариант, что как раз знает, и очень хорошо, поэтому и не делает. Например. Или ещё 1001 причина, вроде принципов. Это вам к размышлению. > Для того чтобы иметь IPv6 уже 15 лет как достаточно иметь IPv4 > интернет и желание, и желательно белый IPv4, можно динамический. > Хуриката электрик очень давно осчастливливает всех желающих, да и другие есть. > У нас дома IPv6 так и появился, и наши подсети с нами > при всех переездах. > Из не удобств в последний год сети HE стал банить гугол, пришлось > на unbound покрутить чтобы отдельные домены только по IPv4 были. OpenAI > туда же подался. Т.е. вы передаёте свои данные через некий левый сервер-транслятор, принадлежащий непонятно кому, и при этом не видите в этом проблемы? Ну, как говорится - OK. Видимо, у нас с вами сильно разный жизненный опыт. Я даже завидую: мне на моём пути, получается, встречалось сильно меньше бескорыстных и честных людей.
	Ответить | Правка | Наверх | Cообщить модератору

	203. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Ivan_83 (ok), 05-Окт-24, 05:28
	В HE уходит сильно меньше "телеметрии" чем от людей которые использую 8.8.8.8 и прочие "облакастые ДНС" сервера. В основном в HE уходит траффик который и так предназначен для компаний на территории АНБ, а то и прямо под его крышей. Нет, я не вижу в этом большой проблемы, потому что это выборочный траффик и потому что его анализ даёт не так уж много информации обо мне. Кроме того сервис не массовый и даже фриковский, в аналитику там вряд ли кто то сильно вкладывался. Вот забрать себе весь клиентский ДНС это значит прям в реалтайме знать всё что происходит на хосте такой жертвы безопасности, притом знать зачастую больше чем хозяин хоста.
	Ответить | Правка | Наверх | Cообщить модератору

	123. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от ryoken (ok), 30-Сен-24, 16:44
	> Ещё одна проблема bittorrent в нелюбви к IPv6. Вроде как формально она > есть, но на практике, если у тебя IPv6 only, то почти > ничего ты не скачаешь. Это где ж жить-то надо... Какой-то вариант IPv6 на роутер дома приезжает, только не понятно какой - то ли от прова, то ли то что я натыкал в настройках OpenWRT...
	Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

87. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
Сообщение от Аноним (31), 30-Сен-24, 10:46
Usage: aria2c --seed-time=0 'магнет_ссылка'
Ответить | Правка | Наверх | Cообщить модератору

	90. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	–1 +/–
	Сообщение от Аноним (31), 30-Сен-24, 10:58
	Урра. Попробовал, понял, что aria2c лучше других торрент-клиентов, особенно когда нужно просто скачать и не стоять на раздаче, убивая свои диски.
	Ответить | Правка | Наверх | Cообщить модератору

	92. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Аноним (31), 30-Сен-24, 11:07
	Пользуйся на здоровье! Есть еще вариант использования aria2c, совместно с yt-dlp, для закачки видео с Ютуба, но я его применяю, только когда yt-dlp медленно качает.
	Ответить | Правка | Наверх | Cообщить модератору

	97. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+1 +/–
	Сообщение от Аноним (1), 30-Сен-24, 11:21
	Вполне норм в целом, но в rpc режиме не идеально (не закрывается по завершении, надо команду отправлять). А так, используй вот это, работает с локальными торрентами, удалёнными торрентами, магнит ссылками (попроси чатгпт запилить .desktop файл для протокола чтобы запускать кликом в браузере, он умеет), скачивает начало и конец файла сразу (вроде есть последовательная закачка блоков, но не проверял). aria2c --disable-ipv6=true --bt-max-peers=150 --bt-max-open-files=1000 --file-allocation=falloc --min-tls-version=TLSv1.3 --bt-save-metadata=false --bt-request-peer-speed-limit=500K --bt-force-encryption=true --bt-min-crypto-level=arc4 --bt-require-crypto=true --bt-prioritize-piece=head=100M,tail=50M --bt-stop-timeout=180 --bt-tracker-connect-timeout=15 --bt-tracker="${TRACKERLIST}" --seed-time=0 --enable-dht=true "${link}" Если не смог скачать, продолжить можно, скормив магнит, полученный из .aria2 файла (aria2_to_magnet.py или напиши однострочник на шелле).
	Ответить | Правка | К родителю #90 | Наверх | Cообщить модератору

	187. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Аноним (-), 03-Окт-24, 05:59
	> aria2c --disable-ipv6=true --bt-max-peers=150 --bt-max-open-files=1000 --file-allocation=falloc > --min-tls-version=TLSv1.3 --bt-save-metadata=false --bt-request-peer-speed-limit=500K > --bt-force-encryption=true --bt-min-crypto-level=arc4 --bt-require-crypto=true > --bt-prioritize-piece=head=100M,tail=50M --bt-stop-timeout=180 --bt-tracker-connect-timeout=15 > --bt-tracker="${TRACKERLIST}" --seed-time=0 --enable-dht=true "${link}" Какое-то совершенно бессмысленное шит-комбо. 1) С одной стороны зачем-то IPV6 гасит. Наверное чтобы торент медленнее качался, без входящих пиров то. 2) Число пиров надо ставить в зависимости от умений своего роутера и RAM на нем. Если ее дофига - то много. Если нифига - то мало. Иначе контрек забьет. 3) Форс крипто штука конечно полезная, но дополнительно нагнет закачки в добавок к пункту 1. Так что скачать редкий торент...эээ... 4) Зачем торенту с магнита TLS вперся хрен его знает. Вы что, еще и на трекеры лазите? И в результате - пойнт такого сетава в чем? Обломать себе скачку редких торентов, не забыв отзвонить на все трекеры что вы качали, чтоб майор уж точно был в курсах? :) > Если не смог скачать, продолжить можно, скормив магнит, полученный из .aria2 файла > (aria2_to_magnet.py или напиши однострочник на шелле). Ария сама умеет качать - по магнитам, внезапно. Можно по списку магнитов даже. И кстати не так уж плохо сидит - я так смотрю их на раздаче поприбавилось.
	Ответить | Правка | Наверх | Cообщить модератору

	190. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Аноним (1), 03-Окт-24, 07:44
	1 _абсолютно_ пустая трата ресурсов 2 это стандартное ограничение, можно оценить на чём-то особо популярном вроде новой убунты 3 фильтрует фейковые клиенты и только 4 ты вообще не понял, в чём дело, магнита у тебя может и не быть изначально и уж точно он нигде не записан. И это вообще не торрент клиент, программа запускается по клику в браузере и tls13 необходим для dpi (хотя где-то и обламается). На трекеры плевать, dht всё равно совершенно публичная и задача трекеров только ускорить возможное нахождение пиров. Нет так нет. Задачи не сидить не стояло, была задача обломать пиявок и не тратить реурсы сверх необходимого -- исходящий трафик у неё всегда лучше, чем у клиентов с сотнями торрентов. С недостатками можно столкнуться, если запихать в неё эти сотни, тут всё довольно печально.
	Ответить | Правка | Наверх | Cообщить модератору

	194. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Аноним (-), 03-Окт-24, 21:54
	> 1 _абсолютно_ пустая трата ресурсов У меня примерно 50% трафа торента - по IPv6 уже. Роутер грузит меньше, входящие проходят, нифига себе "пустая трата". И там часто жирные клиенты с толстым каналом которые потом сидируют в 10 раз круч меня. > 2 это стандартное ограничение, можно оценить на чём-то особо популярном вроде новой убунты Как я уже сказал в торентах нет "one size that fits all" в этом смысле и сие сильно зависит от жирности канала и возможностей контрека. А, да, на v6 контрек как таковой - не вперся. > 3 фильтрует фейковые клиенты и только А заодно и всяких некрофилов с черти какими клиентами, что для редких раздач порой икается. > 4 ты вообще не понял, в чём дело, магнита у тебя может > и не быть изначально Ну, у меня либо магнит, либо торентфайл есть. А для лукапа в DHT нужен так то - инфохэш, если что. Он и так есть, и сяк. Где я торент или магнит взял - вопрос номер два. К самому процессу скачки это уже ортогонально как таковое, как бы мегаодмины не пытались доказать обратное. > И это вообще не торрент клиент, программа запускается по клику в > браузере и tls13 необходим для dpi (хотя где-то и обламается). В протоколе торента - нету TLS нигде. И самый максимум - какие-то запросы для трекеров, вот. Я и не понимаю - для кого вы TLS в торентах декларите? :) > На трекеры плевать, dht всё равно совершенно публичная и задача трекеров только > ускорить возможное нахождение пиров. Судя по потугам с рейтингом - админы оных воообразили себе немного другое. Ессно существование вещей типа DHT с 1 стороны и люлей правоохранителей с другой немного поправили им вывихнутые мозги. > стояло, была задача обломать пиявок и не тратить реурсы сверх необходимого Это вообще by design сделано в логике торента: клиенты льют прежле всего тем кто льет им. Так что личер в стае - сервируется по остаточному принципу, продвигаются кооперативные клиенты. Так что личер наказывает сеебя сам, получая наиболее хреновую скорость из возможных. Те кто качает файло - предпочитают слать более кооперативным коллегам, и только.
	Ответить | Правка | Наверх | Cообщить модератору

101. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+1 +/–
Сообщение от Аноним (101), 30-Сен-24, 11:34
Ребят, подскажите, как сейчас качать торренты через мобильный интернет? ВПН нужен? Спасибо заранее.
Ответить | Правка | Наверх | Cообщить модератору

	118. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Аноним (51), 30-Сен-24, 15:09
	Я качал через тор. Но: через тор нельзя качать по magnet-ссылкам. А VPN по-любому нужен, так или иначе.
	Ответить | Правка | Наверх | Cообщить модератору

	127. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Аноним (-), 30-Сен-24, 17:09
	У меня работает LibreTorrent с требованием шифрования входящих и исходящих соединений, без VPN. Только проверьте, чтобы в APN смартфона было включено IPv4/IPv6.
	Ответить | Правка | К родителю #101 | Наверх | Cообщить модератору

	158. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от name (??), 30-Сен-24, 21:03
	Tribler, например. Или как-то изменить пакеты, чтобы получатель их понимал, а dpi нет.
	Ответить | Правка | К родителю #101 | Наверх | Cообщить модератору

107. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
Сообщение от Аноним (104), 30-Сен-24, 12:24
Помнится, у этого rtorrent было 12-кратное I/O multiplication. Интересно, исправили ли.
Ответить | Правка | Наверх | Cообщить модератору

	161. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Ivan_83 (ok), 30-Сен-24, 23:11
	Сомнительно что было. Сколько им пользуюсь - он всегда (лет 10 точно) использовал mmap() для чтения/записи файлов, теоритически это сокращает количество копирований юзерспейс-ядро как минимум на одно.
	Ответить | Правка | Наверх | Cообщить модератору

	162. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Аноним (104), 30-Сен-24, 23:25
	Под I/O мультипликацией имеется в виду не в копирование из юзерспейса в ядро, а копирование с диска в память. И вот этот самый mmap(), по тогдашним сообщениям, считывал слишком много с диска, типа prefetch, read ahead, кэширование и всё такое. Вот до 12 раз больше, чем надо. А файлы, раздающиеся через торрент, раздаются случайными кусками, то есть этот read ahead далеко не всегда нужен. И поэтому этот read ahead лучше контролировать торрент-клиентом, а не встроенными механизмами glibc или ядра. И я не знаю, насколько сильно read ahead можно контролировать при чтении через mmap(), и при чтении через обычный read(), но по идее через read() контроля больше, потому что read() - более простая операция чем mmap(). Вот как-то так.
	Ответить | Правка | Наверх | Cообщить модератору

	163. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Ivan_83 (ok), 01-Окт-24, 02:00
	Для read ahead во фре есть sysctl крутилки, полагаю в линухе они тоже должны быть. Но как правило там не сильно больше 64кб, притом что чанки в торренте бывают и по паре мегабайт. И rtorrent мапал не весь файл (так никакой памяти не хватит) а нужные куски.
	Ответить | Правка | Наверх | Cообщить модератору

	167. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Аноним (-), 01-Окт-24, 04:14
	> Для read ahead во фре есть sysctl крутилки, полагаю в линухе они > тоже должны быть. У торент клиентов часто есть 1) Свой кэш в RAM ибо клиент лучше знает что ему надо следующее. Видит по запросам от ремот что они хотят за вот этим блоком. 2) Свой префетч этого кеша по той же причине. 3) Direct IO чтобы не вымывать этим хламом системный кеш почем зря, убивая остальное IO.
	Ответить | Правка | Наверх | Cообщить модератору

	179. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Ivan_83 (ok), 02-Окт-24, 02:38
	Это всё хорошо, но вполне можно обойтись и тем что есть в системе не реализуя это у себя в коде. Клиент не знает какой следующий блок попросят отправить. Единственное что клиент знает - это при скачивании как лучше организовать запись. И при отдаче иногда знает что больше данные очень долго не потребуются. Всё это не сказать чтобы требовало самостоятельной реализации, и механизмы сообщать ОС желаемое в принципе есть.
	Ответить | Правка | Наверх | Cообщить модератору

	188. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Аноним (188), 03-Окт-24, 06:08
	> Это всё хорошо, но вполне можно обойтись и тем что есть в > системе не реализуя это у себя в коде. Система в дуще не ... какие следующие части запросил ремотный пир и что вы намерены качать дальше. А торрент клиент - вполне. Там нехилые "окна" запросов, так что кастомный префетч многократно эффективнее системного кеша. Торент клиент грубо выносит системный кеш - бессмысленно и беспощадно убивая перфоманс иного IO. Ибо пытаться кешировать то что выглядит как куча рандомных запросов - такое себе. То что они на самом деле не совсем рандомные только торент клиент и знает. > Клиент не знает какой следующий блок попросят отправить. Вообще-то там нехилое окно запросов субблоков насколько я знаю - и по нему таки возможен довольно большой и адресный пребуфер. А система ессно это все - не видит. Для нее это куча рандомных запросов (на разных пиров). Умный клиент однако читает относительно большие сегменты, последовательно, на основе вон тех данных. Это сильно разгружает IO особенно на механике. > Единственное что клиент знает - это при скачивании как лучше организовать запись. Да он с чтением может быть более адресным. Система будет тупо префетчить N. Независимо от того - просила ли ремота это, или ушла в другой блок. Это почем зря подгрузит IO и вымоет кеш лишний раз. > И при отдаче иногда знает что больше данные очень долго не потребуются. Ну да. Скажем режим супер-сидера когда пытается раздать 1 копию на разных рож - а дальше они пусть сами. > Всё это не сказать чтобы требовало самостоятельной реализации, и механизмы сообщать ОС > желаемое в принципе есть. Эти механизмы никогда не делались под такой хардкор. Поэтому нормальные клиенты предпочитают отращивать свою task specific реализацию, чтобы IO не насиловать и не вымывать системные кеши ударными темпами. Ибо если у вас от этого скажем оглавление разлапистых дир постоянно будет вылетать - это таки будет бесить. А с direct IO + свой контролируемый буфер оно вообще ЭТО из памяти не выносит. Не его епархия, direct IO мимо этого идет.
	Ответить | Правка | Наверх | Cообщить модератору

	204. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Ivan_83 (ok), 05-Окт-24, 05:34
	nginx как то умеет файлы отдавать кусками без вот этого всего дублирования у себя в коде и на перформанс никто не жалуется. Да и в целом даже отдача кучи мелких файлов по сути не сильно отличается от раздачи кусков из одного файла для кеша ФС. Так что нет, практика показывает что без вот этого всего используя штатные механизмы ОС можно вполне годно работать. direct IO и вот это всё часто БД юзают, но у них там свои особенности с частой записью в одни и теже места.
	Ответить | Правка | Наверх | Cообщить модератору

	176. "После пятилетнего перерыва выпущен BitTorrent-клиент rTorren..."	+/–
	Сообщение от Аноним (104), 01-Окт-24, 19:58
	Вот, баг-репорт по проблеме нашёл: https://github.com/rakshasa/rtorrent/issues/443 Там жалуются на меньшую мультипликацию, чем 12х, "всего" на 4х-6х-8х, но всё равно проблема есть.
	Ответить | Правка | К родителю #162 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема