IPFS: обнаружение провайдеров

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

Мы не подключаем Helia или Kubo к сети, не публикуем provider-записи и не измеряем маршруты. Схема описывает механизмы и ожидаемые отказы для собственного проекта библиотеки.

Узнать место, затем получить

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

известный CID
   ↓ поиск провайдера
кандидаты мест выдачи
   ↓ поддерживаемое соединение
получение блоков
   ↓ проверка структуры
восстановленный файл

На каждом этапе возможен самостоятельный отказ. Нет сведений о провайдере, есть запись устаревшего участника, не подходит транспорт, тайм-аут ответа или не хватает дочернего блока. Одна общая ошибка «CID не существует» не объясняет эти случаи.

DHT не хранит учебник

Распределённая таблица помогает находить сведения об участниках и предоставляемых данных по предусмотренным механизмам. Она не является хранилищем полного текста каждой адресуемой книги. Если провайдер перестал работать, запись о нём не создаст его блоки заново.

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

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

Bitswap и обмен

Bitswap организует запрос и передачу блоков между участниками в предусмотренной модели. Клиент может нуждаться не в одном объекте, а в множестве блоков DAG. После получения корневого узла он узнаёт дальнейшие ссылки и продолжает чтение.

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

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

Иные маршруты

Современный клиент может использовать HTTP-маршрутизацию и получение блоков через поддерживаемые сервисы. Это полезно в браузере, где обычные сетевые соединения ограничены. Однако внешний сервис наблюдает запросы и имеет собственную доступность.

В Helia 7 HTTP и libp2p настраиваются модульно. Подключение одного маршрута не обязательно включает другой. Если приложение использует только HTTP, нельзя описывать его как самостоятельный прямой обмен с любыми публичными участниками. Профиль должен назвать фактические зависимости.

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

Полнота провайдера

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

Для библиотеки критерий хранения включает достижимые необходимые блоки либо проверенный полный архив. Реплики проверяются независимо: если две службы на деле обращаются к одному отсутствующему источнику, их количество не равно двум сохранённым копиям.

Статус доставки полезно описывать стадиями root_found, retrieving, verified и unavailable. Они относятся к запросу читателя. Отдельно хранитель сообщает своё состояние закрепления. Один интерфейс не должен смешивать клиентское чтение и обязанность долгосрочного хранения.

Найденный источник не отдал весь урок

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

Другая ситуация — провайдер обозначен в маршрутизации, но сейчас недоступен по поддерживаемому транспорту. Тогда нельзя делать вывод, что блок удалён из всей сети. Сведения могли устареть, соединение могло быть ограничено, а другая копия могла остаться доступной. Библиотечный клиент пробует предусмотренные альтернативы в ограниченном бюджете, сохраняя причины отдельных отказов. Он не превращает один неуспешный маршрут в доказательство полного отсутствия данных.

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

Таким образом, запись диагностики связывает ожидаемый CID, выбранную цель, способ поиска, найденный источник и стадию получения. Для полного каталога фиксируется ещё полнота достигнутого набора. Оператор может увидеть, что манифест доступен, а иллюстрация нет, вместо расплывчатой ошибки «IPFS не работает». Эти сведения описывают конкретное наблюдение, а не глобальную карту сети. При этом журнал запросов способен раскрывать интерес читателя к определённым материалам, поэтому диагностике также требуется разумный состав и срок хранения.

Наблюдаемость и приватность

Запросы раскрывают интерес к объекту участникам маршрута. Содержание открытого выпуска не скрыто, но набор читаемых материалов может быть чувствительным. Библиотека должна понимать, кому отправляются CID и какие журналы ведёт её собственный шлюз.

Собственный источник может уменьшить часть внешних зависимостей, но не делает все сетевые данные невидимыми. Шифрование транспорта защищает определённый канал, а не превращает публичный DAG в закрытый объект. Отдельный урок рассмотрит содержание и ключи.

Механизмы описаны в документации DHT и Bitswap. После урока найденный провайдер является кандидатом выдачи, а не доказательством полной доступности. Это основание для следующего разбора ограничений браузерного клиента.

Оглавление серии