вторник, 22 апреля 2014 г.

FlylinkDC++ и StrongDC++ не качают дубли TTH

Привет.

Нашел хитрый баг...
Если у пользователя в каталоге(ах) лежит два файла с одинаковым TTH
то при постановки в закачку этого каталога(ов) скачивается только один файл!

Это экономит траф, но нарушает целостность загрузки. думаю нужно исправить.
Помню в ченжлоге Greylink-а писали, что если TTH уже есть в шаре
то его скачка из сети не выполняется, а делается копия из локального диска...
вероятно так они и фиксили эту ошибку.
Оригинальный DC++ тупее - он взял и три раза скачал один и тот-же файл из сети но это правильно т.к. в каталоге действительно лежит три файла! (почему они одинаковые это уже проблема не "DC-качалки")
Для теста взял мультик - испортил его фаром чтобы был уникальный TTHи сделал 3 копии файла с разными именами.

Флай при закачке каталога "схлопнул" все файлы и закачал только "Обезьянку номер 3"
а 1 и 2 файл не закачались вообще!  :(









понедельник, 21 апреля 2014 г.

Кушаем CPU при большой очереди закачек

Привет
Часто жаловались на тормоза флая на слабых компах если в очереди много закачек. 
Нашел в коде несколько моментов:
1. При работ клиента в активном режиме на него постоянно приходит несколько десятков запросов в секунду
на поиск различных TTH.




















2. Если флай не находя данные TTH у себя в шаре (там выполняется быстрый поиск через unordered_map)
выполняет дополнительный запрос к менеджеру закачек 
в этом месте к сожалению идет линейный поиск по контейнеру т.к. ключом в мапе является имя файла а не TTH
https://github.com/pavel-pimenov/flylinkdc-r5xx/blob/f8157019835b79ab9000134444cd9a9982020ff3/client/QueueManager.cpp#L3044
https://github.com/pavel-pimenov/flylinkdc-r5xx/blob/f8157019835b79ab9000134444cd9a9982020ff3/client/QueueManager.cpp#L210
у некоторых пользователей в очереди закачек висят тысячи файлов постоянный и очень частый линейный просмотр такого 
контейнера кушает CPU в холостую т.к. вероятнее всего в очереди так-же нет файлов с такими ТТХ
тут я пока планирую завести дополнительный контейнер unordered_set где буду отслеживать наличие  TTH в очереди..
или может есть более оптимальный вариант?

3. Если TTH находится в очереди (это бывает когда вы качаете что-то популярное и большое которые одновременно все ищут) 
то выполняется создание UDP сокета
формирование информации какие части файла есть уже есть в клиенте через функцию SearchManager::toPSR
и передача UDP пакета в того кто ищет этот файл.
при этом выполняются команды разбора URL адреса на части 
в строках Util::decodeUrl(aSeeker, proto, ip, port, file, query, fragment);
а также дополнительный Socket::resolve(ip) перед посылкой UDP
пока не понял зачем делается эта операция тогда как по описанию команды в Search
в то место может попасть только IP:Port
аналогичный код   находится и в StrongDC++ в AirDC++ его немного оптимизировали
сделав UDP-Socket не временным а как мембер менеджера - он создается один раз.
Кто знает/тестировал насколько создание и разрушение UDP сокета затратная операция - наверно стоит сделать аналогично.?
другие мысли можете высказать если есть идеи в этом месте.
 

пятница, 18 апреля 2014 г.

ubuntu 14.04

Вчера успешно обновил ubuntu до 14.04 на ноутбуке
дня три погоняю и сделаю обновление на флай-сервере
и он будет скомпилирован свеженьким gcc :)



воскресенье, 13 апреля 2014 г.

четверг, 10 апреля 2014 г.

StrongDC++ sqlite build 17057

SetupStrongDC-sqlite-x64-release.exe
SetupStrongDC-sqlite-x86-release.exe  
Исходный код:
strongdc-243-sqlite-src-r17057-2014.04.11-19.30.31.7z

Изменения:
* В окне поиска добавлен вывод медиа информации для оценки качества видео и звука 
  (отключается галкой использования fly-server-а)
* Кнопки поиска поднял вверх т.к. их иногда не видно если программа запускается на нетбуке с разрешением по Y 800 точек.



пятница, 4 апреля 2014 г.

StrongDC++ sqlite давно не обновлял...

Публикую тест-версию.
Просьба протестировать под нагрузкой - вдруг что-то сломал
Изменения:
  • Обновлены внутренние либы OpenSSL,SQLite, mediainfo, miniupnp
  • Научил показывать дополнительную медиа-информацию в файл листах пользователей клиентов, которые ее не отдают (для получения информации используется асинхронный запрос к fly-server - естественно данную фичу можно отключить в найтройках)
  •  Блокируем потенциальные вирусы в результате поиска
В планах добавить:











p.s.
А кто поставил 3 минуса :) - отпишите что не понравилось?

вторник, 25 марта 2014 г.

Ошибка закачки файлов с длинными именами

В DC++ клиентах найдена проблема.















Пример файла TTH = 7RNOHVHMMYX6TMHUKBXZ2I42MYCCVZSTNRY273I
он у некоторых пользователей имеет имя

Носов Евгений, Павлов Сергей, Пидоренко Игорь, Пищенко Виталий, Пухов Михаил, Пьянкова Таисия, Силецкий Александр, Сыч Евгений, Ткаченко Игорь, Федотов Дмитрий, Чарушников Олег, Шалин Анатолий - Румбы фантастики. 1988 год. Том II.fb2

После беглого просмотра скрина ошибки SCALOlaz выдал прикольную версию - виновен третий писатель этой коллекции электронных книг :) ... но ошибка оказалось совсем в другом

Windows накладывает ограничение на максимальную длину пути= 260 (MAX_PATH)
Длина этого имени файла 233 символа.

Смотрим на алгоритм получения временного файла для закачки в оригинальном DC++
данный код без изменений мигрировал во все дочерние клиенты.
dcplusplus\dcpp\QueueItem.cpp

namespace {
    const string TEMP_EXTENSION = ".dctmp";

    string getTempName(const string& aFileName, const TTHValue& aRoot) {
        string tmp(aFileName);
        tmp += "." + aRoot.toBase32();
        tmp += TEMP_EXTENSION;
        return tmp;
    }
}

он приводит к тому, что итоговый размер имени файла становится
на 46 символов длиннее т.к. к нему приписывает TTH, точка и временное расширение .dctmp
а это приводит к гарантированной ошибке открытия временного файла
в классе SharedFileStream 233 + 44 > 260

В ветках r5xx и r4xx данная проблема уже исправлена.