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

"После пятилетнего перерыва выпущен 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. Сообщение от Аноним (1), 29-Сен-24, 23:22    Скрыто ботом-модератором	–26 +/–
Помню, всегда отвратно (не)работал, так и не написали нормального клиента за 20+ лет, хотя казалось бы. Мюторрент хоть и проприетарь, вообще ни разу проблем не создавал (2ка), да и по ресурсам намного лучше был (с протоколом правда тоже были вопросы).
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #3, #8, #16, #45, #76, #130

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

97. Сообщение от Аноним (1), 30-Сен-24, 11:21	+1 +/–
Вполне норм в целом, но в 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 или напиши однострочник на шелле).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90 Ответы: #187

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

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

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

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

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

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

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

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

109. Сообщение от ProfessorNavigator (ok), 30-Сен-24, 13:04	+2 +/–
> 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 и "соли" ("соль" в данном случае - любой небольшой набор байт, обычно - также хеш чего-нибудь). Данные же вообще могут быть чем угодно, главное - чтобы размер вписывался в ограничения.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #139, #151, #165

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

131. Сообщение от 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ообщить модератору
Родитель: #128 Ответы: #132, #182

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

155. Сообщение от 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ообщить модератору
Родитель: #152 Ответы: #168

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

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

159. Сообщение от 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ообщить модератору
Родитель: #157 Ответы: #169

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

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

