Страница 2 из 2

Добавлено: 05 окт 2016, 18:18
HackFresse
Потому что этот "upstream" придуман только для оправданий и торможения развития.
Нету никакого ограничения, кроме нежелания и неспособности что-то реализовать.

В стронге сделали как могли что-то новое и клёвое, и другим клиентам это понравилось. Они себе фичу притянули и начали обмениваться файлами.
Реализация DHT от StrongDC++ работала, файлы качались.

Вместо того, чтобы разобраться, проанализировать проблему и убрать "левый UDP-траф", выпилил всю фичу.
Нахрена тогда тянул её?
Был же период с попытками свой dht-сервер поднять. Зачем, если "реализация DHT от StrongDC++ не работала и только напрасно гоняла левый UDP-траф" ?
flylinkdc писал(а):кому нужно найти источники - сделает это и без DHT
Забота о юзерах - это так приятно
flylinkdc писал(а):у флая DHT активирован в libtorrent - там будет использоваться именно он.
и смысла держать еще один открытый UDP порт не вижу смысла.
Ну да, зачем что-то делать в дц, если есть торренты? *THUMBS_UP*

Добавлено: 05 окт 2016, 19:07
flylinkdc
Ты сам когда последний раз что-то качал в DC++ через DHT?
расскажи как ты нашел стартовый источник?
и сколько источников подтянулось через DHT?
когда я проверял на тестовых TTH - пользы с этого DHT не заметил.

Добавлено: 05 окт 2016, 22:25
HackFresse
flylinkdc писал(а):Ты сам когда последний раз что-то качал в DC++ через DHT?
Выборка из одного меня очень прям показательна, вот прям верх анализа статистики.
"100% юзеров не качают через DHT, эта DHT не нужна 100%"
Так я и из дц через хабы не качал давно - их тоже надо выпилить, 100%.
flylinkdc писал(а):расскажи как ты нашел стартовый источник?
Фишка в том, что именно я и не должен ничего искать, оно всё само должно работать. Без участия юзера. И оно работает.

Я скачал старенький StrongDC Version: 2.42 Release date: 27.12.2010 ,
и у него в папке Settings файлик dht.xml обновляется (проверяется) довольно часто, и клиенты в нём разные, даже флайлинки есть, ага
Спойлер
Изображение
Старенький dht-bootstrap сервер стронга всё еще работает. Всего-то нужно открыть ссылку http://strongdc.sourceforge.net/bootstr ... 1&u4=25466 (обязательно с юзерагентом, начинающимся на 'StrongDC++ ' и обязательным параметром encryption=1) и распаковать gz-архив со списком стартовых нод.

http://dht.fly-server.ru/dcDHT.php?cid= ... 0&u4=25466 тоже отдаёт какие-то адреса с портами, но какой процент из них действительно доступны из инета - так и не разобрались, тема заглохла http://dchublist.ru/forum/viewtopic.php?f=10&t=1109
У флайлинка была проблема с корректностью определения открытого порта, из-за чего на сервер отправлялись невалидные данные.

Продавленный в айскальт адрес http://ssa.in.ua/dcDHT.php уже не работает (он там захардкожен до сих пор, https://github.com/eiskaltdcpp/eiskaltd ... er.cpp#L37)

Итого:
Список стартовых нод получить всё еще можно, с ними можно пробовать общаться, через них уже можно запрашивать соседние ноды роя. Дц-клиент обращается к веб-серверу за списком нод только тогда, когда сохранённых локально активных нод нету

Добавлено: 06 окт 2016, 08:27
flylinkdc
У тебя ошибочная иллюзия о том, что DHT решает проблемы DC
чтобы начать качать файл его нужно найти по имени, а это можно сделать только через хаб
если файл найден, то клиент скачает его и без DHT.
по моим тестам появления источника от DHT возникало очень редко.
а трафик DHT генерирует приличный - включи логирование dht.log и посмотри сколько говна летает по этой сети.

Разработчики eiskaltdc полтора года назад хотели заменить протухший адрес на dht.fly-server.ru (вероятно они полностью забили на DC++)
напишу еще раз чтобы вырезали этот старый адрес.
dht.fly-server.ru будет работать пока живой флай - он не напрягает.
но лишний DHT трафик из клиентов флая я выкинул.
кому нужны источники зайдут на хабы и повысят их онлайн.

