пятница, 19 декабря 2014 г.

FlylinkDC++ и Doctor Dump

Всем привет.
Успешно обновился на новую версию сбора и анализа дампов падения.
Фалйлинк за 2 года использования сервиса https://drdump.com стал стабильнее и было 
исправлено львиная доля ошибок не повторяющаяся на конфигурации разработчика
Приведу два последних примера быстрой локализации проблемы с помощью "доктора-дампа"
1. После перехода на VC++2013 я не знал, что он по умолчанию включает
опцию использования инструкций SSE2 и этом привело к тому, что пользователи 
на старых процессорах типа Athlon XP после получения обновлений
сразу начали падать при инициализации openssl
я успел это заметить после получения 23 дамп 
(вероятно эти 23 человека сразу снесли глючный флайлинк и больше никогда его не поставят) 
без доктора - эта цифра была-бы больше:-(
Программой пользуются в отдаленных уголках СНГ где такой старый 
процессор еще считается нормальным... я думаю быстрым фиксом я спас остальных 
обладателей этого процессора
https://drdump.com/Problem.aspx?ProblemID=102637

















2.  Ошибка в реализации функции pow при использовании компилятора VC++2013 старых версий винды
https://drdump.com/Problem.aspx?ProblemID=102616

В данном случае задето меньше пользователей
т.к. она возникла только у тех у кого виста или 7-ка без SP1
падало при хешировании новых медиа-файлов в mediainfo-lib
Ошибка оказалась известная и способ обхода описан в инете.
Быстро пофкисил во флайлинке падение и выпустил обновление
 + послал патч автору библиотеки medainfo
http://sourceforge.net/p/mediainfo/code/6567/
и даже получил за это спасибки в его ченж-логе :)






суббота, 13 декабря 2014 г.

sqlite + levelDB

Всем привет.
Для нормальной работы серверной части флайлинка я смог подобрать только один хостинг- digitalocean
т.к. он единственный кто выдает хорошие iops-ы и позволяет держать текущую нагрузку
(возможно у меня кривые руки - я ищу способы их сровнять :)

но возникла проблема с дисковым пространством т.к. база постоянно пополняется 
а SSD пока не очень дешевые и когда размер sqlite базы добрался до 12 гб я 
пересмотрел алгоритм работы флай-сервера и унес редко-используемые данные в LevelDB 
с прозрачной компрессии  snappy