162. Сообщение от Аноним (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ообщить модератору
Родитель: #161 Ответы: #163, #176

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

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

165. Сообщение от Аноним (-), 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 - один. Делан питонистом. Поэтому протокол не удобен ни для машин, ни для человека, ни два ни полтора этакое. Он уже и не особо читаемый, но еще и не особо эффекитвный в парсинге.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #109 Ответы: #171

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

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

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

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

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

171. Сообщение от 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ообщить модератору
Родитель: #165 Ответы: #177

172. Сообщение от 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ообщить модератору
Родитель: #140

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

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

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

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

177. Сообщение от Аноним (-), 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ообщить модератору
Родитель: #171 Ответы: #183

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

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

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

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

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

183. Сообщение от 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ообщить модератору
Родитель: #177 Ответы: #189

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

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

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

187. Сообщение от Аноним (-), 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ообщить модератору
Родитель: #97 Ответы: #190

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

189. Сообщение от Аноним (-), 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ообщить модератору
Родитель: #183 Ответы: #192

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

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

192. Сообщение от 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ообщить модератору
Родитель: #189 Ответы: #197

194. Сообщение от Аноним (-), 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ообщить модератору
Родитель: #190

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

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

197. Сообщение от Аноним (-), 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ообщить модератору
Родитель: #192 Ответы: #198

198. Сообщение от 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ообщить модератору
Родитель: #197 Ответы: #205

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

200. Сообщение от Аноним (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 числа. Чем меньше это число - тем "ближе к назначению" этот узел. Это не имеет никакого отношения к физической близости узлов и является абстракцией, по которой те или иные узлы решают что они (не)будут индексировать на себе. > Получил я допустим файлик через мессенджер без трекера. К > кому он обратиться? Ко всем кто в таблице маршрутизации, опрашивая а > нет ли возможности соединения? Питекантроп, рассматривая микроволновку: "так, черт, а почему в моем лесу у нее табло не светится? Надо духов свечения вызвать, не иначе."
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #157

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

202. Сообщение от 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ообщить модератору
Родитель: #196 Ответы: #210

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

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

205. Сообщение от Аноним (205), 10-Окт-24, 06:16	+/–
> А такие есть?)) Везде +/- одно и то же с вариациями на > тему. Тут скорее пора "реконструировать площадку". Пока совсем поздно не стало. Ну, в более приватном порядке в том же tox можно. А так да, интернет должен стать менее централизованным, имхо. > Да я нисколько и не сомневаюсь)) Словосочетание "официальная причина" ..уже имеет характерный окрас :) > Да вы вон по opennet пройдитесь - ретроградов полно. Ну и желзки > всякие встречаются. Я своими глазами видел работающие компьютеры под управлением MS-DOS > и с живыми floppy дисководами. И не так давно - в 2016 году буквально. Я в свое время этого счастья наюзался, так что развандалил пару флопов под более интересные цели. > Так я и говорю - так-то сервер организовать не проблема. Проблема в > доступе в интернет, а также в возможных изменениях... локации. Одна из причин по которым я лю мелкие маложручие железки. А в торентах суперсервера так то и не велкам, миллион комаров лучше 1 слона выживают. Прибить сложнее. > В этом случае проблем вообще 0. Тот, кто с прямым доступом, просто > работает в режиме "сервер". Ну да. Впрочем сервер от клиента в udp в основном отличатеся "кто начал первым" и скажем вайргад умеет и в реверс ролей. >> Жирные месенджеры умеют релей через свои сервера накрайняк. > Да, но оно накладно. И медленнее/более склонно к икоте. Но лучше чем никак! > Да, поставленные задачи оно не особо выполняет. Там в результате инфо вида "что качали с этого пула адресов всей толпой". Не очень полезное уже знание. > С одной стороны - да. С другой, DHT сеть для торрентов куда > как обширнее, т.е. её для p2p связи использовать лучше. Лучше - потому что что? > ней везде в качестве ID - SHA1 хеши. Узлов tox для > бутстрапа тоже хватает, насколько я знаю, Их заметно больше чем well known торентовых. А sha1 не пригоден для начала коммуникаций сразу секурно, увы и ах. Слишком мало, даже для 25519 ключа. А с хешированиями, получениями ключей и явными хешдшейками - уже не то. > заводя узел в DHT сети вы помимо всего прочего способствуете раздачам торрентов. Спорный вопрос хотели ли те кто чатится еще и совсем побочных рож сервировать DHTом. > изначально шифрованные (включая подпись), то оно без особой разницы. Просто ещё > одна гарантия, что пакет пришёл от того, от кого ожидалось. В упомянутой схеме - "не тот" чисто технически не может такой пакет создать, он как максимум 2 публичных ключа видит. Недостаточно для shared secret и auth enc. К тому же 1й ключ может быть эфемерный, а второй слать не обязательно, получатель и так свой ключ знает. Кроме всего прочего если так TCP-relay без DHT пустить, произвольные васяны так сразу не смогут понять что сие такое (через DHT инфо ессно разъедется, но TCP relay может и в TCP-only пахать). > только при обмене одноразовыми ключами - чтобы точно быть уверенным, что > ключ пришёл от того, от кого надо. А там это как раз не надо: возможность расшифровать/зашифровать "authenticated encryption" - достаточный пруф обладания ключом "сам по себе". Все сильно проще при том же результате. Т.е. пруфом обладания клчом является сама возможность операций на нем. > Да. У меня оно просто примерно также работает - каждый контакт вешается > на свой порт, У tox все чуть хитрее. Для ряда случаев есть туннелирование чтобы айпи не светить. > что пришёл в пакете, и имеющийся (полученный по другим каналам и > использующийся в качестве уникального идентификатора контакта). Похоже на обычный эфемерный обмент. У тех он просто минимизирован до только того что реально надо. > Да, идея понятна. В этом варианте можно шифровать весь DHT трафик, кроме > изначального обмена ключами. А вон там 1 ключ может быть эфемерный, второй "подразумеваемый". И вот вы пуляете пакет, у него в хидере только какой-то случайный временный "ваш" ключ, ремота сама догадается что у нее за ключ был, а атакующему, вот, кус бесполезного рандома. И пусть гадает был ли валиден этот пакет вообще. > и нет там ничего значимого, только ip адрес). В случае tox в ряде случаев и IP может не быть, особенно в случае TCP. Там онионы на минималочках сделаны как я помню. Всерьез только им доверять я б не стал, но кой-какие меры чтобы не светить IP в лоб - приняты. > Это вы)) А интернет обширен и разнообразен. Не вижу проблем пробрость v6 или поставить виртуалочку с впн накрайняк, чотбы нормальную конективити получить, а не тот франкенштейн, где уже даже айпишник дико прыгать может. >> так чуть не лишился контроля, когда uTorrent его обставил. > Зависит от удобства предложенного нового варианта. А также от желания ALL это кодить. Что совсем не факт. >> Просто соотношения в результате - не очень. > Да по-всякому бывает. Тут просто ещё вопрос в том, что существующие BEP > - реально неудобны. Не в плане концепции, а в плане конкретных > вещей в протоколе. Там просто переделывать слишком много, реюз кода отправится нафиг, а програмерам это не нравится.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #198 Ответы: #209