Добавлено: 06 окт 2016, 14:03
HackFresse
flylinkdc писал(а):У тебя ошибочная иллюзия о том, что DHT решает проблемы DC
Относительно DC у меня вообще нету никаких иллюзий. Совсем.

DHT решает некоторые проблемы в торрентах, но в дц же таких проблем нету, решать нечего?
Или всё-таки проблемы есть, просто реализацию DHT немножко подкрутить надо было?

Ну так это надо было в вопросе разобраться, выкинуть же проще. Только не нужно утверждать, что DHT ничего не решает.
flylinkdc писал(а):чтобы начать качать файл его нужно найти по имени, а это можно сделать только через хаб
Ха-ха 2 раза.
Открою секрет - чтобы качать файл, нужно знать его хэш. Всего-то какую-то контрольную сумму.
Да-да, тот самый, который содержит магнет-ссылка. Всего-то поставить в очередь на закачку.
А через что будет поиск источников проводиться - ваще похрен. Хоть через прилетающие напрямую в открытый порт ответы на поисковые запросы (активный режим и DHT), хоть через хаб (пассивный режим), хоть через веб-запрос какого-то списка источников (торрент-трекер).

И через что качать файлы, тоже похрен. Торренты, дисишечка, фтп, хттп.. Файл будет одним и тем же.

Вот только хэши у разных сетей разные. и файл с известным только TTH (но неизвестным торрентовым хэшем ) будет качаться только через дц, но никак не через торрентовый DHT

Добавлено: 06 окт 2016, 14:38
flylinkdc
Я разбирался с DHT - работает он не эффективно и не поддерживается разработчиком из-за этого и был вырезан.
dht.log создавался чтобы показать сырой расшифрованный трафик гуляющий по порту DHT.

А вот откуда у юзера возьмется эта магнет-ссылка на TTH?
Чтобы скачать файлы они пишут названия в окно поиска,а некоторые особенно шустрые( или бестолковые) пишут слова поиска прямо в чат
DHT нужен только чтобы добавить чуток альтернативных источников и это работает когда клиентов действительно рой по всему миру (как торренты).
Но в связи с текущей ситуацией таких альтернатив мало:
1. Популярный контент и так валяется на юзерах, которые сидят на всех хабах.
2. Уникальный контент лежит у одно и альтернативу по DHT не найдешь.

У меня еще есть мысль оставлять в шаре те файлы которые юзер скачал пока клиент не выключит(по аналогии с торрентом)
это добавит источников - но тут есть проблема человеческого фактора
если юзер по ошибке скачал запрещенный контент и пошел спать - флай его начнет раздавать
и если это зафиксирует товарищ Майор то юзер во сне получит реальную уголовную судимость.

Добавлено: 06 окт 2016, 19:34
HackFresse
flylinkdc писал(а): не поддерживается разработчиком из-за этого и был вырезан.
Так весь DC уже не поддерживается разработчиками, весь DC вырезать и нужно
flylinkdc писал(а):dht.log создавался чтобы показать сырой расшифрованный трафик гуляющий по порту DHT.
Можно сравнить с таким же трафиком, гуляющим по торрентовому DHT.
flylinkdc писал(а):А вот откуда у юзера возьмется эта магнет-ссылка на TTH?
Торрентовые магнет-ссылки и файлы откуда-то берутся. магия, не иначе
flylinkdc писал(а):Чтобы скачать файлы они пишут названия в окно поиска,а некоторые особенно шустрые( или бестолковые) пишут слова поиска прямо в чат
это показатель удобства дц-клиента, "интуитивно понятный интерфейс", ага
flylinkdc писал(а):DHT нужен только чтобы добавить чуток альтернативных источников и это работает когда клиентов действительно рой по всему миру (как торренты).
Если все флайлинки будут знать про шару друг друга, они смогут качать между собой напрямую, без хабов. Раньше хоть не особо, но что-то получалось, теперь-то уж точно не смогут
flylinkdc писал(а):Но в связи с текущей ситуацией таких альтернатив мало:
1. Популярный контент и так валяется на юзерах, которые сидят на всех хабах.
2. Уникальный контент лежит у одно и альтернативу по DHT не найдешь.
Популярного и уникального контента на юзерах, которые сидят на хабах, всё меньше. Хабы закрываются, юзеры уходят.
Хабов пока еще 2 сотни (+локальные), юзеры сидят на 11 из них (год назад было около 15).

