Показаны сообщения с ярлыком обсуждения. Показать все сообщения
Показаны сообщения с ярлыком обсуждения. Показать все сообщения

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

Сохраняем историю обмена файлами в базе sqlite

Несколько раз меня пользователи просили приделать эту функцию
т.к. искать по логам не удобно.
С билда 18034 на бета-канале в автообновлении
или тут http://www.fly-server.ru/install/r5xx/beta/
доступна новая версия.
Пользователям с большой нагрузкой по трафику прошу протестировать
насколько эта операция окажется ресурсоемкой (зависания и т.д.)
Об ошибках пишите на почту [email protected]
или анонимно в чат поддержки dchub://dc.fly-server.ru











Вся информация хранится в базе данных FlylinkDC_transfers.sqlite
в виде одной не нормализованной таблицы (рис 2)
Этот файл всегда можно безболезненно удалить
потеряется только история закачек/отдач











В планах добавить
- Поиск по атрибутам
- Настройку ротации файла для удаления старых записей
- Сохранение статистики от кого получены сегменты файла (возможно оно не нужно)
- Экспорт в Эксель
- Что-то еще.... предлагаете.


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

sqlite + levelDB

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

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

В итоге получилась следующая картинка по диску: 
  • 2.7GiB [##########] /media-db-compress.leveldb 
  • 1.7GiB [######    ]  fly-server-db.sqlite
Вся серверная часть написана на С++ с использованием http://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 байта
если пренебрегать возможными коллизиями хеш-функции поиск идет мгновенно вот в этом месте:
http://github.com/pavel-pimenov/flylinkdc-r5xx/blob/e92a7f560a19bb3122106efe6d25721ee00fb770/client/ShareManager.cpp#L2144

Второй запрос немного сложнее и тут выполняется 2 шага.
2.1 Полученную подстроку подают на вход bloom-фильтра который быстро отвечает на вопрос - стоит ли искать ее в шаре или нет.
2.2 Если bloom сказал, что вероятно объект с таким именем у вас в шаре имеется то стартует самая последняя и тяжелая ветка алгоритма - рекурсивный обход всего дерева каталогов и файлов шары:
http://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 фильтр не отрубает эту подстроку на входе, то затраты на поиск возрастают пропорционально кол-ву файлов и каталогов в шаре.
 










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

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

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

 

пятница, 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




























Почти все сервисы, которые сломали атакой перевел на другой сервер
если заметите баги или тормоза пишите на почту [email protected]

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



вторник, 22 апреля 2014 г.

FlylinkDC++ и StrongDC++ не качают дубли TTH

Привет.

Нашел хитрый баг...
Если у пользователя в каталоге(ах) лежит два файла с одинаковым TTH
то при постановки в закачку этого каталога(ов) скачивается только один файл!

Это экономит траф, но нарушает целостность загрузки. думаю нужно исправить.
Помню в ченжлоге Greylink-а писали, что если TTH уже есть в шаре
то его скачка из сети не выполняется, а делается копия из локального диска...
вероятно так они и фиксили эту ошибку.
Оригинальный DC++ тупее - он взял и три раза скачал один и тот-же файл из сети но это правильно т.к. в каталоге действительно лежит три файла! (почему они одинаковые это уже проблема не "DC-качалки")
Для теста взял мультик - испортил его фаром чтобы был уникальный TTHи сделал 3 копии файла с разными именами.

Флай при закачке каталога "схлопнул" все файлы и закачал только "Обезьянку номер 3"
а 1 и 2 файл не закачались вообще!  :(









понедельник, 21 апреля 2014 г.

Кушаем CPU при большой очереди закачек

Привет
Часто жаловались на тормоза флая на слабых компах если в очереди много закачек. 
Нашел в коде несколько моментов:
1. При работ клиента в активном режиме на него постоянно приходит несколько десятков запросов в секунду
на поиск различных TTH.




















2. Если флай не находя данные TTH у себя в шаре (там выполняется быстрый поиск через unordered_map)
выполняет дополнительный запрос к менеджеру закачек 
в этом месте к сожалению идет линейный поиск по контейнеру т.к. ключом в мапе является имя файла а не TTH
http://github.com/pavel-pimenov/flylinkdc-r5xx/blob/f8157019835b79ab9000134444cd9a9982020ff3/client/QueueManager.cpp#L3044
http://github.com/pavel-pimenov/flylinkdc-r5xx/blob/f8157019835b79ab9000134444cd9a9982020ff3/client/QueueManager.cpp#L210
у некоторых пользователей в очереди закачек висят тысячи файлов постоянный и очень частый линейный просмотр такого 
контейнера кушает CPU в холостую т.к. вероятнее всего в очереди так-же нет файлов с такими ТТХ
тут я пока планирую завести дополнительный контейнер unordered_set где буду отслеживать наличие  TTH в очереди..
или может есть более оптимальный вариант?

3. Если TTH находится в очереди (это бывает когда вы качаете что-то популярное и большое которые одновременно все ищут) 
то выполняется создание UDP сокета
формирование информации какие части файла есть уже есть в клиенте через функцию SearchManager::toPSR
и передача UDP пакета в того кто ищет этот файл.
при этом выполняются команды разбора URL адреса на части 
в строках Util::decodeUrl(aSeeker, proto, ip, port, file, query, fragment);
а также дополнительный Socket::resolve(ip) перед посылкой UDP
пока не понял зачем делается эта операция тогда как по описанию команды в Search
в то место может попасть только IP:Port
аналогичный код   находится и в StrongDC++ в AirDC++ его немного оптимизировали
сделав UDP-Socket не временным а как мембер менеджера - он создается один раз.
Кто знает/тестировал насколько создание и разрушение UDP сокета затратная операция - наверно стоит сделать аналогично.?
другие мысли можете высказать если есть идеи в этом месте.
 

вторник, 25 марта 2014 г.

Ошибка закачки файлов с длинными именами

В DC++ клиентах найдена проблема.















Пример файла TTH = 7RNOHVHMMYX6TMHUKBXZ2I42MYCCVZSTNRY273I
он у некоторых пользователей имеет имя

Носов Евгений, Павлов Сергей, Пидоренко Игорь, Пищенко Виталий, Пухов Михаил, Пьянкова Таисия, Силецкий Александр, Сыч Евгений, Ткаченко Игорь, Федотов Дмитрий, Чарушников Олег, Шалин Анатолий - Румбы фантастики. 1988 год. Том II.fb2

После беглого просмотра скрина ошибки SCALOlaz выдал прикольную версию - виновен третий писатель этой коллекции электронных книг :) ... но ошибка оказалось совсем в другом

Windows накладывает ограничение на максимальную длину пути= 260 (MAX_PATH)
Длина этого имени файла 233 символа.

Смотрим на алгоритм получения временного файла для закачки в оригинальном DC++
данный код без изменений мигрировал во все дочерние клиенты.
dcplusplus\dcpp\QueueItem.cpp

namespace {
    const string TEMP_EXTENSION = ".dctmp";

    string getTempName(const string& aFileName, const TTHValue& aRoot) {
        string tmp(aFileName);
        tmp += "." + aRoot.toBase32();
        tmp += TEMP_EXTENSION;
        return tmp;
    }
}

он приводит к тому, что итоговый размер имени файла становится
на 46 символов длиннее т.к. к нему приписывает TTH, точка и временное расширение .dctmp
а это приводит к гарантированной ошибке открытия временного файла
в классе SharedFileStream 233 + 44 > 260

В ветках r5xx и r4xx данная проблема уже исправлена.



воскресенье, 16 марта 2014 г.

Блокируем потенциальные вирусы в результате поиска

Привет.
Добавлена дополнительная фильтрация результатов поиска на клиенте.
если пользователь указал при запросе тип файла не равный
  - Исполняемый
  - Любой
  - Каталог/Папка
и при этом если внешний клиент возвращает на такой запрос файлы с расширением исполняемого типа
  ".exe", ".com",".msi", ".app", ".bat", ".cmd", ".jar", ".ps1", ".vbs", ".wsf"
 то считаем это 99% вирусом и не показываем данные файлы в окне поиска + логируем.

Подобным образом, вероятно, ведут себя  боты, которые на любой поисковый запрос генерируют ответ на
исполняемый файл нужного имени. - пользователь его по ошибке качает, запускает и заражает свою систему.












Спасибо пользователю с ником"переподвыподверт" http://dchublist.ru/forum/viewtopic.php?p=22426#p22426  за найденную проблему
Функция появится в обновлении флайлинка с build >= 16865
+ после тестирования волью в ветку r4xx


суббота, 15 марта 2014 г.

Подсказка о возможном вирусном файле

Всем привет.
Добавлена подсказка о возможных вирусных файлах в окнах поиска и файл-листов
Подсказка выполняется пока в виде подмены иконки:
  • "Термометр" расширения вида "exe.exe"(Если кто-то знает еще хитрые комбинации расширений в которых как правило маскируют вирус - пишите я дополню коллекцию)
  • "Синий чемоданчик с красным крестом" - медиафайлы + расширение .exe
Списки обновляются в онлайне медиа-файлы на текущий момент содержат расширения    3gp,avi,divx,flv,m4v,mkv,dts,mov,mp4,mpg,mpeg,vob,wmv,bik,qt,rm,aac,ac3,ape,
fla,flac,m4a,mp1,mp2,mp3,ogg,wma,wv,mka,vqf,lqt,ts,tp,mod,m2ts,webm 


Данная версия доступна на бета-канале авто-обновления.



суббота, 25 января 2014 г.

Проблема разрушения базы sqlite

Привет!
Мне периодически присылают письма об ошибке открытия базы
как правило пользователи сообщают о том, что перед этим возникает или отключение питания, или синий экран падения винды
по собранной статистики таких случаев не так много  211 разрушений базы из 133 тыс флаев но они есть.
















я пока не знаю как лучше автоматически полечить эту проблему кроме как удаления базы данных и  ее повторное создание
тут есть побочный эффект - дополнительный рехэш шары т потеря статистики.

В Google Chrome есть код на детект убитой базы sqlite
chromiumtrunk\src\chrome\browser\diagnostics\sqlite_diagnostics.cc
но детально как они восстанавливают базу я не изучил....

у кого есть какие мысли?
p.s.
пример ошибки присылаемой пользователями:

четверг, 23 января 2014 г.

Тест корректного проброса портов

Привет.
С бетки 23 во флайлинк встроена функция тестирования доступности указанных в конфигурации портов со стороны внешнего сервера.
зеленые иконки, будут говорить о корректной настройки сетевой части.






 






раньше этой функцией занимался скрипт http://flylinkdc.com/test.php
но у него был недостаток - он не поддерживал тест UDP порта, т.к. со стороны сервер нельзя узнать
долетел пакет до клиента или нет.
В текущей реализации это исправлено.
Алгоритм работы такой
1. Клиент шлет на сервер json с указанием портов, какие нужно проверить
{
 "CID":"S7IVMBQPT23U3WN2AONV2UTAPL3NGA6GARBXXXA",
 "tcp": [  {  "port":15234 } ], "udp": [  {  "port":16237  },  {   "port":22094  } ]
}
2. Сервер получает запрос и запускает нитку выполняющую обратную передачу специального пакета на указанные порты  

посылка имеет формат $FLY-TEST-PORT S7IVMBQPT23U3WN2AONV2UTAPL3NGA6GARBXXXA91.192.99.251:15234|
3. Слушающие сокеты на стороне флая обрабатывают такую посылку, сравнивают CID и зажигают лампочки зеленым цветом.
Пока сильно не распространилось - критикуйте реализацию, может что-то криво или не учел чего...а может что-то добавить
бонусом этого запроса является получения вашего внешнего WAN IP
соответственно обращенеи к http://checkip.dyndns.com не требуется.

Следующим шагом  для помощи проблем в районе сети будет детект открытости приложения в фаерволе винды а также его автоматическое добавление.
подобное уже реализовано в мастере первичной настройке.
но я нашел немного другую реализацию в гугл-хроме 
chromium\home\src_tarball\tarball\chromium\src\third_party\libjingle\source\talk\base\winfirewall.*
попробую ее.

четверг, 16 января 2014 г.

FlylinkDC++ и проблема: не работает поиск!

Всем привет.

Решил уделить внимание топовому вопросу на всех хабах
"программа ничего не находит!"
Данную тему буду обновлять по мере поступления вопросов и разбора каждой конкретной ситуации.

Для упрощения сбора проблем реализовано:
1. В интерфейсе поиска добавлена функция тестирования UDP используемого для поиска в активном режиме.
2. Добавлена вторая маленькая кнопочка поиска
   позволяющая выполнить запрос в пассивном режиме через хаб - должна помочь найти, если    пользователь еще не научился включать upnp и не разобрался, как открывать порты руками.
3. Добавлен линк на данную страницу, чтобы пользователь у кого не работает поиск зашел сюда и прочитал инструкции или отписал свою уникальную ситуацию.

Причина 1  - Программный фаервол.
Временно отключаем его - если помогает, значит виноват он и ищем
   в инете способ добавления программы в исключения применительно к своей программе.
   ссылки на описания основных фаерволов

http://www.dslreports.com/faq/dc/3.1_Software_Firewalls
http://dcplusplus.sourceforge.net/webhelp/faq_unblock.html
(кто найдет лучше и на русском в картинках кидайте ссылки - дополню тему)
Общая рекомендация - все фаерволы имеют режим обучения при старте приложения он спрашивает разрешение для добавления приложения в доверенные - сделайте это и программный фаер не будет мешать.


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

Вирусные хранилища в сети DC++

Всем привет.
Обращаюсь к тем, кто качает различный софт из DC++
к сожалению в сети на некоторых хабах сидят пользователи(вероятно всего это боты) и раздают вирусы в виде
exe-шников переименованные под популярные программы/кряки.
Если вы скачали подобный исполняемый файл, то перед запуском обязательно проверьте его через http://www.virustotal.com
т.к. многие антивирусы могут реагировать с задержкой.

Я нашел одного такого пользователя и провел тест на файле
MAC OS X Snow Leopard v.10.6.7 Hackintosh Atkos s3v2.exe
TTH - 22HIIKYTW3YM7IH35MZK4YIIYGAZOYHNOMACH5A

Пока скачал и отправил на virustotal юзер уже пропал (возможно он пропадает сразу после того как с него что-то скачают :)
Проверка дала вот такой результат только 8 из 47 нашли в файле заразу. 
также обратите внимание что популярный халявный avast промолчал.
Следующий шаг - сделал поиск уже по имени файла т.к. мой первый TTH пропал из сети
скачал другую версию этого файла. на этот раз она оказалась более старой и 
ее детектировало большее кол-во антивирусов (35 из 47)


Пока не придумал как защититься от подобного в клиенте...
при открытии файл-листов можно легко детектировать рассадник, но ведь пользователи качают подобное сразу из окна поиска
без загрузки файл-листов... в общем пока думаю.
Если у вас есть идеи как флайлинк может помочь не качать вирусы неподготовленным пользователям
можете отписать соображения в данную тему, или мне на почту. [email protected]

Замеченные особенности подобных вирусных хранилищ
 1. Если отрыть файл лист пользователя, то у него в шаре каталог и много (10-30 тыс)  exe файлов 
     с разными именами почти одинакового размера 0.5Мб-1Мб
     у некоторых файлов одинаковый TTH









 2. Подобные пользователи сидят на большом кол-ве хабов и периодически меняют ники
и скорость от них очень хорошая.
















3. Если поискать по имени файла, то TTH и размеры файлов у разных пользователей отличаются.





воскресенье, 6 октября 2013 г.

Исходники FlylinkDC++ на github

Всем привет.
Гугл не отвечает :(

Перенес исходный код ветки r5xx в последнем состоянии под github
http://github.com/pavel-pimenov/flylinkdc-r5xx

История изменений сохранилась под bzr 
http://code.launchpad.net/~vcs-imports/flylinkdc/trunk
но это только ствол и без svn::externals
Вся база данных issue потеряна
Полной копии svn - репозитария у меня не делалась т.к. я не думал, что гугл может закрыть проект без предупреждения
если что-то не компилируется из github - пишите будем разбираться. 

Обязательно делайте бэкапы своих проектов

 

пятница, 4 октября 2013 г.

FlylinkDC++ удален с гугла

Всем привет.

Вчера вечером меня на сайт не пустило.
http://code.google.com/p/flylinkdc
Предварительно никто не предупреждал
поддержка тоже пока ничего не ответила.
все, кто пользуется svn - доступа к исходникам пока нет.
я в такой ситуации первый раз, но тут или техническая ошибка,
или кто-то пожаловался им и нашел в репки какое-то нарушение.

Меня в репозитарий тоже не пускает так:








У других вот такая картина:














Если кто-то сталкивался - отпишите как вы поступали?
я даже не делал зеркало всей репки :(
и обидно, что база issue потеряется

пятница, 20 сентября 2013 г.

Изменения r501 - > r502

Всем привет.
В 502 ветке внесено много изменений в результате чего клиент стал запускаться и сносно работать на старых нетбуках Atom 1.6 + 1 гиг RAM

Всем у кого слабый комп предлагается обновиться с r501 до r502-rc1
через функцию меню и оценить производительность клиента.








Провел тест на своей системе на коллекции хабов ~140 приложенных к проблеме
http://code.google.com/p/flylinkdc/issues/detail?id=1242

* Версия r501-release-build-13693
Потребление памяти  = 573M
Потребление GDI объектов = 8651
(у windows на процесс лимит - 10000 после превышения приложение умирает)














* Текущий релиз-кандидат r502-rc1-build-15449
Потребление памяти  = 289M
Потребление GDI объектов = 2061

воскресенье, 15 сентября 2013 г.