Поддержание целостности сети в одноранговой сети

StackOverflow https://stackoverflow.com/questions/1846522

Вопрос

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

Представьте себе сеть, основанную исключительно на одноранговой сети, где каждый узел подключается только к Икс другие узлы.Не имея большого списка всех узлов, каждый узел отвечает за поддержание соединения с сетью.Узлы отключаются и возникают динамически, то есть каждый узел должен запрашивать у своих соседей (и их соседей?) новые узлы для подключения, чтобы поддерживать Икс количество соединений.

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

В настоящее время я изучаю протокол Chord DHT, поскольку он имеет некоторое сходство с тем, что я спрашиваю.

Это было полезно?

Решение

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

Другие советы

Проект Netsukuku направлен на создание протоколов и реализацию программного обеспечения для крупных одноранговых сетей на базе Wi-Fi.

Из их часто задаваемых вопросов: «Проект Netsukuku основан на очень простой идее использования огромных возможностей подключения к Wi-Fi, заставляя компьютеры беспроводных сообществ действовать как маршрутизаторы и вместе управлять специальной сетью, даже большей, чем Интернет».

Только мои мысли – не полное решение;не проверено на практике, но все же может затронуть ряд интересных проблем и потенциальных решений.

Стандартизированное время отказа узла и повторного подключения должно регистрироваться и управляться.Для этого сеть выполняет вычисления не в режиме реального времени, а на основе количества кадров анимации.Иметь N интерфейсных процессоров, назначающих идентификатор FEP, идентификатор задания и номер кадра сетевой анимации входящим заданиям.Существует ряд проблем, связанных с реальным временем, которые не совсем решаются даже с помощью квантования времени;в некоторых исключительных случаях это немного похоже на бухгалтерский учет: события регистрируются в момент, когда их следует считать происходящими, а не в момент движения денежных средств.

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

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

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

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

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

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

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

  • вы можете сохранить кратчайший путь к X узлам;если узел выходит из строя, присоединенные узлы получают информацию и могут выполнить новый поиск SP, чтобы найти подходящий;вам необходимо учитывать накладные расходы на пинг и сообщения проверки активности
  • вам нужно установить соединения (т.е.поиск в p2p-сети) или просто поддерживать большой набор связанных между собой узлов (а-ля ботнет)?Если да, то может помочь смешанный подход (небольшая распределенная хеш-таблица для небольших подмножеств сети + OSPF/BGP для границ);
  • Так далее и тому подобное

Вы посмотрели Кадемлия?Он похож на Chord, его версии используются BitTorrent и eMule.А бумага перечисляет несколько мер по обеспечению целостности сети даже перед лицом атаки.Двумя основными являются

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

Я не уверен, насколько это применимо к Chord, потому что я не так много читал об этом, но я думаю, что использование DHT — хорошая идея, если только вам не нужен нечеткий поиск.

Используйте Аккорд. http://en.wikipedia.org/wiki/Chord_(одноранговая сеть)

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top