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

"Использовать ли блоки голосов и что это даст процедуре голосования." Эта тема к оптимизации трафика не относится. А вот "как блок экономит трафик" уже относится. И юзабилити может и вовсе не будет затронута.

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

Ну, у меня тоже первая мысль была передавать данные пачками (пакетами). Т.е. в транспортном модуле нужно будет делать некую очередь и передавать данные блоками, а не по одному пакету. Но это не принципиальные изменения. Оно не даст большого выигрыша. Учитывая что соединения по умолчанию будут постоянными.

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

Я собственно речь веду об обработке блоками.

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

Т.е. о снижении нагрузки на клиента? Это тоже важно. Но нагрузка на сеть мне кажется более важной.

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

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

Таким образом трафик на ноду снизится пропорционально количеству групп, размер хранимых данных - аналогично.

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

Да вроде это связанные вещи.
Экспромт? Нода и есть узел. В связи с чем это за пределами понимания. Что-то разумное есть, но непонятно.

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

да

да (свое сообщение поправил)

Если вы про "Все ноды имеют m связей с нодами каждой из групп." имеется ввиду следующее:
Нода будет иметь непосредственные соединения с нодой (-ами) каждой из групп, что позволит ей получить любые данные в пределах одного "хопа".

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

Тут не все так очевидно как кажется. Фактически, объем необходимой для хранения информации будет снижаться пропорционально количеству групп. Однако, при слишком маленьком размере группы система становится уязвимой. При выведении из строя такой группы часть информации в сети теряется. Что не очень хорошо.

Думаю, все-таки, нужно что-то более естественное.

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

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

Транзитное хранилище - вот тут уже можно гибко варьировать.

Кстати, раз уж поднялась эта тема, предлагаю еще раз использовать анонимные кэширующие/транспортные сервера. Они будут устанавливаться любым желающим без необходимости сложной настойки и будут выступать в качестве основных дублированных хранилищ и посредников для транспортного уровня. Тут главное то что для их установки нужно будет только их поставить и указать выделяемое для них место на дисках сервера.

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

Достаточно хорошо проработать алгоритм выбора количества групп.

Против. Анонимное хранилище = анонимное искажение данных. Каждый узел и так будет являться хранилищем - этого достаточно.

Согласен.

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

Анонимное в том смысле что "прозрачное". Пакеты транспортного уровня будут идти через сервер в неизменном виде. Я лично не вижу каким образом даже подложный сервер может чем-то навредить системе. Здесь полная аналогия с подложным клиентом - поддельные пакеты просто не уйдут в сеть.

Смысл в том, что сервер НИЧЕГО НЕ БУДЕТ ПОДПИСЫВАТЬ. Т.е., например, для вброса голосов через такой сервер все-равно нужен будет авторизованный персональный (транспортный) ключ. Тут как ни крути, а подделать вряд-ли что-то получится.

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68