четверг, 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 к лимиту.