206. Сообщение от Аноним (-), 10-Окт-24, 06:47	+/–
> Дело не в портах скорее всего, а в мобильных операторах. Владелец телефона/планшета > перемещается, поэтому его периодически с вышки на вышку перебрасывает, соответственно > цепочка роутеров для выхода в "большой" интернет меняется. В сотовых сетях - сессия данных не переподымается при переходе с соты на соту. К тому же эффект есть не только в сотовых сетях. > автоматом выкидывает на другую (в какой-нибудь Москве например). Поэтому ip и > меняется постоянно. Вон то совершенно точно приколы CGN которому видимо портов на энном айпи уже не хватило для i++ конектции юзера. Я уверен в моих данных. >> любители указывать что хорошо и плохо, типа MAFIAA всяких. > Оно везде +/- одинаково, поэтому *надзоры со звёздочкой. Ну не скажите, Due Process все же урезаер прыть. А не так что вот тут диско загасим, вот тут фигстаграмм, приняв решение за 5 минут по желанию левой пятки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #191 Ответы: #208

207. Сообщение от Аноним (-), 10-Окт-24, 06:58	+/–
> nginx как то умеет файлы отдавать кусками без вот этого всего дублирования > у себя в коде и на перформанс никто не жалуется. Для HTTP клиентов характерно тянуть 1 или накрайняк несколькими большими сегментами, а не чанками по несколько мегов. Ну и вымывание кеша на нагруженном nginx всем так то похрен, вы же там не будете допустим по разлапистым директориям шарахатся интерактивно. Если конечно нечто только под торент и оперативы дохрена... но осмысленный кеш и префетч на стороне клиента работает все же лучше. Особенно если это все еще и в отдельных тредиках. > Да и в целом даже отдача кучи мелких файлов по сути не > сильно отличается от раздачи кусков из одного файла для кеша ФС. А таки - ну вот выносит торент клиент кеш, ежели в наивную это деоать. И на компе общего назначения сие несколько напрягает просадкой перфоманса, особенно на механике. > Так что нет, практика показывает что без вот этого всего используя штатные > механизмы ОС можно вполне годно работать. Практика показывает что мало-мальски серьезные клиенты - кодят вот это вот. > direct IO и вот это всё часто БД юзают, но у них > там свои особенности с частой записью в одни и теже места. У direct io фича в том что он - таки - не выносит системный кэш. Так что остальные таски от этой активности не страдают. А при префетче или записи более-менее жирного чанка перфоманс все же непозорный.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #204

208. Сообщение от ProfessorNavigator (ok), 10-Окт-24, 12:54	+/–
> Вон то совершенно точно приколы CGN которому видимо портов на энном айпи > уже не хватило для i++ конектции юзера. Я уверен в моих > данных. Да, проблема с портами тоже имеет место. Просто в случае с сотовыми операторами там ещё и радиотехнические вещи будут. Всех клиентов нужно разводить по частотам и/или времени передачи пакетов. А дальше всё упирается в технические возможности конкретной железки на конкретной вышке. > Ну не скажите, Due Process все же урезаер прыть. А не так > что вот тут диско загасим, вот тут фигстаграмм, приняв решение за > 5 минут по желанию левой пятки. Да нет, оно на самом деле действительно везде +/- одинаково. Я до относительно недавнего времени много и часто контактировал с госслужбами по всему глобусу. В лице пограничников, таможни и разного рода инспекций. Есть свои нюансы везде естественно, но по большому счёту всё зависит от конкретных исполнителей на местах. Ну и ещё кое-какие вещи роль играют, вроде того - сколько в стране конкурирующих группировок буржуазии и в каких соотношениях их силы/средства. Относительно нормально для обычных людей оно работает тогда, когда группировок больше одной, силы их примерно равны, а интересы - диаметрально противоположны. Тогда есть шанс, что будет соблюдаться хотя бы видимость следования правилам.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #206 Ответы: #212

