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

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

Как интересно можно создать ситуацию искусственно с распределением бит в ключах да ещё в субъекте?
По идее нодам в субъекте полюбому надо контактировать.В принципе да. Но и размеры групп будут разными. Группы будут делиться не пополам.

У нас для голосования есть список голосовавших. Для деления можно использовать номер голосующего в этом списке.
Изначально планировались территориальные субъекты. Затем пришли к тому что субъекты могут совсем не касаться территорий. На данный момент территориальность определяется вхождением в соответствующий субъект.
Легко. Голосование по развитию программного продукта.Это внешняя информация по отношению к человеку. Как бы вынужденно приписанная ему информация не присущая от рождения. Кроме того может меняться.

_________________
Во вселенной нет общества в котором "Vox populi, vox Dei" не переводилось бы "О, Боже, как мы в это вляпались".

Сговор. Договорились с друзьями сгенерить ключи у которых последние биты равны 0. Создали субъект. Вступили в него.

Не нужно контактировать там, где можно не контактировать.
На самом деле можно сделать "контактирование" на этапе вступления в субъект. Вступил в субъект - найди свою группу и запомни их.

Если ключи не будут генерироваться со спец параметрами (см. п1) то будут примерно делиться пополам.

Кажется крайне не эффективным методом.
1) У всех этот список должен быть одним и тем же;
2) Он может быть очень большим;
3) Считать сложнее.

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

Dim, еще раз подумал над твоим "оптимистичным" алгоритмом. Мне кажется он действительно заслуживает внимания, однако для его надежности необходимо хорошо продумать механизм "кричалки" о том, что результат не сошелся.

ps Принимаем сам механизм разбиения на группы, основанный на битах хеша ключа?

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

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

_________________
Во вселенной нет общества в котором "Vox populi, vox Dei" не переводилось бы "О, Боже, как мы в это вляпались".

Не понял про коллективного автора. Ключи генерирует сторона клиента и он вправе выбирать каким ключом пользоваться. Он (и его товарищи) могут генерировать ключи до тех пор пока первые 5 бит не будут равны 0. Таким образом искусственно создав ситуацию неравномерного распределения.

А что бы вы сделали с другим алгоритмом? У нас всегда есть вероятность подобной ситуации.

Предлагаю проверить :)

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

В ОС проекте сложно сделать закладку позволяющую создавать неравномерные группы. А то что пользователи генерируют ключи чтобы спецом попасть в одну группу это нас не сильно волнует.
Если голосующие разделяются на группы по списку проголосовавших, то такая ситуация исключается.

_________________
Во вселенной нет общества в котором "Vox populi, vox Dei" не переводилось бы "О, Боже, как мы в это вляпались".

Ага, но это увеличит объем траффика.
А так же еще вопрос, как они будут узнавать друг о друге. Т.е. у нас есть 1 000 000 000 нод, 2 из них проголосовали, как они узнают друг о друге?

Можно попробовать пойти другим путем, и наоборот, пытаться объединить группы с маленьким количеством проголосовавших, до того как будут распространены подписка о голосовании.

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

Не должно. Список голосовавших нам так и так синхронизировать. Даже не надо синхронизировать порядок. Можно просто отсортировать (по тому же ключу).
Список проголосовавших будет из двух нод.
Т.е. мы сначала разбиваем на группы. А затем по тому же принципу начинаем объединять те группы которые оказались слишком мелкими. Причём это можно повторять снова и снова только отбрасывая большие группы.
Мысль интересная.
Однако не избавляет нас от ситуации когда в такой группе вдруг в голосовании примет участие незначительное количество участников.

_________________
Во вселенной нет общества в котором "Vox populi, vox Dei" не переводилось бы "О, Боже, как мы в это вляпались".

Пакет "подтверждение об участии" отправляется асинхронно с пакетом голоса, и может вообще не отправляться до наличия определенного количества "голосов". В том числе не отправляться до достижения кворума голосования, что сэкономит нам траффик.

Как вариант:
отправлять пакет "подтверждение об участии" по завершению голосования. группы строить исходя из нод принявших явное участие.

На данном этапе мне видится так:
Сначала все участники субъекта разбиваются на группы по N (допустим 1024).
Голосуют.
По окончанию голосования, все в группе знают сколько было "голосов", на основании их количества, при нехватке, начинается объединение с соседними группами. (Причем объединяться можно смело, уменьшая количество используемых для разбиения бит. Дело в том, что при равномерном распределении нод по группам, количество принимающих участие в голосовании, должно быть у всех примерно одинаковым)
После объединения до приемлемого уровня, все начинают рассылать "подтверждение об участии".
Дальше процесс голосования без изменений.

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