issue-843-fly-server-x64-x86-test-3.7z
С исходным кодом всей реализации данной функции можно познакомиться в ветке:
svn co http://flylinkdc.googlecode.com/svn/branches-dev/ppa/issue-618-mediainfo
Заранее спасибо за замечания.
Изменения в test-3
- На сервер передаются только те элементы, которые видны в окне результатов поиска
- По мере скроллирования окна на сервер досылаются запросы (с интервалом 5 секунд) после получения результата записи по которым есть сведения - немного темнеют (10%).
- На стороне сервер исправлен баг в обработке запросов размером более 64к)
- Снял видеоролик как это работает "Поиски Шрэка" (fly-server-shrek-search-demo.flv )
- Обмен информацией выполняется даже если не собрана расширенная инфа, собранная в FlylinkDC_mediainfo.sqlite (данная таблица заполняется только при новом хешировании)
- Со стороны сервера поправлен возврат параметра fly_xe - разрешение видео
- Добавил x64
Для увеличения активность - открыл доступ анонимам :)
Особенности и идея алгоритма:
* Клиент не меняет протокол.
* Ветка после успешного тестирования будет встроена в r4xx и StrongDC++ sqlite
* Для обмена используется www –сервер и алгоритм обработки пока реализован на C/C++
* База данных – sqlite (после анализа нагрузки подменю на другую – cassandra?)
* Модель хранения данных очень простая
- Мастер таблица TTH+size + счетчики популярности, фейков и т.д.
- Дочерняя таблица в модели EAV для сохранения дополнительной атрибутной информации.
* У каждого клиента информация о характеристиках медиа-файла будет храниться локально в дополнительной базе данных FlylinkDC_mediainfo.sqlite. В результате использования функции поиска «постепенно» передаваться на хранение в облако. Одновременно с этим клиент будет запрашивать у облака информацию о файлах, которые попадаю под критерии поиска и в случае успешности - получать результат и визуализировать его.
* После регистрации нового TTH на сервере, фоновый процесс будем дополнять объект признаками
- Ссылки на dcmagnets.ru и другие порталы
- Рейтинги этого объекта на указанных порталах и т.д.
* После анализа нагрузки планируется попробовать работу без www - прослойки на чистых сокетах. (для серверной части пока тестировал libevent – может что-то еще посоветуете?)
Ссылки на предыдущие тестовые - версии (Качать не рекомендуется)
issue-843-fly-server-test-1.7z
issue-843-fly-server-x64-x86-test-2.7z
Сообщения
19 комментариев:
не боитесь, что когда функция попадёт в release, 20000 клиентов задосят вам любой веб-сервер?
надёжнее ведь было разработать медиа-базу поверх протокола DHT.
Спасибо за первый отзыв.
Этого боюсь а также размеры будущей базы)
Но как сделать через DHT не смог придумать :(
Пока прорабатывается просто интерфейс.
если идея вообще заработает - научу клиента работать и другими способами.
Сейчас это конфигурируется на лету вот таким файлом
http://flylinkdc-update.googlecode.com/svn/trunk/etc/flylinkdc-config.xml
В нем можно настроить какие файлы попадают под обмен,протокол и фильтрация.
Сервер точно задосит, придется урезать
На этот случай я думаю сделать такую штуку.
В конфигурации будет описано несколько серверов, каждый будет вести статистику по нагрузке и при активации регистрироваться на центральном узле - оформляя подписку на репликацию и готовность прием соединений на порт X
Клиенты периодически будут обращаться к этому списку серверов узнавать нагрузку и выбирать наименее загруженный.
Для упрощения можно и рандомно выбирать любой из активных.
Тут нужно найти распределенную базу данных, которая умеет реплицироваться автоматом разрешая конфликты - я пока не сильно изучал этот вопрос. но по-моему подходит noSQL
у меня модель как-раз key-значение
Если не найду - аналог можно и самому написать на базе любого sql-сервера - имхо там все просто.
А мелкие задержки в инфе тут не критичны - не банковские проводки кидаем :)
Много гемора, вы написали большой велосипед. Если фишка работает только между последними версиями флая, почему нельзя было сделать передачу данных напрямую между клиентами? Создатели стронга стараются децентрализовать сеть вводя DHT, а вы наоборот всё на свои сервера вешаете. Сначала понадобится один сервак, потом два и вскоре всеравно придется отказаться от этого решения.
Велосипед тут пока очень маленький :)
Сейчас отлаживается JSON-интерфейс между клиентом и другим компом (просто сейчас он называется выделенным сервером)
А сервер выбран для того, чтобы гарантированно помнить максимум TTH-ек и не зависеть от активности клиентов определенной сети.
По-моему тут можно прозрачно выполнить масштабирование.
А вот как с помощью текущей реализации DHT хранить такой объем информации и быстро отдавать по запросу я не знаю.
подскажите?
Зачем здесь вообще DHT или какой-то сервак? Если нашел файл в поиске - значит он у кого-то есть, нужно всего лишь спросить его. Вполне можно было "выкачивать" эту инфу также, как к примеру скачиваются файллисты пользователей. И получилась бы абсолютно стабильная и простая реализация, не зависящая от настроения ваших сервов.
>> подскажите?
а чего непонятного?
в данный момент dht-сеть хранит по TTH (ключу) хранит пару дополнительных полей: размер файла и CID раздающего. нужно дополнить полями с медиа-инфой. при публикации шары в dht клиент кроме имени/размера файла будет выплёвывать медиаинфу тем нодам, чей CID наиболее близок к TTH файла (при поиске спрашивать медиаинфу у тех нод, чей CID близок к TTH). оно уже так и работает с обычным поиском
плохо только, что пока клиентов этой фичей мало, доп. инфа будет отбрасываться. можно либо предпочитать клиентов с этим SUPPORTS (передавать медиаинфу не просто ближайшим, а ближайшим флаям) либо параллельно построить вторую dht-сеть, исключительно для флаев. не то чтобы совсем другую сеть, а вести списки медиа-соседей в отдельных k-bucket'ах, поиск и паблиш медиа по этим бакетам, поиск и паблиш TTH - по обычным, где в том числе и стронги-апексы
сроки хранения медиа-инфы увеличить, чтобы не expire-ось как обычные dht-записи, а например при достижении некоторого размера вытесняло случайную запись
>> Зачем здесь вообще DHT или какой-то сервак? Если нашел файл в поиске - значит он у кого-то есть, нужно всего лишь спросить его.
хорошая идея! но быстрее будет не спрашивать отдельно, а пусть клиенты сразу вместе с результатом поиска передают медиа-инфу где-то в поисковом ответе (но так, чтобы клиент, не понимающий медиаинфу, видел это как обычный поисковый ответ)
либо отсылать одновременно два ответа: стандартный и медиа-инфо
Вывод медиа-информации это первый шаг разобрать мусорку царящую в DC++ сетях.
К файлу будут прикрепятся доп-атрибуты.
- счетчик запросов (популярность попадания в зону поиска)
- признаки +1/-1/фейк/и т.д.
- рейтинг файла на трэккерах с URL
- комменты к файлу
- и т.д.
и эта информация будет доступна при последующих поисках данного TTH.
даже если клиент передавший этот TTH первый раз уже давно отключился от сети DC
Павел, а почему нельзя вот так сделать ?
http://flylinkdc.com/forum/viewtopic.php?f=15&t=832
Все ссылки с описанием будут храниться у юзеров. Чем плохо ?
Ещё один вариант хранения описания самих раздаваемых файлов можно сделать вот таким образом : http://rutracker.org/forum/viewtopic.php?p=56971489#56971489
Компьютер юзера может отдавать тогда не только ссылку с описанием на страницу с веб сервером, но и на страницу описания сохранённую на его компьютере
Вот видите, надо было сначала хорошо подумать и народ спросить. Выходит всетаки костыль вы сделали...
Возможно не туда пишу.Хорошо было бы сделать в флайлинке копирование медиаинформации,по типу магнет url ,и можно было настраивать по переменным шаблон копирования как магнет url , например %codecid% %bitrate% и т.д
Возможно ли научить флай нормально работать через DHT скачивание/отдача, как в торрентах.
P.S. Находит и отдает нормально , но скачивать наотрез не хочит.
Надеюсь время на каникулах вы потратите не на эту фигню, а на более серьезные проблемы, решение которых постоянно откладывалось из-за "недостатка свободного времени и большой сложности"
когда планируется перевести основной чат на webkit?
Кто тебе наврал про такие планы?
[url=http://certifiedpharmacy.co.uk/products/indinavir.htm][img]http://onlinemedistore.com/3.jpg[/img][/url]
online pharmacy no rx http://certifiedpharmacy.co.uk/products/estrace.htm celebrex from new pharmacy zealand [url=http://certifiedpharmacy.co.uk/products/lasuna.htm]st lucie county florida pharmacy discount card[/url]
cvs pharmacy transfer prescription http://certifiedpharmacy.co.uk/products/cytotec.htm mexico international pharmacy [url=http://certifiedpharmacy.co.uk/products/levitra-super-active-plus.htm]levitra super active plus[/url]
alamo heights pharmacy http://certifiedpharmacy.co.uk/products/aricept.htm pharmacy resume examples [url=http://certifiedpharmacy.co.uk/categories/antiviral.htm]meiers pharmacy algonquin il[/url]
next day overnight delivery pharmacy http://certifiedpharmacy.co.uk/products/copegus.htm pharmacy road smokers lothian smoking [url=http://certifiedpharmacy.co.uk/products/triphala.htm]triphala[/url]
[url=http://englandpharmacy.co.uk/products/zovirax.htm][img]http://onlinemedistore.com/8.jpg[/img][/url]
us discount pharmacy ambien no prescription http://englandpharmacy.co.uk/products/desyrel.htm westby pharmacy [url=http://englandpharmacy.co.uk/catalogue/s.htm]catonsville pharmacy catonsville maryland[/url]
joint forces pharmacy seminar http://englandpharmacy.co.uk/products/dilantin.htm pharmacy tech pay scale [url=http://englandpharmacy.co.uk/products/lopid.htm]lopid[/url]
pharmacy chat rooms http://englandpharmacy.co.uk/products/micardis.htm allegra d online pharmacy [url=http://englandpharmacy.co.uk/products/crestor.htm]overseas pharmacy forum[/url]
cvs pharmacy prescription http://englandpharmacy.co.uk/products/trimox.htm degree programs for pharmacy san antonio texas [url=http://englandpharmacy.co.uk/categories/erection-packs.htm]erection packs[/url]
Отправить комментарий