209. Сообщение от ProfessorNavigator (ok), 10-Окт-24, 13:36	+/–
> Ну, в более приватном порядке в том же tox можно. А так > да, интернет должен стать менее централизованным, имхо. Под "реконструкцией площадки" подразумевается не только интернет ;) Такие вещи нужно решать в комплексе, потому что проблемы интернета - это не только и не столько проблемы интернета. > Я в свое время этого счастья наюзался, так что развандалил пару флопов > под более интересные цели. Ну-у... Можно и так)) Но кто ж даст разваландать действующий терминал INMARSAT)) Нет, технически - никаких проблем. Но последствия могут быть... интересными. > И медленнее/более склонно к икоте. Но лучше чем никак! Кто ж спорит. Просто провайдера, который такое устроит, пользователи скорее всего с г...м сожрут)) > Там в результате инфо вида "что качали с этого пула адресов всей > толпой". Не очень полезное уже знание. Да. Но при очень большом желании конкретного пользователя можно установить. Правда, как писал в другом месте - заниматься этим скорее всего никто не будет. Потому что затраты ресурсов в итоге превысят все разумные пределы. > Лучше - потому что что? Вашими же словами - чем больше пользователей, тем всё это дело прибить сложнее. > Их заметно больше чем well known торентовых. А sha1 не пригоден для > начала коммуникаций сразу секурно, увы и ах. Слишком мало, даже для > 25519 ключа. А с хешированиями, получениями ключей и явными хешдшейками - > уже не то. На самом деле пора протокол DHT унифицировать, тогда всем веселее будет. Тем более, что SHA1 хеши уже надёжными не считаются. Я в том числе и поэтому говорю, что пора бы BEP пересмотреть. С участием всех заинтересованных сторон - с участием всех, кто так или иначе использует разные варианты DHT. > Спорный вопрос хотели ли те кто чатится еще и совсем побочных рож > сервировать DHTом. Да там нагрузки то не сильно отличаются. Тем более для тех, кто за NAT сидит - такие узлы всё равно в большинстве случаев в режиме read only работают. > В упомянутой схеме - "не тот" чисто технически не может такой пакет > создать, он как максимум 2 публичных ключа видит. Недостаточно для shared > secret и auth enc. К тому же 1й ключ может быть > эфемерный, а второй слать не обязательно, получатель и так свой ключ > знает. Тут ещё и дополнительная гарантия целостности данных. UDP пакет может прийти в каком угодно виде. В том числе в таком, что частично расшифруется корректно. И если проверка подписи не пройдёт - тогда точно сразу можно сказать, что пакет битый.   > У tox все чуть хитрее. Для ряда случаев есть туннелирование чтобы айпи > не светить. Да, я знаю. Я от этой идеи сразу отказался в пользу организации непосредственно TCP релея. Чтобы не передавать данные через непонятно кого, и потому что туннелирование особой анонимности не даёт - установить цепочку всё равно можно без особых проблем (для тех, кто в этом заинтересован). Анонимность сегодня по факту вообще ничто не даёт. Если будет надо, сам факт передачи данных установят, от кого и кому - найдут. > А также от желания ALL это кодить. Что совсем не факт. Если новый протокол будет удобнее, то и кодить под него будут. Не сразу естественно - понятно, что такие вещи быстро не происходят. > Там просто переделывать слишком много, реюз кода отправится нафиг, а програмерам это > не нравится. Естественно не нравится. Но лучше один раз переделать нормально, чем городить кучи костылей, чтобы заткнуть несуразности в протоколе, а потом всё равно переделывать - ничто не вечно под Луной.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #205 Ответы: #211