Популярный контент - добавятся источники, уникальный - может найтись хоть где-то. DHT - единое пространство для поиска между всеми юзерами, а не между одними и теми же, сидящими на одних и тех же хабах

На торрентах была привязка к трекерам (хабам), но время показало, что магнет-ссылки и DHT -- реально крутая штука.
Странно не понимать и не принимать тот факт, что проблема не в самих этих технологиях, а только в их реализации.
flylinkdc писал(а):У меня еще есть мысль оставлять в шаре те файлы которые юзер скачал пока клиент не выключит(по аналогии с торрентом)
это добавит источников - но тут есть проблема человеческого фактора
если юзер по ошибке скачал запрещенный контент и пошел спать - флай его начнет раздавать
и если это зафиксирует товарищ Майор то юзер во сне получит реальную уголовную судимость.
Фиче лет уже дохренища, а мысли только сейчас появились *CRAZY*

Добавлено: 06 окт 2016, 21:34
flylinkdc
Флаи не смогут знать про шару друг-друга через DHT - для этого нужны хабы.
ты не изучил до конца как это все работает или прикидываешься?
И кстати тут ветка про торренты а не про вырезанный DHT от мертвого стронга
и еще ты всегда чем-то не доволен - не замечал за собой такой особенности?

Добавлено: 06 окт 2016, 22:25
HackFresse
flylinkdc писал(а):Флаи не смогут знать про шару друг-друга через DHT - для этого нужны хабы.
HackFresse писал(а):Если все флайлинки будут знать про шару друг друга, они смогут качать между собой напрямую, без хабов. Раньше хоть не особо, но что-то получалось, теперь-то уж точно не смогут
А вот представь , что такое вдруг стало возможным, чтобы флайлинки знали друг про друга. "Чисто гипотетически" предположи. Подключи воображение.
Чтобы было проще, представь людей, которые знают друг друга.

И представь, что нужна тебе какая-то хрень редкая, типа старого патефона.
И вот ты идёшь на рынки и там смотришь, продают ли патефон.
И у всех своих знакомых спрашиваешь, есть ли у них патефон на продажу, а они уже у своих знакомых спрашивают про патефон для тебя, а знакомые знакомых тоже спрашивают, ищут тебе патефон.
А если верить всяким там учёным https://ru.wikipedia.org/wiki/%D0%A2%D0 ... 0%B8%D0%B9 , то все люди друг друга знают через несколько знакомых

Так вот, хабы - это как рынки, где торгуют определённым набором товаров. А искать "по знакомым" - это же так похоже на DHT, разве нет? Ты спрашиваешь у знакомых список их знакомых, чтобы просто спросить про патефон/ттх
flylinkdc писал(а):ты не изучил до конца как это все работает или прикидываешься?
А ты сам-то изучил, как это работает, или прикидываешься? Объяснять элементарное по каждому вопросу приходится..
flylinkdc писал(а):И кстати тут ветка про торренты а не про вырезанный DHT от мертвого стронга
Так надо было сразу взять и написать, что сам не смог разобраться и пофиксить фичу, притянутую из мёртвого стронга, и потому решил выпилить.
Не надо указывать , что сама технология DHT в DC не нужна, она вообще бесполезна и ничего не решает, это не так.
flylinkdc писал(а):и еще ты всегда чем-то не доволен - не замечал за собой такой особенности?
Я замечал, что моим аргументам одиноко без контраргументов. Пишу утверждение, а против него и обосновать-то нечего.
Никакого полноценного спора, только через некоторое время у меня будет еще одно "а я же говорил"

