IgorK писал(а):
Это, мягко скажем, нестандартный метод.
Вполне обычный вариант. Держать открытыми десяток соединений менее накладно чем пытаться по необходимости устанавливать соединение с сетью при неизвестности доступности узлов с которыми соединяешься. В биткоине это решено запуском irc канала в котором доступные из интернета клиенты указывают что могут принимать соединения. Собственно это слабое место системы. (Хотя может и не совсем слабое. Я не исследовал систему irc.) Но в нашем варианте это одно из направлений атаки.
Кроме того сеть постоянно включенных узлов используется для анонимизации пакетов при тайных голосованиях. И данные в сети проще искать при постоянно подключенных узлах, чем ждать когда хранящий информацию соизволит выйти на связь.
IgorK писал(а):
Очевидно, "конфеткой" будет постоянные зависания компа при работе вашего софта из-за различных событий в присоединенной сети других узлов:-).
Влиять на касающиеся тебя лично решения уже само по себе "конфетка". И какое влияние на комп будут любые события в присоединённых узлах? Расшифруйте. В моём видении могут исчезнуть от одного до всех коннектов к нодам сети. Ну так устанавливать новые согласно координации приходящей по имеющимся коннектам. Или заново инициировать процедуру подключения. Собственно, так работает скайп. Что-то я не слышал миллионов жалоб на то что он вешает комп.
IgorK писал(а):
Не согласен с Вами. Во-первых, идеальных сетей не бывает в природе.
Прототип системы не строится для реальной работы. Если вдруг какойто узел не может присоединиться к сети, то мы на это повесим тикет и при разработке рабочей версии отработаем. Сейчас речь о проверке принципа. Малозначимые детали можно опустить. Чем меньше детализации будет в прототипе, тем быстрее его можно запустить. Это XP.
IgorK писал(а):
1. Хранение и обработка данных и публичных ключей. Проблема в потенциально большом объеме. Решается, насколько я понял, иерархией (по-вашему, "распределенная БД"). Вопрос можно детально разработать теоретически и проверить на "прототипе" фактически не идею, а работоспособность софта. (При этом мне пока непонятен принцип хранения большого кол-ва публичных ключей, но сейчас не об этом) ;
Для прототипа это неущественная деталь. В тестовой эксплуатации будет хорошо если несколько десятков узлов. А для них вопрос решается полной репликой. На дальнейший вариант можно данные раздробить, а доступность данных обеспечить кодеком Рида-Соломона. Но это неспешная задача и не для прототипа.
IgorK писал(а):
2. Распостранение информации по сети узлов. Суть проблемы - как это распостанение организовать.
Вот для изучения этого вопроса и нужен прототип.
IgorK писал(а):
Вы сейчас, насколько я понял, идете по варианту, когда каждый узел может без проблем инициировать соединение с другим узлом.
Мы идем по варианту когда узел имеет несколько постоянных соединений с распределённой сетью. Исходящие соединения можно установить всегда, когда вообще можно установить соединение. Вопрос о том что не каждый узел принимает входящие соединения сейчас не актуален. В сети достаточно узлов с доступностью входящих соединений.
IgorK писал(а):
Как вы понимаете, алгоритм работы софта, ответственного за распостранение информации, может отличается (а если еще и узел разрывает соединение после передачи данных, то сильнее).
Вот мы и не понимаем зачем усложнять себе задачу, если в любом случае ставится задача постоянной доступности.
IgorK писал(а):
На первое время, кстати, вы можете попробовать "пробить" защиту - добраться до моих компов так, как планируется добираться до узлов системы п2п. Необходимые параметры компов, если надо, я сообщу мылом.
Если кто-то не желает участвовать, то вся сеть в целом не имеет морального права "пробивать" защиту. Если вы не можете из-за своей защиты соединиться с доступным узлом сети, то задача установления соединения просто не может быть решена.
Хотел сослаться на классиков, но не смог вспомнить из кого цитата и за её дословную точность.
Цитата:
Никогда не следует проектировать построение системы исходя из недостатков ресурсов. Такой подход породил проблемы дат, когда сэкономили пару байт. И проблему с адресацией сети в протоколе IPv4. Всегда работайте с расчётом, что ресурсы будут. Отрабатывайте недостаток ресурсов только тогда когда с ним столкнётесь.
Как-то так.
Вход
FAQ
Поиск