210. Сообщение от Аноним (-), 10-Окт-24, 14:51	+/–
> Мне uTP не нужен, его отсутствие не проблема для меня. А можно и в черно зеленый терминал пялиться. И нафиг торенты, UUCP хватит! > Я не фанат этого протокола и считаю что TCP намного лучше работает Чем лучше? uTP отваливает в туман если что-то еще качается, а с TCP торент весь канал засир@ет и не больно то отдает какому-нибудь браузеру, который тупит при активном каче торентов. > и что с ним проблем никаких нет, которые бы стоило решать > корябая uTP, HTTP/3 и прочие поделки. Я и вижу, как этот крап работает с беспроводкой. И правда, не понятно, чего им всем таймауты по минуте после проезда тоннеля не нравятся?! Или, вот, дикий тупняк веба если торенты качаются. Странные люди, хотят чтобы нормально работало, а не как окаменелая блевотина из прошлого века. > Под моей реализацией uTP понимается именно реализация парсера протокола и кажется у > меня RST сообщение умеет генерить. Очередная вредительская приблуда? Я то уж думал что полезное... тьфу ты! > Congestion Control и Socket API я к нему не делал и не собирался. > Собственно CC нужен исключительно на отдачу, если делать только качалку то можно > и без него обойтись. Ох, то-есть тут не только вредительство протоколу - но еще и личерство? И зачем я в эту дискуссию влез, теперь вы в моем восприятии мира - конкретный м...к! С точки зрения сетей и p2p. > И авторы этого всего вроде как выложили готовую либу, судя по моим > старым записям :) Либу, блин, чего? Саботажа uTP? Личерства без congestion? Вы там какие-то поклонники садо-мазо, чтоли с этим всем? Или что за нахрен? > Насчёт рокетсаенса - фигня, берём простенький hybla из линуха и радуемся жизни, > он отлично работает даже на фоне более современного RACK. У вас какие-то очень специфичные представления о радостях жизни, из области садо-мазо походу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #202