Добавлено: 07 окт 2016, 10:56
IRainman
DHT в DC++ нужен и хоронить его нельзя. Его допиливать нужно, повышая эффективность. Это вот хабы в DC++ скорее не нужны ибо централизация в таких протоколах это всегда печаль. В bittorrent как раз и добавили DHT чтобы можно было найти пиров без трекеров (по сути аналог хабов, только кроме списка пиров ничего не отдающий).
Флаи не смогут знать про шару друг-друга через DHT - для этого нужны хабы.
Паш, но ведь DHT это просто распределённая таблица узлов (по сути тот же хаб только без сервера), а сам протокол там ADC и работает там весь протокол с любыми запросами. Там не только получение списка файлов и поиск работает, но и даже сообщения, например. Так что могут клиенты между собой по DHT знать про шару друг друга. Есть там тонкость что для работы DHT в DC++ нужно достучаться до узлов, а ретрансляторов не предусмотрено, но так это просто не доделано. Сама концепция ведь отлично работала.

DHT в bittorrent тоже создаёт "лишний" трафик и вообще любая распределённая (p2p) сеть создаёт дополнительный трафик в разных местах на поддержание своей работы. Также напрямую сравнивать протоколы только лишь по DHT не корректно ибо в bittorrent применены другие механизмы (обмен пирами) поскольку DHT и трекеры изначально не могут поддерживать отдачу клиенту полного списка пиров. В тоже время в DC++ DHT может дать достучаться до всех клиентов как будто они на одном глобальном распределённом хабе. Так что сравнивать надо общий оверхед по протоколам.

Принципиальная разница между DC++ и bittorrent в том, что для второго не знание клиента о максимально большом количестве пиров менее критично и это только потому что в bittorrent вообще нет понятия файл-листа в клиенте, а вот в DC++ это важно поскольку доступ к большему количеству клиентов даёт больше файл листов и больше вариантов для текстового поиска без хеша. Это всё особенности протоколов, а не баги!

В DC++ есть из коробки хеши, имена и размеры всех файлов, структура каталогов и полный файл лист. В bittorent хеши файлов не обязательны и их нет почти ни в одной раздаче, из-за этого один и тот же файл в 15 разных раздачах (например видео + разные субтитры/дорожки рядом) не может быть найден в bittorent. В тоже время в DC++ можно найти нужный файл у любого пира даже если он называется по другому, а не только у того у кого есть такая же раздача.

То что в DC++ можно искать по именам файлов не привязываясь к хешу это фича и особенность протокола, а не баг же! Например, изменит юзер ID3 теги в файле и всё - в bittorrent этот файл исчезнет с концами, а в DC++ останется и по имени его можно будет найти.

Помимо этого в bittorrent точно также как и в DC++ без начального бутстрапа клиенты не увидят друг друга вообще, это если говорить о аналоге хаба в bittorrent.

Так что выпиливание DHT из Флая это катастрофа.

P.S. про изначальное появление DHT промолчу, хоть ослик и гораздо ближе по логике работы сети в целом к дисишке чем дисишка к торрентам. Это сейчас не сильно важно в контексте обсуждения.
P.P.S. поиск локальных пиров в bittorrent это вообще из другой оперы и никто не мешает сделать точно такие же локальные мультикаст запросы на заранее обговорённый порт и в DC++, вот только к DHT эта фича вообще никакого отношения не имеет.

Добавлено: 07 окт 2016, 11:05
IRainman
И ещё, ведь ради поддержки торрентов логику интерефейса придётся во Флае переделать под корень, Паш, тебя это не смущает? Также, из-за различий протокола и чтобы не держать десяток интерфейсов по работе с диском придётся это место тоже переделывать ибо в bittorent понятие "файл" отсутствует, ну и без этого всякие фичи не будут работать вроде просмотра и т.д. Или всё это проблемой не считается?

Вообще это очень странное решение пилить подобного монстра с двумя протоколами ибо как показывает весь накопленный опыт из таких проектов в итоге получается Nero Burning ROM, который работает плохо со всеми протоколами, по настоящему тяжёл и монструозен и содержит тонны глюков.

Добавлено: 07 окт 2016, 11:22
flylinkdc
IRainman писал(а):Там не только получение списка файлов и поиск работает, но и даже сообщения, например. Так что могут клиенты между собой по DHT знать про шару друг друга.
Хм. покажи видеоролик (или скрин) как открыть файл-лист с DHT юзера и послать ему сообщение?

