четверг, 26 марта 2015 г.

Оптимизируем поисковый UDP трафик команды $SR

В новых версия FlylinkDC++ решил убрать дублирующие UDP пакеты летящие в сторону пользователя 
выполняющего запрос файла по имени.

Расскажу алгоритм как это работает сейчас

1. Есть 2 клиента
  А - Ищет файл test-uniq-file-1212831283485474923782.txt
  B - Содержит файл test-uniq-file-1212831283485474923782.txt у себя в шаре.
2. Оба клиента сидят на нескольких хабах при этом 8 из них являются общими.

3. Клиент А вводит в поиске имя "test-uniq-file-1212831283485474923782.txt" 
и получает результат в окне поиска о том, что данный файл лежит у одного юзера 
при этом он сидит на разных хабах. (рис 1)









4. Клиент содержащий этот файл выполняет следующие операции
    - Получает от 8 хабов одинаковые поисковые запросы вида 
     $Search 185.90.227.251:24745 F?T?0?1?test-uniq-file-1212831283485474923782.txt
    - Успешно ищет указанный файл у себя в шаре (пока он это делает тоже 8 раз 
       т.к. кеширование результатов поиска добавить к флаю у меня в планах.
    - По результатам поиска клиент B посылает в клиента А по адресу 185.90.227.251:24745 
      8 почти одинаковых UDP пакетов вида (отличается только хвостовой часть где указан IP хаба с которого пришел запрос на поиск)
      (рис 2)
$SR FlylinkDC-dev3 dc++share-test-debug\test-uniq-file-1212831283485474923782.txt 50 15/15 TTH:HLRIXWDUZ5BOECFHG7OYXZ52MFOFMGETQA3TJKA (178.130.0.214:411)| 
$SR FlylinkDC-dev3 dc++share-test-debug\test-uniq-file-1212831283485474923782.txt 50 15/15 TTH:HLRIXWDUZ5BOECFHG7OYXZ52MFOFMGETQA3TJKA (5.165.63.36:411)|   
$SR FlylinkDC-dev3 dc++share-test-debug\test-uniq-file-1212831283485474923782.txt 50 15/15 TTH:HLRIXWDUZ5BOECFHG7OYXZ52MFOFMGETQA3TJKA (94.242.221.159:411)|
$SR FlylinkDC-dev3 dc++share-test-debug\test-uniq-file-1212831283485474923782.txt 50 15/15 TTH:HLRIXWDUZ5BOECFHG7OYXZ52MFOFMGETQA3TJKA (188.134.15.173:411)|
$SR FlylinkDC-dev3 dc++share-test-debug\test-uniq-file-1212831283485474923782.txt 50 15/15 TTH:HLRIXWDUZ5BOECFHG7OYXZ52MFOFMGETQA3TJKA (94.242.222.18:411)| 
$SR FlylinkDC-dev3 dc++share-test-debug\test-uniq-file-1212831283485474923782.txt 50 15/15 TTH:HLRIXWDUZ5BOECFHG7OYXZ52MFOFMGETQA3TJKA (80.93.188.135:4111)|
$SR FlylinkDC-dev3 dc++share-test-debug\test-uniq-file-1212831283485474923782.txt 50 15/15 TTH:HLRIXWDUZ5BOECFHG7OYXZ52MFOFMGETQA3TJKA (178.130.0.205:411)| 
$SR FlylinkDC-dev3 dc++share-test-debug\test-uniq-file-1212831283485474923782.txt 50 15/15 TTH:HLRIXWDUZ5BOECFHG7OYXZ52MFOFMGETQA3TJKA (80.64.175.3:411)|


 
 






Планирую сократить нагрузку на сетевую часть и убрать дубликатную передачу UDP пакетов 
в результате чего клиент А 
 - Получит только одну запись в результате поиска 
 - Имя хаба будет при этом одно (того кто первый прислал $Search).
 - Не будет тратить время на получение и обработку других 7 заведомо паразитных пакетов


Кто видит в этом что-то плохое - пишите в комменты
кто не хочет или заводить у google аккаунт - можно писать анонимно на хабе dchub://dc.fly-server.ru


воскресенье, 1 марта 2015 г.

Защита от превышения лимита GDI объектов

Привет.
У процесса Windows существует ограничение на кол-во GDI дескрипторов.
по умолчанию оно равно 10000
При достижении предельного значения гарфически интерфейс программы 
просто перестает откликаться (рис 1) помогает только снос через диспетчер задач.












C помощью такой атаки "злой админ" хаба может завалить DC++ клиент
накидав в окно много смайликов-убийц :)

