🌵🌵🌵
Дополнение к посту про IPFS...
Спасибо @streamtv85 за замечания и дополнения
1) Допустим, что мы загружаем файл через клиент IPFS. На выходе мы получаем его хеш и он попадает в наш локальный кеш. Когда другому пользователю необходим наш файл, мы передаем ему его хеш. Система ищет данный файл и участника сети IPFS, у которого этот файл можно скачать. Так как данный файл находится только у нас и мы в сети, то второй клиент скачает этот файл у нас и подгрузит автоматически его к себе в кэш. Следующий клиент может запросить файл по нашему хешу и получить его, например, от второго клиента, при этом первому клиенту для этой операции уже нет необходимости быть в сети.
Вот тут и всплывает первый недостаток:
"Недостаток самой публичной сети ipfs из коробки (без всяких дополнительных настроек): хоть они на сайте и заявляют, что сама IPFS сеть является distributed and permanent, но у владельцев нод сети нет абсолютно никакой мотивации хранить твои данные вечно. Да, они могут его загрузить себе, тогда данные будут реплицированы. но они в любой момент могут их удалить (например чтоб освободить место). То есть нет гарантии того, что данные будут храниться в сети вечно. Будут храниться только те, которые интересны людям на данный момент"
2) Узлы IPFS знают, у каких из них есть желаемый файл благодаря использованию DHT (Distributed Hash Table) — распределенная хэш-таблица. Это децентрализованная распределенная система для объединения большого количества постоянно исчезающих и появляющихся узлов и эффективной передачи сообщений между ними.
"Узлы ipfs не соединяются каждый с каждым, а образовывают так называемые "стаи", из ближайших узлов. Вот в пределах "стаи" и работает DHT."
Когда поднимается нода, (любой компьютер, подключенный к сети, который контактирует посредством P2P-протоколов) она открывает IPFS, и чем выше будет количество пиров (участников файлообмена), тем выше будет обработка запросов (для получения обьектов через ipfs), а следовательно и DHT (распределенная хэш-таблица).
При чем уменьшение этой таблицы не приведет к уменьшению времени обработки запросов, так как система будет опрашивать пиры на наличие хэша, а те пиры свои пиры и т.д.
Тут то и второй недостаток:
"Не очень высокое быстродействие и проблемы с масштабированием - это один из ее недостатков"
И небольшое видео о применении IPFS на практике
⬇️⬇️⬇️
https://www.youtube.com/watch?v=CTwQpDCaLME
Дополнение к посту про IPFS...
Спасибо @streamtv85 за замечания и дополнения
1) Допустим, что мы загружаем файл через клиент IPFS. На выходе мы получаем его хеш и он попадает в наш локальный кеш. Когда другому пользователю необходим наш файл, мы передаем ему его хеш. Система ищет данный файл и участника сети IPFS, у которого этот файл можно скачать. Так как данный файл находится только у нас и мы в сети, то второй клиент скачает этот файл у нас и подгрузит автоматически его к себе в кэш. Следующий клиент может запросить файл по нашему хешу и получить его, например, от второго клиента, при этом первому клиенту для этой операции уже нет необходимости быть в сети.
Вот тут и всплывает первый недостаток:
"Недостаток самой публичной сети ipfs из коробки (без всяких дополнительных настроек): хоть они на сайте и заявляют, что сама IPFS сеть является distributed and permanent, но у владельцев нод сети нет абсолютно никакой мотивации хранить твои данные вечно. Да, они могут его загрузить себе, тогда данные будут реплицированы. но они в любой момент могут их удалить (например чтоб освободить место). То есть нет гарантии того, что данные будут храниться в сети вечно. Будут храниться только те, которые интересны людям на данный момент"
2) Узлы IPFS знают, у каких из них есть желаемый файл благодаря использованию DHT (Distributed Hash Table) — распределенная хэш-таблица. Это децентрализованная распределенная система для объединения большого количества постоянно исчезающих и появляющихся узлов и эффективной передачи сообщений между ними.
"Узлы ipfs не соединяются каждый с каждым, а образовывают так называемые "стаи", из ближайших узлов. Вот в пределах "стаи" и работает DHT."
Когда поднимается нода, (любой компьютер, подключенный к сети, который контактирует посредством P2P-протоколов) она открывает IPFS, и чем выше будет количество пиров (участников файлообмена), тем выше будет обработка запросов (для получения обьектов через ipfs), а следовательно и DHT (распределенная хэш-таблица).
При чем уменьшение этой таблицы не приведет к уменьшению времени обработки запросов, так как система будет опрашивать пиры на наличие хэша, а те пиры свои пиры и т.д.
Тут то и второй недостаток:
"Не очень высокое быстродействие и проблемы с масштабированием - это один из ее недостатков"
И небольшое видео о применении IPFS на практике
⬇️⬇️⬇️
https://www.youtube.com/watch?v=CTwQpDCaLME