211. Сообщение от Аноним (211), 11-Окт-24, 04:45	+/–
> Под "реконструкцией площадки" подразумевается не только интернет ;) Так то вы правы профессор, но вы поаккуратнее, имхо. Законы у вас драконовые. > не только и не столько проблемы интернета. Да я даже и не спорю, но в РФ общественные процессы - на нуле. Да и с MAFIAA зарубаться таки сложно. Денег у них много. Немного поугомонились, в p2p треш но но супертреш, но все равно. > Ну-у... Можно и так)) Но кто ж даст разваландать действующий терминал INMARSAT)) > Нет, технически - никаких проблем. Но последствия могут быть... интересными. Терминала инмарсат у меня нет. А флопы, вот, были. Нафиг они в современном мире черт его знает, ну я и поюзал механику и часть электроники (драйвер шаговика). > Кто ж спорит. Просто провайдера, который такое устроит, пользователи скорее всего с > г...м сожрут)) За ютуб же не сожрали? Хотя при возможности сменить, ессно, вариант возможен. > Да. Но при очень большом желании конкретного пользователя можно установить. Это знание имеет свойство протухать и к тому же может быть в другой юрисдикции. Так что так ловить будут ну хз, разве что несколько совсем задолбавших релизеров. > Вашими же словами - чем больше пользователей, тем всё это дело прибить сложнее. В принципе это так. Но с другой стороны, чем популярнее - тем больше решений для прибития, кто-то крупный типа MAFIAA и прочих DPI может вбросить денег на изучение самых слабых мест. И есть некоторая разница между тем когда хоть немного попытались в секурити VS когда совсем нет. > На самом деле пора протокол DHT унифицировать, тогда всем веселее будет. Его тогда и банить будет проще всем желающим. А так GnuNet это попытался, но получился тот еще франкенштейн. Да и XKCD #927 не отменяли. Task specific реализации могут быть более элегантны. Скажем вот 160 бит по ширине хеша торента. Или 256 - по ширине ключа 25519. Это сильно упрощает ряд вещей, ликвидируя минимум 1 лишний уровень абстракции/ремаппинга. > Тем более, что SHA1 хеши уже надёжными не считаются. Я в том > числе и поэтому говорю, что пора бы BEP пересмотреть. Ну так там и есть некий torrent 2.0 с какими-то иными хешами. Не особо идет в массы, и конечно кохем как истый питонист ограничился полумерами. Так что с одной стороны несовместимо, с другой полумеры, в общем недостатки обоих миров слились воедино. > использует разные варианты DHT. У них могут быть очень разные приоритеты и пожелания. Мягко говоря. > Да там нагрузки то не сильно отличаются. Э не, они СУММИРУЮТСЯ. Ибо придется обслуживать и тех и других. Для зафайрволеного нода может и не быть сильно большой проблемой, но для остальных трафика подгрузит, а стабильный активный DHT торента постепенно начинает собирать довольно много трафа на себя. > Тем более для тех, кто за NAT сидит - такие узлы всё равно в большинстве случаев > в режиме read only работают. Ну вот им да, НО... как я уже сказал это вообще крайне нежелательный режим для DHT и p2p вообще, будущее за IPv6. А там нормальная конективити - норма жизни. И трафа подвалит. >> эфемерный, а второй слать не обязательно, получатель и так свой ключ знает. > Тут ещё и дополнительная гарантия целостности данных. UDP пакет может прийти в > каком угодно виде. В auth enc by design есть "authenticator" проверяющий целостность пакета на основе poly1305 и того "shared secret" который даст DH (25519). Но для сторонноего наблюдаетеля не знающего shared secret это лишь кучка случайных байтов. Вы явно не видели апи cryptobox(). А напрасно. > можно сказать, что пакет битый. Там это все тоже есть. Не только битый но и forged кем-то левым без известного ключа ремоты. Но все гарантии в этом случае - эфемерны, они только пока есть сессия и тот shared secret от эфемерной пары. После того как эфемерные ключи уничтожены, это ничего не означающий набор байтов. > Да, я знаю. Я от этой идеи сразу отказался в пользу организации > непосредственно TCP релея. Чтобы не передавать данные через непонятно кого, ...TCP релей можно и свой добавить, и указать бутстрапом только его. Но это неважный сетап с точки зрения анонимности как раз. Ибо довольно легко трейсится. Разве что разрешить толпе васянов ходить через него, но даже так - вон те более "затоптанные" будут. И намного лучше если owner релея не указывает на вас. > и потому что туннелирование особой анонимности не даёт - установить цепочку всё > равно можно без особых проблем (для тех, кто в этом заинтересован). Это таки - поднимает планку атаки, делая дороже, неудобнее и негарантированнее. > Анонимность сегодня по факту вообще ничто не даёт. Если будет надо, > сам факт передачи данных установят, от кого и кому - найдут. В случае onion'ов то? Когда оно релеить может? Это мягко говоря не совсем простое начинание. Как вы понимаете, у меня ISP в принципе не видит - вот это вот. И что он там установит? >> А также от желания ALL это кодить. Что совсем не факт. > Если новый протокол будет удобнее, то и кодить под него будут. Не > сразу естественно - понятно, что такие вещи быстро не происходят. Там вон уже эти господа попытались какой-то торент 2.0. Неведома зверушка, с полумерами. > Естественно не нравится. Но лучше один раз переделать нормально, чем городить кучи > костылей, чтобы заткнуть несуразности в протоколе, а потом всё равно переделывать > - ничто не вечно под Луной. А таки - все не предусмотришь. По ходу дела будут вылезать разные моменты. Но да, сначала подумать а потом накодить - это более потребный план чем наоборот. А Кохем, вот, наоборот изначально сделал по сути.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #209 Ответы: #213

