Проектирование децентрализованной распределенной сети

[jangle]

Кто нибудь сталкивался с такой задачей? Именно проектирование сети и протоколов обмена, для объединения большого количества постоянно исчезающих и появляющихся узлов и эффективной передачи сообщений между ними?

[alibek]

Почитай про любой P2P. Если хочешь качественно, то поищи инфу по Skype.

[jangle]

Почитай про любой P2P. Если хочешь качественно, то поищи инфу по Skype.

Там присуствуют централизованные login серверы, а меня это не устраивает

[alibek]

Чистого P2P не бывает, без серверов-каталогов все-равно не обойтись.

[Денис]

Если где-то чего-то не бывает, то этого просто не придумали еще. Автор говорил о сети передачи сообщений. Такой сети не нужны сервера, каталоги, хранилища данных... просто в децентрализованной сети на основе протокола TCP/IP в силу его архитектуры, будет циркулировать большой объем избыточных данных (из-за того, что каждый клиент децентрализованной сети будет слать широковещательные пакеты, а так же принимать и обрабатывать их же).

[ANDLL]

Денис акстись.
В сети нужен ли сервер для вступления в сеть, либо бродкаст. В интернете второго нет, значит без первого понастоящему динамической сети не получится.

[jangle]

Чистого P2P не бывает, без серверов-каталогов все-равно не обойтись.

Думаю можно, мне нужно только оповещать сеть посылая ей определенные команды.
Например, на футбольном поле стоит 1000 человек с фонариками, каждый фонарь может светить тремя цветами: Reg, Green, Blue. Я тихо говорю самому крайнему человеку - включи красный цвет и направ его в небо, после чего передай команду своим соседям. Постепенно все начинают включать фонарики и поле "краснеет", затем я говорю включи "зеленый" и передай другим.
Мне интересно, как будет происходит изменение цвета футбольного поля, распределение и скорость продвижения команд в децентрализованной сети, коллизии команд. Когда например в некоторый участок сети команда включить зеленый, прийдет раньше чем включения красного цвета.

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


При этом узел 0 знает только узел 4
4-ый знает узлы 3 и 5
5-ый знает узлы 6 и 2
2-ой знает узлы 1 и 3
и т.д.

И еще вариант, чтобы сообщения доходили от самых удаленных узлов обратно к "командиру". Например узел 2 хочет сообщить узлу 0, что у него села батарейка. Но в его таблице нет такого адреса, поэтому он сообщает знакомым узлам 1,3,5 просьбу передать это важное сообщение команду узлу 0.
Узел 3 передает своим знакомым, и наконец 4 узел находит в своей таблице адрес 0 и передает ему данные.В некотором роде, это классическая партизанская или террористическая сеть, очень устойчивая к разрушению и жизнеспособная.

[alibek]

jangle, твоя сеть умрет на первом же маршрутизаторе. Кроме того, в подобной сети можешь забыть про "эффективную передачу данных".
Современные P2P-сети хорошо работают только потому, что базируются на маршрутизируемом протоколе TCP/IP. Убери эту прослойку и получишь хаос. А чтобы этот хаос как-то упорядочить, тебе придется самому реализовывать в сети маршрутизаторы и управляющие узлы.

[alibek]

И еще вариант, чтобы сообщения доходили от самых удаленных узлов обратно к "командиру". Например узел 2 хочет сообщить узлу 0, что у него села батарейка. Но в его таблице нет такого адреса, поэтому он сообщает знакомым узлам 1,3,5 просьбу передать это важное сообщение команду узлу 0. Узел 3 передает своим знакомым, и наконец 4 узел находит в своей таблице адрес 0 и передает ему данные.В некотором роде, это классическая партизанская или террористическая сеть, очень устойчивая к разрушению и жизнеспособная.

Смешной.
А я создаю антипартизанский узел (узлы), которые всем говорят, что знают про любые узлы и могут доставить любые сообщения. На самом деле они будут слать все полученные пакеты в /dev/nul, а также генерировать шум (или не шум, а пакеты, которые приведут к зацикливанию маршрута) и рассылать его всем. И твоя очень устойчивая к разрушению сеть помрет очень быстро.

[jangle]

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

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

Первое, что приходит в голову на счет протокола, "командир" должен нумеровать свои команды:

1 команда - включить красный цвет
2 команда - включить синий цвет
3 команда - включить красный цвет
....

У узла должен быть счетчик приходящих команд, например ему приходит команда под номером 1 а его счетчик равен 0. Значит узел исполняет команду, и передает ее далее своим "знакомым". А еслин, например счетчик узла равен 1 а пришла команда под номером 3, значит произошла коллизия, и команда №2 где-то задержалась. Поэтому узел не выполняет команду номер 3, а просто передает ее соседям, ожидая прихода команды 2.
Правда при этом есть риск, что узел зависнет намертво (если инструкция 2 так и не прийдет к нему) выпав из общей системы.

