Pull to refresh

Comments 13

UFO just landed and posted this here
UUID тут не подходит, идентификатор должен однозначно зависеть от содержимого файла, а не генерироваться случайно. Взяли с запасом — чтобы избежать атаки дней рождения с учётом возможных атак злонамеренных личностей. Например, правообладателей (вспомним фирмочки, выкладывавшие мусор с привлекательными названиями в P2P-сети).
Кстати, неясно, насколько сеть защищена от целенаправленного захламления большим количеством мусорных файлов.
UFO just landed and posted this here
Насколько я понял статью Mithgol, раздаются только те файлы, которые запрашиваются. Чтобы замусорить сеть, нужно одновременно раздавать и запрашивать мусор на разных краях сети. Это вроде бы не невозможно, но заметно дороже, чем в некоторых других P2P-схемах.
Замусорить сеть «можно», но для этого понадобится не менее квадриллиона иоттабайтов.
Для замусоривания сети достаточно, чтобы объём хранимого там мусора на порядки превышал объём полезной информации. Вряд ли участникам сети будет интересно замусоривать свои хранилища терабайтами бессмыслицы, среди которых сиротливо вкраплены отдельные байты чего-то нужного. Квадриллионы йоттабайтов — это для коллизии хешей.
А вот принцип раздачи только запрошенных файлов, про который говорит ruikarikun, как раз решает проблему с мусором, хотя при этом начинаешь задумываться о том, не начнут ли становиться недоступными непопулярные, но всё же полезные файлы.
странная валидация, попытка «угадать хэш» ipfs.pics/ipfs/QmcT99xWRNDAYunp7Zr8wGiwMKSgVfDpfbXw9hBtLCM4Ma (a вместо m ) заставило сервер сильно призадуматься — минут 5 уже ищет
надеюсь ничего там не сломал
Это не валидация. Он просто ищет картинку по всем пирам (по цепочке).
Если картинка есть — все просто, ее отдаст первый же откликнувшийся пир у которого имеется ее копия.
Но вот если ее нет — сложнее, тут же нет центрального сервера с БД всех имеющихся картинок (хотя бы их перечнем), который сразу бы ответил — такого файла в нашей сети нет, идите лесом. Если нет у 100 опрошенных пиров, не значит что ее не может быть у 101го.

Если же задать некорректный хэш (нарушить формат) то проверка и ответ приходят быстро (пару раз проробовал порядка 200-300 мс задержка) и выдает что-то такое:
Path Resolve error: multihash length inconsistent: &{1 97 [42 112 107 115 78 68 200 48 108 223 141 125 203 120 242 53 141 189 109 235 67 196 53 250 11 151 16 103 192 73 133]}

А вот корректный хэш, но от несуществующей в реальности картинки — да, задумывается надолго. Правда врядли это какую-то нагрузку значительную создает, скорее всего это просто ожидание истечения таймаутов у пиров которые недавно были в сети (и поэтому еще числятся активными), но отключились/имеют проблемы со связью.
Просто хэшу не помешал бы какой-нибудь контрольный символ, по которому можно было бы проверять формальную корректность хэша без опроса всех пиров. Это застраховало бы от задержек при подобных «опечатках».
P.S. Раньше разработчики IPFS запустили криптовалюту, привязанную к распределённому файлохостингу, Filecoin.

Поправка — создали (большую часть по крайней мере), но пока так еще и не запустили.
А жаль, читал про нее давно, идея понравилось. Но пока так и не дождался опробовать в реальной работе…
UFO just landed and posted this here
Все работает. Вероятно был «хаброэффект» по случаю запуска. В сети уже тысячи изображений залито и используется.

Кстати можно посмотреть что обычно сейчас заливают другие пользователи: ipfs.pics/random — при каждом новом клике случайно выбирается любая из картинок хранящихся в этой p2p сети
Судя по коду проекта, пока что (временно) для бэкенда используется S3, но от него откажутся при регистрации в сети большого количества узлов.
при этом IP в бутстрапе:
ipfs bootstrap add /ip4/45.55.151.20/tcp/4001/ipfs/QmdkJZUWnVkEc6yfptVu4LWY8nHkEnGwsxqQ233QSGj8UP
— относится к сети Digital Ocean; в этот же IP разрешается домен ipfs.pics.

Может там всё-таки только DO, без S3?
Sign up to leave a comment.

Other news