IPFS: Pinning и удержание DAG

Выпуск можно получить сейчас, но будет ли он сохранён после уборки хранилища? Pinning обозначает удержание нужных объектов в выбранной системе. В уроке отделим закрепление корня, сохранение зависимостей и реальную доступность хранителя. Эти понятия нужны библиотеке для обещанного архива версий.

Мы не запускаем клиент, не вызываем API закрепления и не проводим сборку мусора. Состояния ниже — модель процедуры. Пользовательские токены и аккаунты поставщиков не используются.

Удержание нужного набора

Когда клиент получает данные, блоки могут оказаться в локальном хранилище как временные или уже ненужные после чтения. Политика уборки освобождает место. Закрепление сообщает, какие данные нужно удерживать по выбранным правилам.

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

Понятия и API конкретного клиента различаются. Мы не переносим буквальную команду Kubo в Helia и не предполагаем одинаковый механизм автоматической уборки. Досье сначала задаёт результат удержания, затем связывает его с поддерживаемым инструментом.

Корни нескольких редакций

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

edition-1 ROOT ──→ общий CSS
              └─→ старый урок
edition-2 ROOT ──→ общий CSS
              └─→ новый урок

Это схема зависимостей, а не доказательство конкретного повторного использования при нашем профиле. Импорт не проводился. Её смысл — показать, почему уборка должна учитывать ссылки и живые корни, а не только имена файлов редакционного каталога.

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

Закрепление не гарантирует ответ

Локально закреплённые блоки могут находиться на выключенном компьютере. Диск может отказать, соединение — не поддерживаться клиентом, а объявления провайдера — устареть. Поэтому наличие pin не является полной проверкой доступности читателю.

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

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

Что подтверждать после запроса

Процедура имеет стадии: запрошено, выполняется, завершено, отказ. Если закрепление асинхронное, HTTP-ответ о создании задачи ещё не является завершением. Сохраняем идентификатор запроса и получаем конечный статус.

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

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

Безопасная уборка

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

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

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

Общие блоки двух закреплённых редакций

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

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

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

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

Ожидаемый результат

Для будущего локального разбора закреплённый выпуск должен сохранять все необходимые части после предусмотренной уборки, а незакреплённые временные данные могут исчезнуть. Затем отдельный клиент получает выпуск и проверяет объявление. Сейчас такие действия не выполнялись; это критерии процедуры.

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

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