Поддержание целостности сети в одноранговой сети - PullRequest
3 голосов
/ 04 декабря 2009

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

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

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

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

Ответы [ 6 ]

3 голосов
/ 04 декабря 2009

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

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

2 голосов
/ 17 декабря 2009

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

2 голосов
/ 14 декабря 2009

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

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

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

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

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

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

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

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

1 голос
/ 17 декабря 2009

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

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

Используйте аккорд. http://en.wikipedia.org/wiki/Chord_(peer-to-peer)

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

0 голосов
/ 15 декабря 2009

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

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

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

...