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

Таким образом вы ставите распостранение информации по сети п2п в зависимость от активности узлов системы ЭГ внутри NATа. Клиент на таком узле должен сам постоянно "тюкать" другие узлы системы в надежде получить текущую информацию по голосованиям. Поэтому же у узла за NATом весьма ограниченные возможности по выполнению функций маршрутизатора системы голосований.

Вопрос про объемы входящей и хранимой информации пока замнем для ясности.


Насколько я понял, STUN иногда помогает решить проблему доступа к узлам за NAT. Но не для всех типов NAT. И не решает проблему антивирусных и прочих FW, а также прокси доступа в инет. Короче, далеко не универсален.

Подводим итог по этой части. Система ЭГ может быть построена по принципу п2п с точки зрения хранения (и обработки) данных. При этом клиент ХРАНИТ данные о голосованиях на этом узле и ЗАПРАШИВАЕТ данные о голосованиях на других узлах. При универсальном подходе самостоятельно инициировать распостранение данных узлы не могут.

Если бэкэнд клиента подключен к другим бэкэндам любым способом - вообще не имеет значения способ этого подключения. Какая вам разница откуда взялся tcp канал если вы по нему можете слать информацию в обе стороны?

Ну и какая разница за NAT клиент или имеет реальный IP если и тот и другой имеет одинаковое количество коннектов к другим бэкэндам? И у этих коннектов одинаковые свойства.


Честно говоря странный вывод. Не понимаю я вашу логику.

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

Разницы нет тогда, когда tcp соединение уже установлено. Но установившееся соединение не держится вечно. И рано или позно (скорее рано, чем наоборот), разрывается. Более того, после обмена данными логично программно разорвать соединение - зачем его держать вечно, расходуя ресурсы системы? А дальше инициировать соединение может опять только бэкэнд клиента (который за FW). Если до этого момента в глобальной системе произошли изменения, а клиент по какой-то причине связь не устанавливает, то об изменениях ему принудительно сообщить не удастся - он защищен всякими FW.


Давайте тогда по частям.
1. На узле произошли голосования. Предполагаю, что клиент ХРАНИТ эти данные, а не уничтожает их с этого узла после передачи другим узлам группы.
2. Клиент ЗАПРАШИВАЕТ данные о голосованиях на других узлах. Он инициирует соединение. К этому времени на других узлах группы уже могли пройти голосования или другие значимые события. Эти данные перекачиваются на узел для выравнивания БД узлов группы.
3. Если брать крайний случай, все, кроме одного узла группы, могут быть расположены за FW. Единственный способ инициировать распостранения данных по голосованиям - узлы за NATом инициирую соединения с единственным "реальным" и ЗАПРАШИВАЮТ у него данные. Т.е. универсальный подход к ПО клиента - он хранит данные по своим голосования и инцициирует соединения с другими узлами для запроса у них данных группы.
Такая моя логика. Описание в таких терминах вы, как разработчики, мне не дали. Поэтому пытаюсь сделать "реинжиниринг" сам.

Для демонстрационного прототипа это утверждение верно.


Не верно. STUN описывать как организовать подключение между 2мя нодами за NATом используя ноду с внешним адресом.

ps Установка соединения более ресурсоемкая операция, чем поддержка. См. документацию по TCP/IP, syn, ask, keepalive.

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

Угадал хоть в чем-то наконец. Почему только для прототипа?

Методично повторяю, что расчитывать на определенную конфигурацию условий доступа узла в инет для системы, претендующей на массовое распостранение и использование - неправильно. NAT на шлюзе может не поддерживать STUN, в системе и на узле могут быть дополнительные уровни защиты сетевого трафика. Пользователь может не иметь доступа или желания (имеет право) для конфигурации защиты специально для ПО узла голосования.


Да, но найлучший способ экономии ресурсов - инициировали и установили соединение - синхронихировали/передали данные и отключились. Кроме того, в сети и на узле постоянно происходят события. В том числе и выключения программ и питания и разрывы связи.

