Это общая проблема в P2P, известный как оригинальное Введение, хотя самонастройки также хорошее слово. Проблема с самозагрузкой в ​​том, что вы не можете децентрализацию его. Является ли это IRC или HTTP или DNS, клиент должен быть жёстко с адресом или списком адресов, которые достаточно свежи, что по крайней мере один из перечисленных адресов активен. После того, как не первый узел достигнут, вы больше не в первоначально режиме Введения и можете использовать весь спектр методов децентрализации, такие как сплетни. Если, конечно, вы не получите отсоединены от сети и все ваших известных коллег уходят, в этом случае вы вернулись к самонастройке.

Есть два свойства, которые расходятся, когда вы выбрали метод самонастройки: надежность (масштабируемость / надежность) и свежесть. Надёжность повышается за счет свежести путем кэширования на нескольких серверах, как это обычно делается со списками HTTP пэра. Свежесть максимизируется (по крайней мере, до истечения времени ожидания TCP) за счет надежности, имея все связаны, как с IRC. Конечно, ключ найти правильное сочетание прочности и свежести, потому что нужно как для начальной загрузки, чтобы быть успешным.

Вот некоторые из моих нынешних любимых методов самозагрузки:

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

Подключение через XMPP к Google App Engine приложения. Это дает свежесть IRC, но с более надежным масштабированием. App Engine в основном для написания веб-приложений, но он обеспечивает электронную почту и обработку XMPP, а также. Это было бы просто написать одно приложение, которое может обрабатывать списки одноранговые либо через XMPP или HTTP с тем же кодом обработчика. В настоящее время я использую это в приложении, и она работает хорошо, и очень надежна. Я только хотел было второй App Engine, чтобы использовать в качестве запасного варианта, потому что у него есть время от времени простоя.

Альтернатива требует, чтобы все узлы включают сложность протокола, как IRC или XMPP должен иметь несколько специальных узлов дозорных, которые сидят в сети и собирать адреса подключенных узлов с помощью обычных децентрализованных методов, доступных для активного узла. Эти сторожевые узлы периодически загружать новые адреса, скажем, с помощью POST HTTP на ряд веб-сайтов. Новый узел может затем загрузить свежий список адресов из любых сайтов, которые в настоящее время функционируют и достижимость. Если у вас есть 5 сторожей каждый загрузки каждые 5 минут (в шахматном порядке), то вы должны будете обновления примерно раз в минуту. Это находится на одном уровне с IRC с точкой зрения свежести и надежно, как вы заботитесь, чтобы сделать это путем изменения количества HTTP зеркал и количества часовых.