Добавлено: 07 окт 2016, 11:31
flylinkdc
IRainman писал(а):И ещё, ведь ради поддержки торрентов логику интерефейса придётся во Флае переделать под корень, Паш, тебя это не смущает?
В чем будет заключаться переделка?
Нужно добавить диалог выбора пути загрузки и выбора файлов если их в торренте несколько.
историю я уже поправил так:
https://yadi.sk/i/n-5ROliEwQKPq
Вот очередь загрузки у флая уродская - и нужно сделать как в AirDC
https://yadi.sk/i/IH9Fk2qywQL8j
и 2 ветки - торренты и дц++

Добавлено: 07 окт 2016, 23:28
HackFresse
flylinkdc писал(а):IRainman писал(а):Там не только получение списка файлов и поиск работает, но и даже сообщения, например. Так что могут клиенты между собой по DHT знать про шару друг друга.
Хм. покажи видеоролик (или скрин) как открыть файл-лист с DHT юзера и послать ему сообщение?
У меня есть кое-что получше -- исходники!

https://github.com/pavel-pimenov/flylin ... T.cpp#L416
Спойлер
/*
* Sends private message to online node
*/
void DHT::privateMessage(const OnlineUserPtr& ou, const string& aMessage, bool thirdPerson /* = false */)
{
AdcCommand cmd(AdcCommand::CMD_MSG, AdcCommand::TYPE_UDP);
cmd.addParam(aMessage);
if (thirdPerson)
cmd.addParam("ME", "1");

auto key = UDPKey();
key.m_ip = ou->getIdentity().getIpAsString();
key.m_key = ou->getUser()->getCID();

send(cmd, ou->getIdentity().getIpAsString(), ou->getIdentity().getUdpPort(), ou->getUser()->getCID(), key);
}
Отправить сообщение

https://github.com/pavel-pimenov/flylin ... T.cpp#L821
Спойлер
// private message
void DHT::handle(AdcCommand::MSG, const string& /*ip*/, uint16_t /*port*/, const UDPKey& /*udpKey*/, const AdcCommand& /*c*/) noexcept
{
// not implemented yet
//fly_fire1(ClientListener::PrivateMessage(), this, *node, to, node, c.getParam(0), c.hasFlag("ME", 1));

//privateMessage(*node, "Sorry, private messages aren't supported yet!", false);
}
Почти получить сообщение

https://github.com/pavel-pimenov/flylin ... T.cpp#L830
Спойлер
void DHT::handle(AdcCommand::GET, const string& ip, uint16_t port, const UDPKey& udpKey, const AdcCommand& c) noexcept
{
if (c.getParam(1) == "nodes" && c.getParam(2) == "dht.xml")
{
AdcCommand cmd(AdcCommand::CMD_SND, AdcCommand::TYPE_UDP);
cmd.addParam(c.getParam(1));
cmd.addParam(c.getParam(2));

SimpleXML xml;
...
xml.toXML(&sos);

cmd.addParam(Utils::compressXML(nodesXML));

send(cmd, ip, port, CID(c.getParam(0)), udpKey);
}
}
А отправка списка нод - почти как отправка списка файлов , которая используется на обычных хабах, "$ADCGET file files.xml.bz2 0 -1|"
Спойлер
Изображение

Добавлено: 07 окт 2016, 23:39
flylinkdc
У тебя грейлинк - у него для dht отдельное окно. (я кстати это сам не проверял - завтра потестирую)
как это сделать в родителе DHT - стронге простому юзеру?

Добавлено: 08 окт 2016, 00:29
HackFresse
Что именно сделать? И при чем тут стронг и грей? Окно со списком нод / массив в памяти / xml-файл на диске - похрен вообще.
Ссылки выше - на репозиторий флайлинка, код выпиливался оттуда.
Пример закачки файл-листа тоже был с флайлика.
Вот между двумя флайлинками
Спойлер
Изображение

Добавлено: 09 окт 2016, 10:55
IRainman
flylinkdc писал(а):Хм. покажи видеоролик (или скрин) как открыть файл-лист с DHT юзера и послать ему сообщение?
Пишу на момент как при мне было.
Там не до конца дописано (в плане личных сообщений точно) и в GUI не вытащено, но само общение по протоколу работало. Тестировали ведь и скачивание файл листа по DHT без хабов работало (и хорошо работало, файл-лист оставили ведь, как и поиск) и даже сообщениями баловались когда влили код из стронга, но как ЛС работали не помню. HackFresse на правильные куски кода ссылается. При обмене по DHT чем либо в окне передач пишет что скачивание идёт c хаба DHT (это если про файл лист говорить)

Сделать для DHT отдельную вкладку не проблема, надо недостающие функции дописать, хотя бы заглушками и просто "открыть вкладку с DHT как ещё один ADC хаб", интерфейс то унифицирован.

Ещё раз напишу про важный момент: с DHT может казаться что оно не позволяет много чего сделать если один из юзеров в пассивном режиме. Происходит это поскольку релей для DHT там был не доделан и не работал (он ни в одном клиенте не работал тогда, ни в стронге, ни в грее, ни где то ещё), соответственно в таком случае любые запросы до пассивного юзера дойдут только через adc хаб, к которому подключён и клиент и тот пассивный юзер *. В общем хаб в таком случае и выступает как релей, который транслирует все необходимые команды пассивному юзеру. Также напомню, что с точки зрения логики протокола adc хаб, клиент и DHT ничем не отличаются, только доступным набором команд. То есть если вот прямо сейчас в DHT клиенту добавить обработку команды ЛС или любой другой как будто он хаб(!) то как раз и получится релей и всё заработает даже с пассивными юзерами, помимо этого для совсем полноценного релея полностью через DHT надо будет ещё сделать ретрансляцию запроса в сеть, но суть в том, что это можно сделать и понятно как. Если же оба клиента в активном режиме то запросы ходят замечательно вообще без хабов или иных релеев и всё прекрасно работает на той голой реализации DHT которая есть.

* работает по привязке к голому CID без url хаба, т.е. когда hint у юзера пустой, сперва ищется этот юзер по CID, а потом ему шлётся сообщение. Если помнишь когда ядро апгрейдили даже проблема была что без хинта сообщения ходят не на тот adc хаб который нужно а на первый попавшийся и приходят также.

P.S. На счёт гуя, торрентов и очереди успокоил в целом :)

P.P.S. Ах да, вот ещё что вспомнил, на счёт ЛС - там у команды очень не хватает обратного маленького ответа от получателя что сообщение получено, впрочем, как и ID сообщения, на хабах это вызывает проблемы только когда сеть (или клиент или хаб) сильно глючат, а вот в DHT будет вызывать проблемы более серьёзные, поэтому без реализации релея и подтверждения доставки делать ЛС поверх DHT хоть и можно но работать будет так себе.

Добавлено: 10 окт 2016, 13:18
HackFresse
Так что в итоге-то c DHT? Удалять нельзя оставить?

Добавлено: 11 окт 2016, 13:13
HackFresse
[2016-10-11 - 11:37:32] <HackFresse> а дхт - всё? точно, окончательно?
[2016-10-11 - 11:38:49] <HackFresse> хабы закрываются, всё меньше их. новые поднимать тяжко
...
[2016-10-11 - 11:59:33] <FlylinkDC-dev> HackFresse: у меня нет возможности допиливать dht до рабочего состояния. в том виде какой он сейчас он нах не нужен во флае
[2016-10-11 - 12:00:18] <FlylinkDC-dev> если найдется программист кому это интересно - пусть допиливает и проталкивает это в DC++ возможно только после этого что-то получится из этого
http://hub.mydc.ru/chatlog.php?date=2016-10-11

Изображение

Добавлено: 12 окт 2016, 14:38
IRainman
Паш, если нет возможности допиливать, то тогда просто выключи в настройках по умолчанию DC++ DHT и всё (SettingsManager и там поиском по "DHT"). Выпиливать из кода не надо только, ну а херить с концами тем более. Таким образом все останутся довольными. Ну ещё можно при включении диалог повесить что "функция толком не доделана и без хабов не работает с пассивными пирами. Всё равно включить?".

Прошу оставить поскольку в лице простых пользователей Флай это последний клиент на который есть хоть какая то надежда в области DC++ если и он начнёт активно херить наработки то народ окончательно разбежится из DC++.

