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

Андрей, нарушу одноразово свое обещание. Перечитайте мои посты. Я нигде и никогда не говорил об ассиметричности установленного тср соединения. Я говорил о невозможности его инициировать в некоторых случаях. Так что америку Вы не открыли, прямо скажу.

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

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

Да, такая схема подходит для связи двух тср клиентов, если оба они находятся за FW/NAT. Единственная тонкость в том, что на сервере-посреднике необходимо идентифицировать/верифицировать оба клиентских соединения и после этого, считывая данные одного соединения, передавать их другому соединению, таким образом связывая потоки данных клиентских компьютеров. По такой схеме работает, например, TeamViever (за исключением того, что у этой программы соединения обеих клиентов с сервером организуются с использованием vpn).

Не обязательно что-бы между этими клиентами были именно сервера. Как я уже отмечал, никаких принципиальных отличий между компьютером-сервером и компьютером-клиентом нет. Указанные функции могут с легкостью выполнять другие клиентские компьютеры.

На счет идентификации - бОльшая часть рассылаемой информации в сети общедоступна, т.е. должна рассылаться широковещательно. Да - есть вопросы по трафику, но не неразрешимые. Кроме того, возможно использование каких-то способов автоматической маршрутизации для отправки адресных пакетов.

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

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

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

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

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

Так-же и у любого пользователя будет доступ к клиенту. Но все его права будут ограничиваться имеющимся у него ключем и свойствами этого ключа. И даже если клиентская программа будет взломана и в сеть уйдут пакеты от "неправильного" пользователя, они просто не пройдут дальше первого узла.

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

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

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

Это делается НЕ авторизацией коннекта, а подписанием проходящих через ноду пакетов. Коннекты тут не при чем.

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68