[Денис]

jangle

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

Социальная среда является сервером. Общество - протоколом. Атмосфера, планета в целом - физическим уровнем передачи данных. Нет децентрализации здесь.

[alibek]

Мне пока хочется понять чисто логически, как такой алгоритм может работать.

Почитай про маршрутизацию в интернете.
Поверь, над этим неглупые люди думали.

[alibek]

Первое, что приходит в голову на счет протокола, "командир" должен нумеровать свои команды:

Командир? Мы все еще про P2P?

[jangle]

А я создаю антипартизанский узел (узлы), которые всем говорят, что знают про любые узлы и могут доставить любые сообщения. На самом деле они будут слать все полученные пакеты в /dev/nul, а также генерировать шум (или не шум, а пакеты, которые приведут к зацикливанию маршрута) и рассылать его всем. И твоя очень устойчивая к разрушению сеть помрет очень быстро.

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

[jangle]

Командир? Мы все еще про P2P?

Название роли не играет, можешь называть его источником команд, или процессором

[Денис]

В принципе, можно сделать что-то похожее на P2P. Смотрите:
Каждая программа на узле состоит из клиентской и серверной части. При "авторизации" в сети надо клиентской частью программы опросить все сервера, имеющиеся в онлайне. те, кто сохранили свои IP отзываются и сообщают IP недостающих адресов. Ну а дальше работа прямыми соединениями через сокеты. Если ни один сервер не отозвался - тогда любым другим способом, по аське, по почте, на трекере (!) узнать IP ближайшего узла онлайн.
Знакомо?

[alibek]

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

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

[jangle]

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

Ну например, каждое сообщение передаваемое от узла к узлу шифруется, где в качестве ключа используется текущее время с точностью до минуты, конечно защита слабая, но все равно для ее вскрытия надо реверсить код узла, а это не всем под силу...
Или вообще, сделать шифрование трафика через SSL протокол. Короче говоря, закрыть протокол обмена от посторонних глаз.

[alibek]

Ты не увиливай от ответа.
Ты писал:

...для объединения большого количества постоянно исчезающих и появляющихся узлов и эффективной передачи сообщений между ними?

Итак, появился правильный узел. Как он подключится к сети?

[jangle]

Итак, появился правильный узел. Как он подключится к сети?

Этот узел должен подключиться к другому узлу, назовем его Super Node. Это обычный узел, только выполняющий функции маршрутизатора.
У SN есть таблица адресов обычных узлов, подключенных к нему, а также "cоседних" SN узлов. Можно назвать такую конструкцию пулом нодов или кластером нодов. Копия этих таблиц есть и у обычных узлов (на случай выхода из строя SN узла, обычный узел тогда станет SN и соберет всю конструкцию заново. Система самовосстановления сети.) "Правильный узел" пытаясь подключиться/зарегистрироваться на SN, генерирует некий код в зависимости от времени на time.windows.com, и посылает его SN, тот в свою очередь тоже генерирует код в зависимости от текущего времени, сравнивает. Они они совпадают, то прописывает IP адрес нового узла в свою таблицу, и также посылает эту измененую таблицу остальным узлам которые подключены к SN. С этого момента новый узел подключен ко всей сети, и может быть доступен с любого другого узла сетки - /SN1/узел6

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

[alibek]

Этот узел должен подключиться к другому узлу, назовем его Super Node. Это обычный узел, только выполняющий функции маршрутизатора.

Уже интересно. Ведь в Skype тебя суперноды (эту роль на себя автоматически берут узлы с быстрым каналом) не устраивали. Ну да ладно.

У SN есть таблица адресов обычных узлов, подключенных к нему, а также "cоседних" SN узлов. Можно назвать такую конструкцию пулом нодов или кластером нодов.

Если сеть только создается (а следовательно, у всех потенциальных SN таблицы пусты), как они найдут друг друга?

Копия этих таблиц есть и у обычных узлов (на случай выхода из строя SN узла, обычный узел тогда станет SN и соберет всю конструкцию заново. Система самовосстановления сети.)

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

"Правильный узел" пытаясь подключиться/зарегистрироваться на SN, генерирует некий код в зависимости от времени на time.windows.com, и посылает его SN, тот в свою очередь тоже генерирует код в зависимости от текущего времени, сравнивает. Они они совпадают, то прописывает IP адрес нового узла в свою таблицу, и также посылает эту измененую таблицу остальным узлам которые подключены к SN. С этого момента новый узел подключен ко всей сети, и может быть доступен с любого другого узла сетки - /SN1/узел6