Добавлено: 14 окт 2016, 20:59
flylinkdc
Возвращать "мертвый" код пока не планирую.
если кому понадобится его всегда можно взять в git
ну и про отключение DHT пока вспомнило всего 4 человека
p.s.
На счет разбежится из DC++ - это "и ежу понятно" собственно поэтому я ушел на интеграцию c libtorrent
если ее сделать бесшовной, то возможно флайлинк не постигнет участь eMule и Shareaz-ы

Добавлено: 16 окт 2016, 21:43
IRainman
flylinkdc писал(а):собственно поэтому я ушел на интеграцию c libtorrent
если ее сделать бесшовной, то возможно флайлинк не постигнет участь eMule и Shareaz-ы
Да, так оно и есть. В принципе я только рад. Более того буду очень рад если совместными усилиями после того как bittorrent более менее заработает во Флае, как минимум, начнёт оставаться на раздаче и научится сохранять торренты в базу. Вот после этого очень надеюсь, что совместными усилиями удастся запилить импорт resume.dat от utorrent, тогда на Флай легко можно будет даже кучу народа перетащить ибо многие уже замучались возиться с куском этого закрытого биоразложимого кода в котором элементарные проблемы не исправляются годами, а так можно будет бесшовно перейти на открытый и хороший клиент (Флай ведь и с сылками в ФС работает корректно и ещё много других вещей делает корректно, да и ресурс не сильно чтобы жрёт, ну и нормальная sqlite база, а не говённый текстовый файлик с раздачами, как в том же мюторренте и, наверняка, до сих пор в оригинальном DC++ клиенте). Ну и плюс опенсорсности: в случае необходимости можно будет просто прислать патч к коду.

Во, ещё что вспомнил, пусть и опять слегка оффтоп, но всё же это важно и по теме, раз уж сравниваем Флай с торрент клиентами, то у них это буквально попоболь у всех без исключения: у всех торрент клиентов то и дело течёт память, утекает файловый кэш! Ты недавно сделал хорошее и Флай теперь открывает файлы с помощью mapped files. Но судя по комментам в блоге забыл понизить приоритет открытия файлов клиентом и принудительный сброс данных на диск тоже не сделал и поэтому он жрёт память, ну т.е. он сам не жрёт, а вот весь файловый кэш системы успешно забивается и системе от этого плохо ;) Это тоже можно и нужно поправить. Смотреть надо в сторону флагов у CreateFile конкретно по теме кэширования https://msdn.microsoft.com/en-us/librar ... g_behavior , а также стоит приглядеться к функции FlushFileBuffers https://msdn.microsoft.com/en-us/librar ... s.85).aspx и с помощью неё периодически вызывать сброс кэша файла.
Если при работе Флая не будет течь системная память то просто орды пользователей выкинут свои торрент клиенты и переползут на Флай. В код библиотеки libtoorrent я ещё не заглядывал, но как сделана работа с файлами в самом клиенте хорошо знаю и помню, так что ссылки на CreateFile и FlushFileBuffers должны быть просто в точку. Как уточнение идеи: FlushFileBuffers можно вызывать по завершении скачивания или отдачи одного (или нескольких) или даже лучше после записи или чтения нного количества байт из файла (точнее нескольких десятков МБ, 32 МБ или даже больше, 64 или 128, не знаю) и явно стоит звать при закрытии файла ну и ещё корректировать это число в зависимости от количества открытых клиентом файлов чем больше файлов тем чаще звать FlushFileBuffers. Разумеется максимальный объём явно должен быть меньше чем количество ОЗУ на машине иначе опять всё будет плохо. Уточнять в какие функции конкретно надо лезть внутри клиента сейчас не могу, не до того ибо это надо в код Флая лезть, но я думаю что ты это очень быстро сам найдёшь. Ну и ещё важный момент: DC++, в отличии от bittorrent качает файл всегда последовательно. Однако и там и там бывают исключения. Соответственно при выставлении флагов в CreateFile этот момент нужно обязательно учесть иначе кэш опять таки будет работать не оптимально и всё тоже будет плохо.

P.S. ежу понятно, агу, я же тот самый Ёж из команды Флая и есть :-P