В итоге получилась следующая картинка по диску: 
  • 2.7GiB [##########] /media-db-compress.leveldb 
  • 1.7GiB [######    ]  fly-server-db.sqlite
Вся серверная часть написана на С++ с использованием https://github.com/cesanta/mongoose

Подробности миграции обсуждал тут
http://www.sql.ru/forum/1118531/vybor-bd-dlya-optimalnogo-hraneniya-musorki-json-ov



пятница, 21 ноября 2014 г.

Проблемка DC++ если шарятся очень большие коллекции файлов

Всем привет!
Недавно мне показали в DC++ сети пользователя с шарой 350 Tb! (рис 1) 
6.5 миллиона файлов 259 тыс каталогов - 
Файл лист в сжатом bz2 виде занимает 197 мб - после декомпрессии получается  xml в 733 мб
Флалинк парсит этот список на моем i7 компе 60 сек!












Теперь рассмотрим алгоритм обслуживания поисковых запросов в DC++
для случае если такой жирный пользователь сидит на большом кол-ве хабов.
Если открыть окно CMD отладчика то можно увидеть, что клиент ежесекундно
получает пачку поисковых запросов
(на моем компе активно около 30 хабов случае это около 40-80 штук)

Запросы делятся на 2 вида:
1. Точный запрос поиска по TTH вида
  $Search Hub:Indie F?T?0?9?TTH:KEWX74O4YGFIT3WGE3LYK43QXMVYORJPWVLUWUA
2. Поиск по подстроке(клиенты ищут файлы без учета регистра)
  $Search Hub:UserDDD_1313 F?T?0?7?Unforgettable
Первый вид запросов практически не напрягает программу т.к. вся шара пользователя загружена в оперативную память в хеш таблицу (std::unordered_map) где ключом является TTHValue - 24 байта
если пренебрегать возможными коллизиями хеш-функции поиск идет мгновенно вот в этом месте:
https://github.com/pavel-pimenov/flylinkdc-r5xx/blob/e92a7f560a19bb3122106efe6d25721ee00fb770/client/ShareManager.cpp#L2144

Второй запрос немного сложнее и тут выполняется 2 шага.
2.1 Полученную подстроку подают на вход bloom-фильтра который быстро отвечает на вопрос - стоит ли искать ее в шаре или нет.
2.2 Если bloom сказал, что вероятно объект с таким именем у вас в шаре имеется то стартует самая последняя и тяжелая ветка алгоритма - рекурсивный обход всего дерева каталогов и файлов шары:
https://github.com/pavel-pimenov/flylinkdc-r5xx/blob/e92a7f560a19bb3122106efe6d25721ee00fb770/client/ShareManager.cpp#L2205
В результате обхода собирается ответ из 5 или 10 первых совпадений и возвращает результат назад запросившему пользователю.
 - Если запросивший пользователь активный, то ему посылается UDP пакет на указанный порт (собственно поэтому если юзер думает что он активный и UDP порт закрыт - не работает поиск)
 - Если запросивший юзер пассивный, то ответ идет по TCP на хаб с указанием ника кому форварднуть ответ о том, что по его запросу найдены файлы.

Проблема не эффективного потребления CPU в DC++ клиентах возникает когда владелец толстой шары сидит на более чем 1 хабе.

Возьмем наш лог из CMD отладчика (FlylinkDC++ недавно научился его сохранять в файл по галке в настройках)
и выберем строки где идет поиск по подстроке Unforgettable
Обратите внимание на временные метки и адреса хабов с которых приходили запросы.
Получается что за секунду прилетело 7 одинаковых(!) запросов от одного юзера
совместно с вами сидящем на разных хабах (рис 2)
По текущему алгоритм клиент получив эти запросы в разных потоках обслуживающих эти хабы
по очереди обращается к менеджеру шары и постоянно ищет одно и то-же.
Если bloom фильтр не отрубает эту подстроку на входе, то затраты на поиск возрастают пропорционально кол-ву файлов и каталогов в шаре.
 










я внес мелкое исправление https://code.google.com/p/flylinkdc/source/detail?r=17886#
в менеджер шары флайлинка где попытался убрать эту лишнюю нагрузку
с помощью заведение дополнительной хеш-таблицы.

Алгоритм работы такой:
1. Получаем запрос на поиск подстроки от клиента-1 и выполняем рекурсивный поиск. Если не находим ее в шаре сохраняем строку  в хеш-таблице.
2. С большой вероятностью в течении секунды к нам в менеджер шары прилетает еще таких-же запросов от клиентов 2-N
перед тяжелым рекурсивным обходом дерева - мы смотрим в нашу промежуточную табличку по ключу - подстрока поиска если находим ее там - сразу уходим т.к. в нашей шаре такого объекта не нашлось и мы это определили на шаге (1)
3. Если в вашу шару добавляются файлы - деваться некуда чистим эту временную мапу
4. На минутном таймере смотрим размер этой таблицы и если он больше 1000 - тоже чистим
    число 1000 выбрал с потолка - на выходных потестю подробнее но лимит нужен чтобы не утекала память при большом кол-ве разных запросов.

Новой бетки с этими изменениями пока нет - появится вечером.
Желающие могут покритиковать-улучшить алгоритм т.к. возможно я что-то не учел.
не хочется сломать ключевую функцию клиента - поиск который и так из за NAT-работает не очень :-)

 

воскресенье, 16 ноября 2014 г.

FlylinkDC++ и Visual C++ 2013

Планирую перейти на VC++2013
в автообновление пока не помещал - просьба протестировать новый билд и отписать о результатах
http://www.fly-server.ru/install/r5xx/src-bin/r503-vc2013
в Favorites.xml 483 - хаба  - ввизуально стартует быстрее и памяти немного меньше кушает

Размер FlylinkDC_x64.exe 12407968 (VC++2010)

RAM - 333 Mb











Размер FlylinkDC_x64.exe 11805856 (VC++2013)
RAM -  318 Mb

 

пятница, 7 ноября 2014 г.

Автоматический переход в пассивный режим.

Привет.
В последней бетке реализован автоматический _временный_ переход в пассивный режим если не смогли скачать в активном.
для теста можете авто обновиться или забрать бинарники 
тут http://www.fly-server.ru/install/r5xx/src-bin/

Алгоритм работы:
* Если клиент настроен как "активный" а по факту порты закрыты (мешает NAT, программный фаервол) 
   при попытке подключиться к пользователю по команде $ConnectToMe - клиент бесконечно висел в ожидании.
   неподготовленный пользователь в этом случае - сносил FlylinkDC++ :)