Ну одно то, что ты собираешься построить отказоустойчивую и самовосстанавливающуюся сеть возлагая критически важные функции на ресурсы, которые к этой сети не имеют никакого отношения, уже должно натолкнуть на мысль, что путь выбран неправильный. Но даже если это вынести за скобки, объясни, как это помешает неправильному ноду точно также сгенерировать сессионный ключ, подключится к SN и вести деструктивную деятельность?

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

[jangle]

Если сеть только создается (а следовательно, у всех потенциальных SN таблицы пусты), как они найдут друг друга?

Самый первый SN можно создать вручную, заполнив его таблицы нужными IP. Все последующие SN будут "пристыковаваться" к этому первому SN.
Таким образом проблема "пустых таблиц" не возникнет.

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

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

[ANDLL]

Ведь есть же черви в p2p сетях которые полностью эмулируют реальных пользователей, пиринговые сети от это еще не умерли.

Это пять. Выясни хотя бы, как p2p сети с этим боряться. Вдруг откроется что новое...

[alibek]

Самый первый SN можно создать вручную, заполнив его таблицы нужными IP. Все последующие SN будут "пристыковаваться" к этому первому SN. Таким образом проблема "пустых таблиц" не возникнет.

Ты похоже просто ленишься думать.
Такая ситуация возникнет не только один раз при создании сети. Такая проблема будет вставать перед каждым SN, который будет включаться в сеть.
Откуда подключаемый SN будет знать, к какому именно существующему SN ему надо "пристыковаться"? Откуда существующий SN будет знать, что новый SN следует к себе пристыковать и что это правильный супернод, а не хакерский? При масштабных сбоях в работе сети, когда будет отключен сразу большой сегмент, каким образом два ранее соединенных SN снова подключатся друг к другу (а заодно, как два изолированно работающих некоторое время сегмента вновь соединятся)?
Или ты предлагаешь все это делать вручную, по заявке администраторов узлов? Добро пожаловать в FIDOnet? Только учти, что во-первых ФИДО было оффлайновой сетью, а во-вторых сеть ФИДО умерла, поскольку Internet лучше.

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

Да, действительно. Подумаешь, в сети окажется неправильный SN, который нарушит работу целого сегмента сети.
Хорошо, что люди, ответственные за корневые DNS-сервера так не думают.

[Денис]

Вы главное не путайте функциональность и безопасность.
Я считаю, что распределенную сеть нужно строить как минимум на двух уровнях организации сети: сначала по TCP/IP устанавливаются открытые соединения с одним или несколькими узлами, а потом по этим соединениям передается шифрованный поток данных, в котором сериализованы объекты-письма с атрибутами-адресатами, временными штампами, подписями и пр.

Кроме того, принцип регистрафии по типу фидо - очень хорош! Зря его забыли. (Я имею ввиду личный контакт, либо по телефону. Только так автор отсеет хакеров (а точнее - оперов) из своей сети)

[alibek]

Я считаю, что распределенную сеть нужно строить как минимум на двух уровнях организации сети: сначала по TCP/IP устанавливаются открытые соединения с одним или несколькими узлами, а потом по этим соединениям передается шифрованный поток данных, в котором сериализованы объекты-письма с атрибутами-адресатами, временными штампами, подписями и пр.

Ты про ТОР слышал?

Кроме того, принцип регистрафии по типу фидо - очень хорош! Зря его забыли. (Я имею ввиду личный контакт, либо по телефону. Только так автор отсеет хакеров (а точнее - оперов) из своей сети)

И где теперь ФИДО?

[Денис]

Ты про ТОР слышал?

Конечно, потому и говорю.

И где теперь ФИДО?

Известно где, но ИМХО не из-за того, что там регистрация "оффлайновая", а просто из-за общего неудобства.

[jangle]

Ты похоже просто ленишься думать.
Такая ситуация возникнет не только один раз при создании сети. Такая проблема будет вставать перед каждым SN, который будет включаться в сеть.
Откуда подключаемый SN будет знать, к какому именно существующему SN ему надо "пристыковаться"? Откуда существующий SN будет знать, что новый SN следует к себе пристыковать и что это правильный супернод, а не хакерский? При масштабных сбоях в работе сети, когда будет отключен сразу большой сегмент, каким образом два ранее соединенных SN снова подключатся друг к другу (а заодно, как два изолированно работающих некоторое время сегмента вновь соединятся)?

Пока мне сложно ответить на эти вопросы, надо будет все еще хорошенько обдумать.