| 1.1, Dmitry (??), 22:46, 10/01/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
А где хранится адрес откуда скачивать блоки образа? Ведь при создании индекса zsyncmake создается только индекс.
| | |
| |
| 2.2, Аноним (-), 23:10, 10/01/2013 [^] [^^] [^^^] [ответить]
| +/– |
> А где хранится адрес откуда скачивать блоки образа? Ведь при создании индекса
> zsyncmake создается только индекс.
В файлике с расширением .zsync вначале идёт блок мета-данных, где указано имя файла, размер блока и другая информация.
| | |
| 2.3, Аноним (-), 23:13, 10/01/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
> А где хранится адрес откуда скачивать блоки образа? Ведь при создании индекса
> zsyncmake создается только индекс.
Блоки грузятся из основного файла, который выложили для загрузки. Этот файл логически разбивается на сегменты, для которых в индексе хранятся контрольные суммы. Когда zsync загружает индекс, он сверяет контрольные суммы того что уже есть на стороне пользователя и то что различается грузить с удалённого сервера используя HTTP/1.1 заголовок Range.
| | |
| |
| 3.14, Sw00p aka Jerom (?), 20:05, 20/02/2013 [^] [^^] [^^^] [ответить]
| +/– | |
хммм а разве не одно и тоже получает? он же вроде должен весь файл сверить поблочно и это равносильно скачиванию с сервера или я чтото недопонял
как реализован механизм контрольных сумм и чего ?
| | |
|
| |
| |
| 4.16, Аноним (-), 05:07, 07/03/2013 [^] [^^] [^^^] [ответить]
| +/– |
Клиентской ясен фиг. Клиент качает .zsync и смотрит что у него есть и насколько оно совпадает с вот этим вот описанием. Что не совпадает - качается с сервака.
| | |
|
|
|
| |
| 2.5, Пользователь Debian (?), 02:37, 13/01/2013 [^] [^^] [^^^] [ответить]
| +/– |
Торрент не умеет эффективно выкачивать изменения в уже имеющимся файле. Основное применение rsync это *инкрементная* передача данных.
| | |
| |
| 3.7, XoRe (ok), 01:16, 14/01/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > Торрент не умеет эффективно выкачивать изменения в уже имеющимся файле.
o'rly?
Сегмент (англ. part — часть) — все файлы для передачи делятся на небольшие куски — сегменты, которые, затем, передаются по сети в произвольном порядке для оптимизации обмена.
1. Выкладываете новый torrent файл
2. Пользователи его тыкают
3. bittorent клиент анализирует имеющийся у клиента iso, сравнивает crc каждого сегмента
4. Клиент закачивает только изменившиеся сегменты
5. PROFIT!
В остальном, программа имеет право быть. Хотя это отдельная программа.
Её профит скорее для сервера - можно использовать http сервер, со всеми его плюшками (бекенды, балансировка, и т.д.), не нужно поднимать *sync сервер.
Клиент все равно должен использовать специальную программу для скачивания
Было бы классно, если бы был плагин к FF с такой функциональностью.
| | |
| |
| |
| 5.9, pavlinux (ok), 02:44, 14/01/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > Спасибо, не знал про такую особенность протокола.
Через Magnet по-моему (или что-то ещё нужно) можно вообще обновлять
без уведомления клиентов. Просто в папку кидаешь новый файл с тем же
именем, а оно само по клиентам расползается.
А ещё есть PerFS, P2PFS, и другая распределённая хрень.
| | |
|
| 4.10, Pilat66 (?), 12:00, 14/01/2013 [^] [^^] [^^^] [ответить]
| +/– |
Насчёт торрента - если в начало файла добавится один байт, сработает ли ?
| | |
| |
| 5.12, pavlinux (ok), 02:06, 15/01/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> Насчёт торрента - если в начало файла добавится один байт, сработает ли ?
Не, там всё сдвинется на один байт.
| | |
|
|
|
|
| |
| 2.13, qux (ok), 22:59, 27/01/2013 [^] [^^] [^^^] [ответить]
| +/– |
 Поправьте если не так, но это может профильный кейс для jigdo (сборка iso из кучи rpm-файлов и одного со служебной информацией). В случае если большой файл "атомарный", это не прокатит.
А вообще как выше сказали, тут скорее торрент альтернатива. Плюс, если данные нужны многим, еще и распределенное хранение вместо одного сервера, и скорость скачивания.
| | |
|
|