* Сейчас после 60 секунд ожидания клиент переходит в пассивный режим и повторяет попытку подключения 
  через команду $RevConnectToMe
* Если попытка удалась - происходит скачка контента при этом в прогрессе рисуется "кирпичная стенка"
* После завершения операции клиент возвращается в активный режим.
Кто разбирается в протоколе - подскажите какие проблемы вы видите в этом случае.
Пока пришлось выполнять посылку команды $MyINFO сообщающей хабу
что мы перешли в пассив - это сделано для Verlihub хотя другие хабы 
в частности PtokaX не требуют этой посылки и принимают команду $RevConnectToMe 
даже если клиент ранее сообщил что он активный.
мне это не совсем нравится т.к .приводит к лишнему спаму MyINFO туда-сюда...
что может привести к блокировке юзера на хабе напичканы хитрыми скриптами...
обычно нельзя часто слать MyINFO - от спама даже в клиенте есть защита на 2 минут.
пишите в комментарии или подрубайтесь к хабу dchub://dc.fly-server.ru
там можно анонимно пообщаться :)

суббота, 11 октября 2014 г.

DDoS атака на сервера флайлинка

Всем привет.
9-10 числа были перебои с обновлением FlylinkDC++
а также не работал DHT bootstrap сервер.
Причина: атака анонимных "хакеров" они положили сразу два VPS сервера
на третий media.fly-server.ru или сил не хватило, или в digitalocean
есть встроенная защита от DDoS
http://www.fly-server.ru/munin/www/localdomain/localhost.localdomain/fw_conntrack.html
http://109.120.164.244/munin/localdomain/localhost.localdomain/fw_conntrack.html




























Почти все сервисы, которые сломали атакой перевел на другой сервер
если заметите баги или тормоза пишите на почту pavel.pimenov@gmail.com

Новый сервер не использует виртуализацию
он не очень мощный, но думаю для авто обновления ресурсов хватит
http://37.187.111.84/munin/localdomain/localhost.localdomain/index.html



четверг, 2 октября 2014 г.

Вирусы - подсказываем зараженный каталог

Добрый вечер!
Начиная с билда 17658 у FlylinkDC++ ветки r5xx 
добавлена визуализация зараженного каталога
у подозрительного пользователя:










новая версия доступна на канале авто обновления (beta)
или портабельные сборки тут  http://www.fly-server.ru/install/r5xx/src-bin
FlylinkDC-r503-x64-beta95-build-17658-2014.10.02-23.30.54.7z
FlylinkDC-r503-src-beta95-build-17658-2014.10.02-23.18.57.7z
FlylinkDC-r503-x86-beta95-build-17658-2014.10.02-23.18.11.7z