212. Сообщение от Аноним (-), 11-Окт-24, 05:01	+/–
> Да, проблема с портами тоже имеет место. Айпишники видите ли - подорожали. Видимо ставят на минималках совсем. Так что вот, оптимизация, раскидывать новые исходящие на недоюзаные порты других айпишников пула. > по частотам и/или времени передачи пакетов. А дальше всё упирается в > технические возможности конкретной железки на конкретной вышке. Оно таки довольно упрямое в удержании сессии и чтоб совсем отвалилось - ну, не настолько это часто. >> 5 минут по желанию левой пятки. > Да нет, оно на самом деле действительно везде +/- одинаково. Да нет, due process таки - довольно прилично времени, сил и денег занимает. Так что по ерунде и за 5 минут, ВНЕЗАПНО - ну вот нет. > относительно недавнего времени много и часто контактировал с госслужбами по всему > глобусу. В лице пограничников, таможни и разного рода инспекций. А у меня просто знакомые по всему глобусу есть. И я могу посмотреть как оно, по факту. > когда группировок больше одной, силы их примерно равны, а интересы - > диаметрально противоположны. Тогда есть шанс, что будет соблюдаться хотя бы видимость > следования правилам. Ну таки откровенно lawless стран не так уж много. Так с наскока бразилия припоминается, где какие-то мутные процессы в законодательстве. Ну и чайна с иранами всякими. А более приличные юрисдикции вот так за 5 минут по желанию левой пятки - все же не гасят. Хотя, конечно, вон ту плашку SEIZED от FBI можно и в штатах на сайт словить. Но это далеко не за 5 минут случится, придется и постараться (раздачей вареза) и нехилую известность срубить, тогда они все же по судам побегают чтобы получиьт ордер и выпилить это на радость копирасам.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #208

