Проект "Свободные голосования" http://gplvote.andyhost.ru/forum/ |
|
Информационные потоки распределенной системы ЭГ http://gplvote.andyhost.ru/forum/viewtopic.php?f=23&t=335 |
Страница 4 из 5 |
Автор: | yurial [ 18 янв 2012, 21:58 ] |
Заголовок сообщения: | Re: Информационные потоки распределенной системы ЭГ |
IgorK писал(а): Другого выхода нет - займусь на досуге подробным изучением. Возможно, появятся более веские доводы с техническими деталями. Тогда добавьте к своим высказываниям немножко сомнений. IgorK писал(а): Бог, как грится, в помощь. Я не буду делать - критиковать чужие поделки проще :-) Критиковать не воспрещается, но позаботьтесь об обосновании своих доводов. |
Автор: | IgorK [ 19 янв 2012, 10:32 ] |
Заголовок сообщения: | Re: Информационные потоки распределенной системы ЭГ |
Пора вернуться к теме трэда, пожалуй. У меня была мысль, пока вы воплощали в жизнь "принятые решения"(с) я ее думал, в итоге она сформировалась в две идеи. Прошу их обсудить. 1. Информационные потоки в системе ЭГ реализованы исключительно в виде информационных пакетов перечисленных типов (названия условные): - пакет "выдача" ("В"). На узле СГ произошло событие (генерация ключей, голосование, ...). Информация в пакете "В" выталкивается в сеть. Принимают информацию те узлы, которым она нужна. - пакет "запрос" ("З") информации и ответ в пакете "ответ на запрос" ("ОЗ"). Софт на узле запущен, БД узла требуется пополнить текущей информацией (ключами, сформированными в группе узлов, текущими рез-ми голосований, ...). В сеть идет запрос "З", узлы, обладающие необходмиой информацией, отвечают по сути пакетом "ОЗ". Лучший вариант - основывать систему на пакетах только одного типа. Но, наверное, возможно совмещение. Решение можно принять после формализации всех потребностей системы в пакетах указанных типов. 2. Распределенная СГ может быть простроена по принципу, максимально приближенному к принципу п2п. А именно так. В системе есть узлы, выполняющие почти все необходимые функции, в т.ч. хранение и обоработку данных. Также в системе есть сервера, выполняющие только функции распостранения и кэширования информационных потоков. Кол-во серверов теоретически не ограничено. Могут использоваться хостинговые сервера, расположенные где угодно и обслуживающие специально зарегистрированные под СГ домены. Список известных системе серверов может распостраняться с дистрибутивами и периодически обновляться с выходом новых версий программы. Теперь необходимые пояснения. Для "идеальной" п2п сети "прототипа" СГ, когда каждый узел установил и держит соединение с определеным кол-вом других узлов, при применении для обмена пакетов "В" возникают вопросы. Пакет выдан узлом в сеть, получен (учтен) некоторыми узлами. А как быть с теми узлами, которые в данный момент не присоединены, и, соответственно, не получили нужную информацию. Как вариант - требуется вводить еще "синхронизацию" БД узлов. Еще вариант - кэшировать пакеты "В". Но кто должен выполнять функцию кэширования и как долго держать пакеты в кэше? Если в такой же сети примененять обмен посредством пакетов типа "З" и "ОЗ", возникают те же вопросы. Если применять кэш, то сначала кэшируются маленькие "З" пакеты, а если получен ответ и он сразу не может быть отослан (узел, инициировавший запрос, в данный момент не соединен) то кэшируется ответ "ОЗ". Узел может при формировании запроса явно указать время его актуальности. Или это время может ограничить кэширующее ПО. При применении системы серверов (идеи 1+2), почти все вопросы кэширования снимаются, так как это одна из их функций. Пакеты типа "В" принимаются, а затем распостраняютя по всем доступным серверам СГ и кэшируются на каждом из них. Вопрос - как долго, т.е. когда их можно будет удалить из кэша. Логика работы узла: Присоединился к любому серверу (или к нескольким сразу), просмотрел кэш, если нужно - скачал инфу себе и отключился. Если СГ функционирует на запросных пакетах, логика работы узла: запущен софт, пользователь проголосовал и хочет посмотреть текущую инфу. Формируется пакет "З", отправляется на сервер (сервера). Если ответа в кэше нет, запрос дублируется по всем серверам и кешируется. Узлу выдается квитанция "запрос принят, приходите позже". Узел отключается для того, чтобы подключится через некоторое время и получить свой "ОЗ" пакет. Узел может сразу указать время актуальности запроса "З", правила хранения информации в серверных кэшах также устанавливаются. |
Автор: | yurial [ 19 янв 2012, 12:06 ] |
Заголовок сообщения: | Re: Информационные потоки распределенной системы ЭГ |
IgorK писал(а): 1. Информационные потоки в системе ЭГ реализованы исключительно в виде информационных пакетов перечисленных типов (названия условные): - пакет "выдача" ("В"). На узле СГ произошло событие (генерация ключей, голосование, ...). Информация в пакете "В" выталкивается в сеть. Принимают информацию те узлы, которым она нужна. - пакет "запрос" ("З") информации и ответ в пакете "ответ на запрос" ("ОЗ"). Софт на узле запущен, БД узла требуется пополнить текущей информацией (ключами, сформированными в группе узлов, текущими рез-ми голосований, ...). В сеть идет запрос "З", узлы, обладающие необходмиой информацией, отвечают по сути пакетом "ОЗ". Тогда уж так: - выдача; - синхронизация (пополнение хранилища); - запрос (запрос на информацию которая тут храниться не должна, но потребовалась по каким-либо причинам) IgorK писал(а): 2. Также в системе есть сервера, выполняющие только функции распостранения и кэширования информационных потоков. Так же p2p клиент можно установить на сервера. По факту они ничем не будут отличаться от пользовательских нод и будут выполнять те же функции. Вот только ресурсов у них будет побольше. IgorK писал(а): Список известных системе серверов может распостраняться с дистрибутивами и периодически обновляться с выходом новых версий программы. Список будет синхронизироваться p2p. IgorK писал(а): А как быть с теми узлами, которые в данный момент не присоединены, и, соответственно, не получили нужную информацию. Правильно - синхронизироваться. Для демонстрационного прототипа будет только пункт "синхронизироваться". Для реальной системы будет разработан механизм поиска нод с нужными данными типа DHT |
Автор: | yurial [ 19 янв 2012, 12:29 ] |
Заголовок сообщения: | Re: Информационные потоки распределенной системы ЭГ |
yurial писал(а): Для реальной системы будет разработан механизм поиска нод с нужными данными типа DHT Если быть еще точнее, должна быть: 1) Глобальная распределенная БД с множественный реплицированием и общими механизмами синхронизации; 2) Локальная специализированная БД для голосований и специальными механизмами синхронизации. |
Автор: | IgorK [ 19 янв 2012, 12:53 ] |
Заголовок сообщения: | Re: Информационные потоки распределенной системы ЭГ |
yurial писал(а): Тогда уж так: - выдача; - синхронизация (пополнение хранилища); - запрос (запрос на информацию которая тут храниться не должна, но потребовалась по каким-либо причинам) Здесь Вы имеете в виду чистую п2п, как я понял. Если протоколы выдачи и запроса теоретически можно представить, то вопрос синхронизации для меня пока в тумане. Во-первых, понятно, что синхронизация нужна в первую очередь для того, чтобы максимально увеличить кол-во точек хранения. Во-вторых понятно, что синхронизация должна осуществляться в пределах ограниченных групп. А если группы пересекаются? И в-третьих, протокол синхронизации тоже должен быть построен на запросах-выдачах инфы. Возвращаемся к ненужности протокола синхронизации и опять пошли по кругу про необходимость кэша (см. мой пост с "идеями"). yurial писал(а): Так же p2p клиент можно установить на сервера. По факту они ничем не будут отличаться от пользовательских нод и будут выполнять те же функции. Вот только ресурсов у них будет побольше. Говорим об "идее 2"? Разница есть, и очень большая. Типичные узлы - это домашние или рабочие компы. Типичный сервер - это хостинговый "виртуальный" сервер, расположенный непонятно где у хостинг-провайдера. Все его ресурсы - для поддержки соединений с узлами, репликаций и кэширования. Любой такой сервер в любой момент можно отключить без всяких последствий для СГ. Кроме того, голосовать и считать результаты на сервере - значит увеличивать стоимость эксплуатации СГ в целом (требуется бОльшая БД и бОльшие вычичлительные мощности). На нем правильнее установить софт для поддержки/управления системой, ведения логов, .... yurial писал(а): Список будет синхронизироваться p2p. Опять говорим о СГ с серверами? Тогда список известных серверов (сотни/тысячи шт.) может(должен) быть зашит в софт и достаточно его пополнять только с выходом новых версий ПО узлов. Зачем нагружать систему лишней процедурой синхронизации? Лучше продумать заранее удобный (а лучше вообще прозрачный) для юзверей способ обновления версий ПО узлов. |
Автор: | yurial [ 19 янв 2012, 13:57 ] |
Заголовок сообщения: | Re: Информационные потоки распределенной системы ЭГ |
IgorK писал(а): Здесь Вы имеете в виду чистую п2п, как я понял. да IgorK писал(а): Говорим об "идее 2"? да IgorK писал(а): Разница есть, и очень большая. Типичные узлы - это домашние или рабочие компы. Типичный сервер - это хостинговый "виртуальный" сервер, расположенный непонятно где у хостинг-провайдера. Все его ресурсы - для поддержки соединений с узлами, репликаций и кэширования. Любой такой сервер в любой момент можно отключить без всяких последствий для СГ. Кроме того, голосовать и считать результаты на сервере - значит увеличивать стоимость эксплуатации СГ в целом (требуется бОльшая БД и бОльшие вычичлительные мощности). На нем правильнее установить софт для поддержки/управления системой, ведения логов, .... Кто хочет - тот ставит, нам от этого хуже не будет. IgorK писал(а): Опять говорим о СГ с серверами? Тогда список известных серверов (сотни/тысячи шт.) может(должен) быть зашит в софт и достаточно его пополнять только с выходом новых версий ПО узлов. Зачем нагружать систему лишней процедурой синхронизации? Лучше продумать заранее удобный (а лучше вообще прозрачный) для юзверей способ обновления версий ПО узлов. Зачем? Зачем я буду зашивать в программу какой-то список, если все будет работать и без этого? |
Автор: | IgorK [ 19 янв 2012, 14:24 ] |
Заголовок сообщения: | Re: Информационные потоки распределенной системы ЭГ |
yurial писал(а): IgorK писал(а): Опять говорим о СГ с серверами? Тогда список известных серверов (сотни/тысячи шт.) может(должен) быть зашит в софт и достаточно его пополнять только с выходом новых версий ПО узлов. Зачем нагружать систему лишней процедурой синхронизации? Лучше продумать заранее удобный (а лучше вообще прозрачный) для юзверей способ обновления версий ПО узлов. Зачем? Зачем я буду зашивать в программу какой-то список, если все будет работать и без этого? Я установил софт СГ на свой домашний/рабочий комп. Куда будет обращаться программа, чтобы выдать или запросить информацию. Мы говорим не о вашем "прототипе", поэтому инициировать соединение с моим компом из инета невозможно (да и кто вообще знает о факте существования моего узла?). Распишите, плз, подробный алгоритм включения узла в работу СГ. |
Автор: | yurial [ 19 янв 2012, 14:37 ] |
Заголовок сообщения: | Re: Информационные потоки распределенной системы ЭГ |
Программа запроси у вас (минимум 1) список адресов. Адреса могут распространяться любыми сайтами, причем генерироваться автоматически исходя из активности. Один из таких генераторов по всей видимости будет стоять на сайте gplvote. |
Автор: | IgorK [ 19 янв 2012, 14:55 ] |
Заголовок сообщения: | Re: Информационные потоки распределенной системы ЭГ |
yurial писал(а): Программа запроси у вас (минимум 1) список адресов. Адреса могут распространяться любыми сайтами, причем генерироваться автоматически исходя из активности. Один из таких генераторов по всей видимости будет стоять на сайте gplvote. "Программа запросит у вас" - это как? И как я ей отвечу? Ручками буду вводить в интерфейс из памяти. А в памяти откуда? Если будет только gplvote для начала работы - надежность на нуле. Вот как по-моему (один из вариантов). Регистрируются необходимое кол-во доменов (сотни). Для каждого из доменов покупается/арендуется хостинговый сервер, на который устанавливается серверное ПО. Список серверов КОНЕЧЕН на данный конкретный момент времени. Новые будут добавляться нечасто (пулами, по мере необходимости/возможности). Текущий список есть на каждом сервере/узле. Он может на них же рейтинговаться для ускорения процесса поиска доступных. Начать работу каждый узел может с любым из серверов из списка - сервера абсолютно равнозначны в функциях. Из логики работы узла при этом исключается за ненадобностью процесс синхронизации списка серверов. |
Автор: | yurial [ 19 янв 2012, 18:14 ] |
Заголовок сообщения: | Re: Информационные потоки распределенной системы ЭГ |
IgorK писал(а): "Программа запросит у вас" - это как? И как я ей отвечу? Ручками буду вводить в интерфейс из памяти. А в памяти откуда? Конечно, копирование же со страницы gplvote не работает. IgorK писал(а): Из логики работы узла при этом исключается за ненадобностью процесс синхронизации списка серверов. Исключено. Серверов может и не быть - система должна оставаться работоспособной в любом случае. |
Страница 4 из 5 | Часовой пояс: UTC + 3 часа [ Летнее время ] |
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |