Ошибка обновлений + кэширующий прокси

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

 


При обновление сверяются контрольные суммы всех файлов полученные с сервера для исключения не консистентной копии.
и получается, что провайдер отдал пользователю старую версию файла
http://update.fly-server.ru/update/5xx/beta/FlylinkDC_x64.exe.bz2
меркер версии хранится в файле рядом  
http://update.fly-server.ru/update/5xx/beta/Update5_beta.xml
но этот файл был отдан уже от новой версии
Детальнее проблема описана на одном из форумов провайдера http://help.unet.by/question/details/id/361926
В чем может быть причина?
может у меня что-то не так?
или это проблема локальная и исключительно на стороне провайдера.
Может кэшу нужна привилегия на сканирования каталога
http://update.fly-server.ru/update/5xx/beta/
которую я отключил - т.к. флайлинк сам знает какие файлы качать и их прямые урлы
после чтения файла конфигурации обновки
http://update.fly-server.ru/update/5xx/beta/Update5_beta.xml

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

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

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

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

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/
и даже получил за это спасибки в его ченж-логе :)

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