После реализации прототипа будет разрабатываться распределенная БД с распределенным подсчетом результата.

У вас торренты работают?

Определитесь "Да" или есть "Наилучший способ".
О того что один из 32 узлов отвалился вам на много хуже не станет. У вас торренты работают? :)

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

На узле в БД хранятся все ИСХОДНЫЕ результаты голосований в группе. Если ограничить размер группы разумными пределами, то любой узел может сам подвести любые итоги голосований в этой группе. Распределять БД в этом случая нет необходимости.
Результаты голосований во всех других группах в ОБРАБОТАННОМ, а значит, значительно сокращенном виде, можно получить от доверенных узлов этих других групп. При разумном количестве других групп таким образом на узле (на всех узлах нашей группы) могут храниться результаты голосования всего субъекта. И каждый узел в состоянии (по требуемым вычислительным ресурсам) сам подвести итоги.
Если при этом структура групп вложенная, т.е. построена по иерархии, то на узлах нашей группы могут храниться результаты голосований субъекта любого (всероссийского, всемирного) размера.
Принципиальным здесь является вопрос: допускается ли промежуточная обработка данных в группах и использование этих данных другими группами? Или каждый раз при подсчете неким узлом результатов голосования в субъекте должны использоваться ИСХОДНЫЕ данные голосований всего субъекта?


У меня дома три компа и точка доступа с NAT. Сын качает фильмы с peer -сетей. Наверное, используя торренты (я сам не балуюсь, поэтому терминологией не владею). Но для работы его качалки я прописал на точке доступа правила для входящих пакетов, без которых качалка не работала.


Юрий, не сомневаюсь в Вашей квалификации в разработке проектов и написании кода приложений, использующих сетевые ресурсы. Но, имхо, не очень корректны реализации, свободно распоряжающиеся ресурсами (не своих) компьютеров. Это относится к любым типам ресурсов - к оперативной и "твердой" памяти, вычислительным и ресурсам сети. В итоге получаются монстры, плохо перевариваемые любыми компами, оттого не пользующиеся особой популярностью у широких народных масс.
"Да" - ресурсы, требуемые для поддержания соединения, меньше, чем они же на установку соединения.
Нет текущей передачи данных (все уже передано-принято) - соединение разрываем, ресурсы освобождаем.
При возникновении нового события на узле голосования - пришел еще один человек и хочет голосовать - устанавливаем соединение и производим обмен данными. И так по циклу. Такая логика работы есть "наилучший способ".

Это вы прочитали мой вчерашний пост про распределенное хранение данных?

Плохая качалка :)

1) Лучше иметь хоть что-то чем ничего;
2) Если есть конкретные предложения - они обсуждаются, но уже в рамках пост-демонстрационного проекта.

Нет у нас таких узлов, не узнаете вы ничего, если не будет ни с кем соединения.

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

Нет, Ваш пост я не читал. (К тому же вчера Вы пост на такую тему не писали или я его, как всегда, не нашел). Под "распределенным хранением данных" в СУБД я понимал и понимаю другое.


Под вывеской "прототип" вы проектируете утопию. Если можно согласиться с предложенным принципом хранения данных в прототипе (все ИСХОДНЫЕ данные хранятся на узле), то принцип взаимодействия прототипа - открытая локальная сеть - существует только в Вашем воображении. Потратив время на проектирование и отладку взаимодействия узлов прототипа вы будете разрабатывать эту функцию системы заново для любой реальной сети компьютеров.


Берем, как всегда, граничный случай. Система установлена на группу узлов, каждый из которых находится за мощным FW. Очевидно, что начать работу такая система ЭГ сможет только при наличии какого-то известного всем компьютера, так или иначе принимающего входящие соединения. Т.е. сервера. Других способов нет.

Мне прям больше ответить нечего.
Вы хотите понять, что мы делаем или оспорить принятые решения?

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