В новых версия 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
четверг, 26 марта 2015 г.
воскресенье, 1 марта 2015 г.
Защита от превышения лимита GDI объектов
Привет.
У процесса Windows существует ограничение на кол-во GDI дескрипторов.
по умолчанию оно равно 10000
При достижении предельного значения гарфически интерфейс программы
просто перестает откликаться (рис 1) помогает только снос через диспетчер задач.
C помощью такой атаки "злой админ" хаба может завалить DC++ клиент
накидав в окно много смайликов-убийц :)
В клиент FlylinkDC++ начиная с build 18323 добавлена защита от этого в виде
автоматического отключения смайлов при приближении GDI к лимиту.
У процесса Windows существует ограничение на кол-во GDI дескрипторов.
по умолчанию оно равно 10000
При достижении предельного значения гарфически интерфейс программы
просто перестает откликаться (рис 1) помогает только снос через диспетчер задач.
C помощью такой атаки "злой админ" хаба может завалить DC++ клиент
накидав в окно много смайликов-убийц :)
В клиент FlylinkDC++ начиная с build 18323 добавлена защита от этого в виде
автоматического отключения смайлов при приближении GDI к лимиту.
Подписаться на:
Сообщения (Atom)