Проект "Свободные голосования"

Тогда добавьте к своим высказываниям немножко сомнений.

Критиковать не воспрещается, но позаботьтесь об обосновании своих доводов.

_________________
AF4B DFB0 0E41 2F7A 09FD 4971 96F0 B176 EA1C DD85

Пора вернуться к теме трэда, пожалуй. У меня была мысль, пока вы воплощали в жизнь "принятые решения"(с) я ее думал, в итоге она сформировалась в две идеи. Прошу их обсудить.

1. Информационные потоки в системе ЭГ реализованы исключительно в виде информационных пакетов перечисленных типов (названия условные):
- пакет "выдача" ("В"). На узле СГ произошло событие (генерация ключей, голосование, ...). Информация в пакете "В" выталкивается в сеть. Принимают информацию те узлы, которым она нужна.
- пакет "запрос" ("З") информации и ответ в пакете "ответ на запрос" ("ОЗ"). Софт на узле запущен, БД узла требуется пополнить текущей информацией (ключами, сформированными в группе узлов, текущими рез-ми голосований, ...). В сеть идет запрос "З", узлы, обладающие необходмиой информацией, отвечают по сути пакетом "ОЗ".
Лучший вариант - основывать систему на пакетах только одного типа. Но, наверное, возможно совмещение. Решение можно принять после формализации всех потребностей системы в пакетах указанных типов.

2. Распределенная СГ может быть простроена по принципу, максимально приближенному к принципу п2п. А именно так. В системе есть узлы, выполняющие почти все необходимые функции, в т.ч. хранение и обоработку данных. Также в системе есть сервера, выполняющие только функции распостранения и кэширования информационных потоков. Кол-во серверов теоретически не ограничено. Могут использоваться хостинговые сервера, расположенные где угодно и обслуживающие специально зарегистрированные под СГ домены. Список известных системе серверов может распостраняться с дистрибутивами и периодически обновляться с выходом новых версий программы.

Теперь необходимые пояснения.
Для "идеальной" п2п сети "прототипа" СГ, когда каждый узел установил и держит соединение с определеным кол-вом других узлов, при применении для обмена пакетов "В" возникают вопросы. Пакет выдан узлом в сеть, получен (учтен) некоторыми узлами. А как быть с теми узлами, которые в данный момент не присоединены, и, соответственно, не получили нужную информацию. Как вариант - требуется вводить еще "синхронизацию" БД узлов. Еще вариант - кэшировать пакеты "В". Но кто должен выполнять функцию кэширования и как долго держать пакеты в кэше?
Если в такой же сети примененять обмен посредством пакетов типа "З" и "ОЗ", возникают те же вопросы. Если применять кэш, то сначала кэшируются маленькие "З" пакеты, а если получен ответ и он сразу не может быть отослан (узел, инициировавший запрос, в данный момент не соединен) то кэшируется ответ "ОЗ". Узел может при формировании запроса явно указать время его актуальности. Или это время может ограничить кэширующее ПО.

При применении системы серверов (идеи 1+2), почти все вопросы кэширования снимаются, так как это одна из их функций. Пакеты типа "В" принимаются, а затем распостраняютя по всем доступным серверам СГ и кэшируются на каждом из них. Вопрос - как долго, т.е. когда их можно будет удалить из кэша. Логика работы узла: Присоединился к любому серверу (или к нескольким сразу), просмотрел кэш, если нужно - скачал инфу себе и отключился.
Если СГ функционирует на запросных пакетах, логика работы узла: запущен софт, пользователь проголосовал и хочет посмотреть текущую инфу. Формируется пакет "З", отправляется на сервер (сервера). Если ответа в кэше нет, запрос дублируется по всем серверам и кешируется. Узлу выдается квитанция "запрос принят, приходите позже". Узел отключается для того, чтобы подключится через некоторое время и получить свой "ОЗ" пакет. Узел может сразу указать время актуальности запроса "З", правила хранения информации в серверных кэшах также устанавливаются.

Тогда уж так:
- выдача;
- синхронизация (пополнение хранилища);
- запрос (запрос на информацию которая тут храниться не должна, но потребовалась по каким-либо причинам)

Так же p2p клиент можно установить на сервера. По факту они ничем не будут отличаться от пользовательских нод и будут выполнять те же функции. Вот только ресурсов у них будет побольше.