В клиент FlylinkDC++ начиная с build 18323 добавлена защита от этого в виде
автоматического отключения смайлов при приближении GDI к лимиту.



воскресенье, 22 февраля 2015 г.

PtokaX 0.5.0.3

Всем привет.
Обновился хаб. в нем закрыта уязвимость
http://www.ptokax.org/news.html
Всем крупным хабам рекомендую обновиться

На уровне клиентов исправление внесены в AirDC++ и FlylinkDC++
к сожалению разработчики оригинального DC++ пока думают как это лучше исправить...


 

четверг, 12 февраля 2015 г.

Игнорируем дубликатные поиски файлов

Привет.
В новой бетке r503-build18257 добавлена функция предварительной фильтрации заведомо ложных поисковых запросов по маске. DC++ клиент сидит на множестве хабов и в него по сети летит достаточно больше кол-во запросов.
На рис 1 представлен топ запросов в моей сети:











максимальное кол-во запросов делают боты в целях выявить запрещенный контент

но т.к. боты тупые и не могут исключать дубликатные запрос к клиентам они вынуждены повторять их каждые N-минут.
но т.к. у законопослушного пользователя в шаре нет файлов, которые ищут боты
то клиент начинает выполнять рекурсивное сканирование всех файлов пока не найдет 5- 10 совпадений с маской… а это ресурсоемкая и длительная операция. в результате чего ваш комп тратит лишнее электричество.
Новая версия флайлинка блокирует подобные дубликатные запросы.
Факт игнорирования дубля отображается в CMD отладчике (рис 2)
на примере мой клиент "сжал" 9 запросов пришедших за 2 секунды с разных
хабов в поиске "аватар".






воскресенье, 8 февраля 2015 г.

deleaker - подарок для FlylinkDC++

Привет
Новые версии FlylinkDC++ избавились от некоторых утечек GDI ресурсов благодаря 
Deleaker! эта утилита подарена флайлинку как Open Source проекту от  разработчика Артема Разина
и уже помогла сделать флай лучше. Я давно использую детектор утечек памяти https://vld.codeplex.com
но он к сожалению не  "замечает" GDI и файловые дескрипторы.
в любом случае всем разработчикам GUI приложений на VC++ рекомендую попробовать 
http://www.deleaker.com
 

 


суббота, 31 января 2015 г.

DC++ лишние дисковые операции

Привет.
Когда DC++ клиент качает файл он выполняет частое открытие и закрытие временного файла *TTH.dctmp в который записываются полученные сегменты от разных пользователей
т.к. антивирусные мониторы при операции открытия файла выполняю анализ на предмет вирусни. В связи с этим рекомендуется вашему антивирусу добавить в исключение расширение файла *.dctmp - это снизит нагрузку на систему.
у себя в последних билдах FlylinkDC++ я исправил эту особенность и временный файл открывается один раз и закрывается только после того, как скачка всех сегментов файла окончательно завершится.













Ловится такая активность программой Process Monitor вот таким фильтром:








Обновить свой флайлинк до последней версии можно через
меню -> помощь -> проверка обновлений




вторник, 13 января 2015 г.

HFS от Mac в Windows чуток глючит?

Привет.
Пользователь в винде примонтировал файловую систему от MacOS (BOOTCAMP)
но у него вылез баг - при запуске флайлинка он повторно хеширует файлы расположенные на этом диске
причина оказалась в том, что размер файла показываемый под виндой всегда кратен размеру кластера
но если читать файл, то читается точный размер файла.
алгоритм хеширования через FidFile сканирует каталоги и анализирует размер файлов и временные метки
сравнивая их со значениями из базы. а в этом случае получается так, что размер файла не равен прочитанному 
в результате чего файл посылается в "вечное" повторное хеширование.
Кто встречал такое и как лучше это обойти если эта "фича" драйвера? 

Пример файла в картинках: