Ошибочные команды с DC++ хабов

Все привет.
Вчера ко мне обратился пользователь - у него файл system.log распух до 3 гиг
я поправил этот момент и исключил переполнение system.log (он мог переполняться только в ветке-бета)
но проблема оказалась глобальнее и таких хабов достаточно много 
если кто-то знает их админов - попросите поправить северные скрипты
т.к. в результате их работы все DC++ игнорируют эти ошибочные команды.
    1  "error":"[BUG][24] NmdcHub::onLine first unknown command:NmdcHub::onLine first unknown command! hub = [dchub://besthub.ro], command = [UserComman], param = [0 3]"
      1  "error":"[BUG][24] NmdcHub::onLine first unknown command:NmdcHub::onLine first unknown command! hub = [dchub://dc.focsanivn.ro], command = [UserComman], param = [0 3]"
      1  "error":"[BUG][24] NmdcHub::onLine first unknown command:NmdcHub::onLine first unknown command! hub = [dchub://dc.imsnet.ro], command = [UserComman], param = [0 3]"
      1  "error":"[BUG][24] NmdcHub::onLine first unknown command:NmdcHub::onLine first unknown command! hub = [dchub://dc.mycuk.net], command = [myinfo], param = [$all 10.11.171.60 $ $100\u0001$$99480130723$]"
      1  "error":"[BUG][24] NmdcHub::onLine first unknown command:NmdcHub::onLine first unknown command! hub = [dchub://dc.mycuk.net], command = [myinfo], param = [$all 10.11.171.60 $ $100\u0001$$99480130723$]"
      1  "error":"[BUG][24] NmdcHub::onLine first unknown command:NmdcHub::onLine first unknown command! hub = [dchub://dc.net23.info], command = [myinfo], param = [$all dryguardian)) $ $100\u0001$$103875033826$]"
      1  "error":"[BUG][24] NmdcHub::onLine first unknown command:NmdcHub::onLine first unknown command! hub = [dchub://dc.nevedem.net], command = [UserComman], param = [0 3]"

Оптимизируем поисковый 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

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

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

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

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

PtokaX 0.5.0.3

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

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


 

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

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

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

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

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

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

 

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

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

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

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