213. Сообщение от ProfessorNavigator (ok), 11-Окт-24, 13:47	+/–
> Законы у вас драконовые. Да... Тут вопрос не в том, будет или нет, а в том - когда будет и что именно. Потому что ситуация складывается так, что либо "реконструкция площадки", либо все тупо сдохнут. И "когда" - это вопрос пары-тройки лет, вряд ли больше. А скорее всего, что называется, "в любой момент". Собственно гайки в том числе потому и закручивают, что "подгорает". > Да я даже и не спорю, но в РФ общественные процессы - > на нуле. Да и с MAFIAA зарубаться таки сложно. Денег у > них много. Немного поугомонились, в p2p треш но но супертреш, но > все равно. С общественными процессами тут всё сложнее, чем кажется - в СМИ попадает далеко не всё, что происходит на местах. Другое дело, что совершенно непонятно, во что эти "общественные процессы" в итоге выльются. Направляющего стержня нет, а "мы за всё хорошее и против всего плохого" никогда не работало. Деньги же... Деньги играют роль ровно до того момента, пока действуют правила. Когда начинают стрелять пушки, правила действовать перестают. Следовательно и деньги начинают играть всё меньшую роль. Особенно для тех, у кого их нет. А таких большинство. > За ютуб же не сожрали? Хотя при возможности сменить, ессно, вариант возможен. С ютюбом тут несколько другое - всем очевидно, что виноваты не провайдеры отнюдь. Они то как раз могут и даже хотят. Ну и "ситуация" далеко ещё не закончилась. Пока что все немного приспособились - кто-то переключился на "отечественные" площадки, кто-то - пользуется всякими обходными вариантами. Но долго так скорее всего не будет. Скоро людям надоест стоять на голове и пытаться сделать что-то полезное ногами. А "отечественные" площадки... Скажем так - ютюб тоже далеко не подарок. 90% содержимого там - откровенные помои. И всякие интересности от администрации тоже присутствуют, куда ж без них. Но таки 10% - относительно полезные вещи. Вроде научно-популярных и научных лекций и т.п. На "отечественных" же площадках помои - это 99,99% содержимого. И ситуация лучше не станет. Люди тупо выживанием больше озабочены. Те же, кто имеет достаточно свободного времени и возможностей создавать "контент", в большинстве своём на что-то осмысленное не способны от слова совсем.   > Это знание имеет свойство протухать и к тому же может быть в > другой юрисдикции. Так что так ловить будут ну хз, разве что > несколько совсем задолбавших релизеров. Так о том и речь, что технически - можно. Но вот в реальности вряд ли кто таким заниматься будет. > В принципе это так. Но с другой стороны, чем популярнее - тем > больше решений для прибития, кто-то крупный типа MAFIAA и прочих DPI > может вбросить денег на изучение самых слабых мест. И есть некоторая > разница между тем когда хоть немного попытались в секурити VS когда > совсем нет. Изучать особо некому. Тут грамотных специалистов в чём-либо осталось - иногда по пальцам пересчитать можно. На всю страну. И такое не только в IT, оно везде так. А самое страшное - оно не только в РФ, оно по всему миру так. > Его тогда и банить будет проще всем желающим. А так GnuNet это > попытался, но получился тот еще франкенштейн. Да и XKCD #927 не > отменяли. Task specific реализации могут быть более элегантны. Да, специализированные варианты в своих конкретных областях работают лучше. Фокус в том, что это всё прихлопнуть можно на раз. > Скажем вот 160 бит по ширине хеша торента. Или 256 - по > ширине ключа 25519. Это сильно упрощает ряд вещей, ликвидируя минимум 1 > лишний уровень абстракции/ремаппинга. О том и речь. А в качестве хешей в торрентах можно использовать те же SHA256 хеши. > Ну так там и есть некий torrent 2.0 с какими-то иными хешами. > Не особо идет в массы, и конечно кохем как истый питонист > ограничился полумерами. Так что с одной стороны несовместимо, с другой полумеры, > в общем недостатки обоих миров слились воедино. Поэтому и говорю - нужно нормально сделать. Постаравшись учесть интересы всех причастных и накопленный опыт. > У них могут быть очень разные приоритеты и пожелания. Мягко говоря. Да и пускай, ничто не мешает сделать некое ядро протокола, общее для всех, а для частных случаев - разные опциональные расширения. > Э не, они СУММИРУЮТСЯ. Ибо придется обслуживать и тех и других. Для > зафайрволеного нода может и не быть сильно большой проблемой, но для > остальных трафика подгрузит, а стабильный активный DHT торента постепенно начинает собирать > довольно много трафа на себя. Нет, если нормально реализацию писать. Те же записи о пирах держать дольше нескольких минут смысла нет - кто-то подключается, кто-то отключается, кто-то за NAT сидит, и у него порт периодически меняется. > Ну вот им да, НО... как я уже сказал это вообще крайне > нежелательный режим для DHT и p2p вообще, будущее за IPv6. А > там нормальная конективити - норма жизни. И трафа подвалит. Так оно опять же распределится более менее на всех. Так что для каждого индивидуально - скорее всего мало что поменяется. > В auth enc by design есть "authenticator" проверяющий целостность пакета на основе > poly1305 и того "shared secret" который даст DH (25519). Но для > сторонноего наблюдаетеля не знающего shared secret это лишь кучка случайных байтов. > Вы явно не видели апи cryptobox(). А напрасно. Я в основном с libgcrypt работаю. > Это таки - поднимает планку атаки, делая дороже, неудобнее и негарантированнее. Ну... Я про тех, кто имеет возможность прийти к вам в реале, вежливо показать нечто огнестрельное (или некую бумагу, что обычно имеет ничуть не меньший эффект, если бумага "правильная"), и также вежливо попросить показать логи вашего сервера. В этом случае "анонимность" не поможет. Обычное же ворьё и шифрование скорее всего не вскроет, если сами тупить не будете, что-то ещё сделать - вряд ли способны. Да и не будет таким никто заниматься, если только не обнаружится дыр уж совсем эпических масштабов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #211

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

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