Список будет синхронизироваться p2p.

Правильно - синхронизироваться.

Для демонстрационного прототипа будет только пункт "синхронизироваться".
Для реальной системы будет разработан механизм поиска нод с нужными данными типа DHT

_________________
AF4B DFB0 0E41 2F7A 09FD 4971 96F0 B176 EA1C DD85

Если быть еще точнее, должна быть:
1) Глобальная распределенная БД с множественный реплицированием и общими механизмами синхронизации;
2) Локальная специализированная БД для голосований и специальными механизмами синхронизации.

_________________
AF4B DFB0 0E41 2F7A 09FD 4971 96F0 B176 EA1C DD85

Здесь Вы имеете в виду чистую п2п, как я понял. Если протоколы выдачи и запроса теоретически можно представить, то вопрос синхронизации для меня пока в тумане. Во-первых, понятно, что синхронизация нужна в первую очередь для того, чтобы максимально увеличить кол-во точек хранения. Во-вторых понятно, что синхронизация должна осуществляться в пределах ограниченных групп. А если группы пересекаются? И в-третьих, протокол синхронизации тоже должен быть построен на запросах-выдачах инфы. Возвращаемся к ненужности протокола синхронизации и опять пошли по кругу про необходимость кэша (см. мой пост с "идеями").

Говорим об "идее 2"?
Разница есть, и очень большая. Типичные узлы - это домашние или рабочие компы. Типичный сервер - это хостинговый "виртуальный" сервер, расположенный непонятно где у хостинг-провайдера. Все его ресурсы - для поддержки соединений с узлами, репликаций и кэширования. Любой такой сервер в любой момент можно отключить без всяких последствий для СГ. Кроме того, голосовать и считать результаты на сервере - значит увеличивать стоимость эксплуатации СГ в целом (требуется бОльшая БД и бОльшие вычичлительные мощности). На нем правильнее установить софт для поддержки/управления системой, ведения логов, ....

Опять говорим о СГ с серверами? Тогда список известных серверов (сотни/тысячи шт.) может(должен) быть зашит в софт и достаточно его пополнять только с выходом новых версий ПО узлов. Зачем нагружать систему лишней процедурой синхронизации?
Лучше продумать заранее удобный (а лучше вообще прозрачный) для юзверей способ обновления версий ПО узлов.

да

да

Кто хочет - тот ставит, нам от этого хуже не будет.

Зачем? Зачем я буду зашивать в программу какой-то список, если все будет работать и без этого?

_________________
AF4B DFB0 0E41 2F7A 09FD 4971 96F0 B176 EA1C DD85

Я установил софт СГ на свой домашний/рабочий комп. Куда будет обращаться программа, чтобы выдать или запросить информацию. Мы говорим не о вашем "прототипе", поэтому инициировать соединение с моим компом из инета невозможно (да и кто вообще знает о факте существования моего узла?). Распишите, плз, подробный алгоритм включения узла в работу СГ.

Программа запроси у вас (минимум 1) список адресов. Адреса могут распространяться любыми сайтами, причем генерироваться автоматически исходя из активности. Один из таких генераторов по всей видимости будет стоять на сайте gplvote.

_________________
AF4B DFB0 0E41 2F7A 09FD 4971 96F0 B176 EA1C DD85

"Программа запросит у вас" - это как? И как я ей отвечу? Ручками буду вводить в интерфейс из памяти. А в памяти откуда?
Если будет только gplvote для начала работы - надежность на нуле.
Вот как по-моему (один из вариантов). Регистрируются необходимое кол-во доменов (сотни). Для каждого из доменов покупается/арендуется хостинговый сервер, на который устанавливается серверное ПО. Список серверов КОНЕЧЕН на данный конкретный момент времени. Новые будут добавляться нечасто (пулами, по мере необходимости/возможности). Текущий список есть на каждом сервере/узле. Он может на них же рейтинговаться для ускорения процесса поиска доступных. Начать работу каждый узел может с любым из серверов из списка - сервера абсолютно равнозначны в функциях.
Из логики работы узла при этом исключается за ненадобностью процесс синхронизации списка серверов.

Конечно, копирование же со страницы gplvote не работает.

Исключено. Серверов может и не быть - система должна оставаться работоспособной в любом случае.

_________________
AF4B DFB0 0E41 2F7A 09FD 4971 96F0 B176 EA1C DD85