voidlizard
/
hbs2
mirror of https://github.com/voidlizard/hbs2
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

hbs2-git-problem document added

This commit is contained in:
Dmitry Zuikov 2023-05-03 06:13:43 +03:00
parent e1cea76d27
commit 1428324f17
2 changed files with 635 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
docs/hbs2-git-problem/Makefile Normal file
View File

@ -0,0 +1,8 @@
.PHONY: all clean
all:
xelatex hbs2-git-problem.tex < /dev/null
xelatex hbs2-git-problem.tex < /dev/null
clean:
rm -f *.aux *.log *.nav *.out *.snm *.vrb *.toc

627
docs/hbs2-git-problem/hbs2-git-problem.tex Normal file
View File

@ -0,0 +1,627 @@
\documentclass[11pt,a4paper]{article}
\usepackage{polyglossia}
\usepackage{xltxtra}
\usepackage[margin=2cm,a4paper]{geometry}% http://ctan.org/pkg/geometry
\usepackage{pdfpages}
\usepackage{graphicx}
\usepackage[ddmmyyyy]{datetime}
\usepackage{booktabs}
\usepackage{enumitem}
\usepackage{amssymb}
\usepackage{amsmath}
\usepackage{bm}
\usepackage[nomessages]{fp}
\usepackage{caption}
\usepackage{url}
\usepackage{indentfirst}
\usepackage[parfill]{parskip}
\usepackage[ colorlinks=true
, linkcolor=black
, anchorcolor=black
, citecolor=black
, filecolor=black
, menucolor=black
, runcolor=black
, urlcolor=blue]{hyperref}
\usepackage{tikz}
\usetikzlibrary{arrows,snakes,shapes,backgrounds,positioning,calc}
\usepackage{marvosym}
\usepackage{pifont}
\usepackage{fontspec}
\usepackage{fontawesome5}
\setmainlanguage{russian}
\defaultfontfeatures{Ligatures=TeX,Mapping=tex-text}
\setmainfont{Liberation Serif}
\newfontfamily\cyrillicfont{Liberation Serif}[Script=Cyrillic]
\setlist{noitemsep}
\setlength{\intextsep}{2cm}
\renewcommand{\dateseparator}{.}
\renewcommand*\contentsname{Содержание}
\graphicspath{ {img/}}
\title{Проблема репозитория HBS2 GIT}
\begin{document}
\maketitle
\section{Определения}
\begin{description}[itemsep=10pt]
\item[Объект] Любой объект, сохраняемый и передаваемый в системе. Файл,
структура данных и т.п.
\item[Блок] Адресуемые (имеющие криптографический хэш) данные. Данные это последовательность байт.
Может быть любого размера, типичный размер: не более 256K. Зашифрованный блок может
быть больше, так как при шифровании в него добавятся данные алгоритма шифрования.
Блок может быть и меньше 256K, допустим блок это маленький объект. Тогда размер блока
будет равен размеру объекта.
\par \textbf{Note:} при шифровании данные можно предварительно сжимать.
\item[Чанк] Нумерованая часть \textit{блока}. Для каждого блока известного размера можно построить
единственное разбиение на чанки заданного размера. Размер чанка выбирается таким
образом, что бы его можно было поместить в UDP пакет безопасного размера.
Безопасного это такого, что можно не заботиться о фрагментации. Считается безопасным
размер UDP пакета 508 байт, на практике MTU всегда 1500 и либо фрагментацией
занимается сетевой стек и делает это хорошо, либо MTU других размеров уже не
встречаются, в любом случае практических проблем с размером чанка = 1400 не
встретилось. В системе размер чанка принят за 1200 --- 1400 байт. Чанк используется
в протоколе передачи блоков: так как по UDP мы не можем запросить блок целиком, мы
запрашиваем его по частям, каждая такая часть и есть чанк. В протоколе существует
возможность запрашивать не каждый чанк одельно, а последовательностями, именуемыми
burst.
\item[BlockSize] Размер блока. Может быть любой, не должен быть слишком
маленьким, но и слишком большим. Типично в районе 256K.
\item[ChunkSize] Максимальный рамер чанка. Должен иметь размер, не превышающий
максимального безопасного размера для UDP (1200 --- 1400
байт) (с учетом заголовка пакета).
\item[Burst] Последовательность чанков в протоколе. Клиент запрашивает не по каждому чанку
отдельно, а сериями по N чанков, начиная с k-го. Каждая такая последовательность
и есть burst.
\item[Merkle~Tree] Любой крупный объект, данные или последовательность объектов
разбивается на блоки при помощи построения его Merkle дерева
(в нашей интерпретации). Дерево имеет два параметра:
количество элементов в каждом узле, и размер (в каком-то виде) каждого
элемента. Построение дерева происходит в два этапа: сначала мы производим
разбиение, учитывая эти два параметра, затем --- обходим получившееся дерево,
сериализуем каждый узел (пишем блоки в \textit{хранилище}), и из полученных
при сериализации хэшей строим уже дерево Меркля (Merkle~Tree).
Дерево может состоять из узлов типа (Merkle~Tree) либо Leaf
- указание на блок (данных).
\item[Annotated~Merkle~Tree] Merkle~Tree с аннотацией в виде либо короткой
строки, либо ссылкой на блок с метаинформацией.
\item[Peer] Пир. Участник сети, авторизованный своим криптографическим ключом
подписи, и поддерживающий протоколы системы.
\item[RTT] Round trip time, время на посылку запроса и получение
ответа (в сети). Можно рассматривать на уровне прикладного протокола HBS2,
можно на уровне транспортного (TCP). Обычно имеется ввиду уровень протокола
HBS2.
\item[Reflog] Механизм реализации изменяемой ссылки. Каждая ссылка
определяется неким публичным ключом. Для каждой ссылки можно опубликовать
транзакцию, короткий (ChunkSize) блок данных, который может либо содержать
произвольные данные, либо \textit{ссылку} на блок или Merkle~Tree. В случае,
если внутри ссылка -- то данные ссылки будут скачаны пиром автоматически
рекурсивно. Все транзакции Reflog упорядочиваются по их хэшам в виде списка,
который сохраняется в виде Merkle~Tree. Таким образом, значение ссылки типа
Reflog это хэш Merkle~Tree упорядоченного по хэшам списка транзакций.
\end{description}
\section{Проблема}
Медленная передача большого количества маленьких объектов (блоков).
Приводит к очень медленному первоначальному скачиванию репозитория.
Обновления затем происходят с приемлемой скоростью.
Связано с тем, что в текущем протоколе для каждого передаваемого адресуемого
блока нам нужно:
\begin{enumerate}
\item Запросить размер (выяснить его наличие)
\item Запросить его чанки
\end{enumerate}
Таким образом, скачивание одного маленького объекта занимает минимум:
\mbox{$ 2 \times RTT + C + T$}, где C - время обработки запроса на обеих
сторонах, T - время передачи самих данных.
На практике это означает, что например при типичном $ RTT = 50ms $ мы доcтигаем
скорости 6 блоков (чанков) в секунду, что даём нам не более 9Kb/s, реально в
районе 6 --- 8. Каковая скорость и наблюдается экспериментально.
Текущее устройство репозитория hbs2-git:
\begin{figure}[h!]
\centering
\begin{tikzpicture}[every node/.append style={font=\scriptsize}]
\node[ rectangle split
, rectangle split parts=3
, draw
, font=\scriptsize
, text width=3cm
, label={above:Reflog}
] (reflog)
{
Transaction~N
\nodepart{two}...
\nodepart{three}Transaction~1
};
\node[ rectangle split
, rectangle split parts=4
, draw
, font=\scriptsize
, text width=3cm
, right=2cm of reflog.north east, anchor=north west
, label={above:Object~list}
] (objlist)
{
\nodepart{one}HEAD~Object
\nodepart{two}Git Object~1
\nodepart{three}...
\nodepart{four}Git object~N
};
\node[draw,rectangle,below=2cm of objlist,xshift=-3cm,minimum
height=1cm,label={below:Git Object}]
(merkle) {Annotated~Merkle~Tree};
\draw[-latex] (reflog.15) -- (objlist.155);
\draw[-latex] (objlist.205) to [bend right,looseness=1] (merkle.north);
\end{tikzpicture}
\end{figure}
\begin{description}[itemsep=10pt]
\item[Reflog] Это Merkle~Tree списка \textit{транзакций}.
\item[Транзакция] Это небольшой объект (размера не больше ChunkSize),
произвольного содержания, в случае HBS2 Git -- со ссылкой на Merkle~Tree
списка объектов.
\item[Object list] Список всех достижимых объектов репозитория (транзитивное
замыкание всех объектов для коммита) + HEAD (список ссылок в смысле git и их значений)
\item[Git Object] Сохраненный в виде Annotated~Merkle~Tree объект git. В
аннотации указан тип объекта (commit, blob, tree)
\end{description}
Данное устройство было выбрано как
\begin{enumerate}
\item Наиболее простое и очевидное
\item Минимизирующее оверхед по данным на уровне git объектов -- т.е уже
имеющиеся git объекты никогда не будут скачиваться повторно
\item Любая транзакция описывает полный, консистентный репозиторий, т.е можно
не иметь полного набора транзакций, но иметь, тем не менее, полный
репозиторий.
\item Каждый когда-либо созданный git object доступен в сети пиров по хэшу его
Merkle~Tree, что казалось довольно удобно (но практически бесполезно)
\end{enumerate}
Несмотря на стремление к минимизации оверхеда по данным, данное устройство его,
тем не менее, создаёт в другом месте:
Каждое Merkle~Tree это минимум один дополнительный блок -- т.е блок на
Merkle~Tree + блок на блок данных.
Как можно видеть, данное устройство располагает к образованию большого
количества маленьких объектов: сами объекты git как правило маленькие,
транзакции = маленькие объекты (ChunkSize).
Большое число: 10---20 тысяч для репозитория размером порядка 600 коммитов.
Что, если взять скорость 5 блоков (чанков) в секунду (из оценки выше), приводит
к нас с показателю 4000 секунд на 20'000 блоков, что примерно соответствует
наблюдаемой картине (в реальности чуть лучше).
Несмотря на то, что последующие скачивания будут выполняться быстро (объекты не
будут выкачиваться повторно, будут скачаны только недостающие объекты, их
немного), первоначальное развертывание репозитория происходит неприемлемо
медленно.
Это и есть проблема.
\section{Возможные решения}
Что мы в принципе хотим добиться:
\begin{enumerate}
\item Быстрое скачивание всего репозитория;
\item Минимизировать оверхед по данным, т.е что бы одни и те же объекты
(разбитые на блоки), по возможности, скачивались один раз.
\end{enumerate}
\subsection{Большой лог}
Основная идея --- не порождать большое число маленьких объектов, как в текущем
дизайне, вместо этого ввести \textit{лог}, куда будут упорядоченно
писаться объекты git, каждый объект только один раз.
Такой лог представляет собой просто большой файл, который может передаваться
обычными механизмами с максимально высокой скоростью ( десятки Mb/s ).
Данное решение имеет недостатки:
\begin{itemize}
\item[-] Более нет соответствия $ git object \leftrightarrow merkle tree $
\item[-] При отсутствии выравнивания, логи разных форков репозиториев
не сойдутся никогда, следовательно, всегда будет перевыкачиваться
различающаяся часть и эта часть будет расти со временем
\item[-] При наличии <<крупного>> (256K) выравнивания оверхед по данным возрастает
на порядки ( ~ 3Gb для числа объектов $ \approx 12000$ )
\item[-] При наличии <<мелкого>> выравнивания оверхед всё равно
существенный ( $ \approx 50\% $ для блока размером 1K ),
но растёт число мелких объектов и соответствующим падением скорости
передачи.
\end{itemize}
\subsubsection{Большой лог всех объектов}
В случае выровненной записи --- получаем описанные выше недостатки.
В случае невыровненной записи --- получаем расхождение логов у разных писателей
(форков), соответствовать будет лишь начальная часть.
Можно ввести специальную дисциплину работы с логом и мерж лога, тогда можно
будет их переупорядочивать у всех, и логи будут периодически сходиться. Высокая
сложность реализации и много неоднозначностей.
Можно писать лог каждый раз при push, тогда для одинаковых git репозиториев
будут одинаковые логи. Очень медленно и время будет расти с ростом репозитория.
\textbf{Плюсы:}
простая реализация, быстрое первоначальное развертывание.
\textbf{Минусы:}
всё остальное.
\subsubsection{Отсортированный по времени/высоте сегментированный лог}
Как можно видеть, ситуация с большим логом объектов, даже отсортированных по
высоте/времени может приводить к перевыкачиванию значительной части лога в
ситуации, когда кто-то отредактировал историю так, что новые объекты появились в
начале лога, что допустимо в git. В случае больших репозиториев это приведёт к
скачиванию большого количества данных и хранению этих данных. Что бы реже
сталкиваться с подобной проблемой, будем строить стейт следующим образом:
\begin{figure}[h!]
\centering
\begin{tikzpicture}[every node/.append style={font=\scriptsize}]
\node[ rectangle split
, rectangle split parts=3
, draw
, font=\scriptsize
, text width=3cm
, label={above:Reflog}
] (reflog)
{
Transaction~N
\nodepart{two}...
\nodepart{three}Transaction~1
};
\node[ draw
, right = 2cm of reflog.north east, anchor=north west
, rectangle split, rectangle split horizontal, rectangle split parts=4
, label={below:PUSH log}
] (pushlog)
{ \nodepart{one}$S_1$
\nodepart{two}...
\nodepart{three}$S_n$
\nodepart{four}HEAD
};
\draw[-latex] (reflog.12) -- (pushlog) node[midway,above] {merkle~tree};
\end{tikzpicture}
\end{figure}
\begin{itemize}
\item[-] Каждая транзация $T_x$ содержит
отсортированные по времени (высоте) и по хэшу объекты репозитория
\item[-] $S(R_x) = \bigcup$ объектов из всех транзакций Reflog
\item[-] Берем объекты, отсутствующие в $S(R_x)$, сортируем по времени/высоте и затем хэшам
и пишем в лог в сжатом виде можно сжать весь лог)
\item[-] Объект HEAD пишем в тот же лог, начало или конец (TBD)
\item[-] Публикуем транзацию $T_y$, которая содержит ссылку на Merkle~Tree лога из предыдущего
пункта
\end{itemize}
\textbf{Следствия:}
\begin{itemize}
\item[-] Стейт $S(R_x)$ каждой ссылки $R_x$ обновляется инкрементально
\item[-] Каждое обновление (транзакция $T_x$) соответствует push в соответствующий
\textit{git~remote}
\item[-] Каждое обновление содержит объекты, отсутствующие в $S(R_x)$, отсортированные
детерменированным образом, зависимости только состояния репозитория git
\item[-] Каждый сегмент лога, кроме первого, как правило, сравнительно небольшой -- содержит
только новые объекты, созданные пользователем (commit, tree, blob)
\item[-] В рамках одной ссылки логи перевыкачиваться не будут, как логи (содержимое
Merkle~Tree транзаций $T_x$ создаются детерменированным образом в завимости только
содержимого репозитория git
\item[-] Частичные логи могут иногда совпадать, так что они не всегда будут дублироваться между
ссылками. Различные кейсы рассмотрим далее отдельно
\end{itemize}
\textbf{Ситуация 1:}
\begin{itemize}
\item[-] Алиса делает \textit{EXPORT} существующего репозитория в свою ссылку $R_a$
\item[-] Боб делает \textit{git~clone} данного репозитория (ссылки $R_a$)
\item[-] Боб создаёт новую ссылку $R_b$
\item[-] Боб делает \textit{EXPORT} репозитория в эту ссылку
и сообщает ссылку $R_b$ Алисе
\item[-] Боб делает изменения и делает \textit{git~push} в ссылку $R_b$
\end{itemize}
В этом случае:
\begin{enumerate}
\item Создаётся лог, содержащий объекты $S(R_a)$ --- все объекты репозитория,
в порядке создания/высоты и далее в порядке хэшей
\item Публикуется транзация $T_x$ со ссылкой на Merkle~Tree лога объектов
\item Боб принимает данную транзацию, объектов $S(R_a)$ --- данных объектов
у него еще нет, следовательно дублирования нет
\item Объекты $S(R_a)$ распаковываются в репозиторий git
\item Создаётся новая ссылка $R_b$. При \textit{EXPORT} создаётся
первоначальная транзакция, которая ровно такая же, как и $T_x$,
так как содержимое лога определяется только объектами репозитория git,
а они все из $S(R_a)$
\item Боб делает свои изменения и делает \textit{git~push}
\item Создается $T_{b1}$, содержащая объекты $S(R_{b1})$, отсутствующие в
$S(R_a)$
\item Алиса получает $T_{b1}$, содержащая объекты $S(R_{b1})$ и импортирует
эти объекты в свой репозиторий git.
\end{enumerate}
На шаге (5) мог не выполниться \textit{EXPORT}, так как его выполнение зависит
от пользователя. В этом случае на шаге (7) будет создана $T_{b1}$ содержащая все
объекты репозитория, включая те, что были созданы Бобом на шаге (6). В этом
случае, какое-то количество объектов в зависимости от гранулярности разбиения
(BlockSize), попадут в те блоки, что уже есть у Алисы в $S(R_a)$. И чем больше
был размер лога $S(R_a)$, тем больше объектов Алиса не будет скачивать повторно,
так как порядок следования определяется только объектами в репозитории, Боб не
переписывал историю и его объекты будут следовать за объектами Алисы.
Если же Боб переписал историю, что, в целом, возможно, то Алиса не будет
повторно выкачивать только часть лога до изменений Боба.
Таким образом видно, что при создании ссылки $R_b$ нужно форсировать операцию
EXPORT.
Как можно её форсировать, ведь Боб может и не создавать ссылку, или создавать
её в любой момент времени.
Например, при операции PUSH нужно каким-то образом получить все объекты,
которые шли раньше изменений Боба и создать транзакцию $T_{b0}$ в которой
будут эти объекты.
Как система должна понять, что этот \textit{git~push} --- не первоначальная
инициация репозитория, а апдейт? Например, так: при \textit{FETCH}
в случае отсутствия транзакций создаётся (и публикуется) первая транзакция.
Тогда в большей части случаев она будет соответствовать инициации репозитория,
и при последующем \textit{PUSH} или \textit{EXPORT} в создаваемую транзакцию
попадут только те объекты, которые создал владелец новой ссылки (Боб в нашем
случае).
\subsubsection{Merkle~Tree+лог с переменным разбиением}
\begin{figure}[h!]
\centering
\begin{tikzpicture}[every node/.append style={font=\scriptsize}]
\node[ rectangle split
, rectangle split parts=3
, draw
, font=\scriptsize
, text width=3cm
, label={above:Reflog}
] (reflog)
{
Transaction~N
\nodepart{two}...
\nodepart{three}Transaction~1
};
\node[ rectangle split
, rectangle split parts=5
, draw
, font=\scriptsize
, text width=3cm
, right=2cm of reflog.north east, anchor=north west
, label={above:Object~list}
] (objlist)
{
\nodepart{one}HEAD~Object
\nodepart{two}SmallObjectLog
\nodepart{three}...
\nodepart{four}BigGitObject
\nodepart{five}...
};
\node[draw,rectangle,below=1cm of objlist.north east,xshift=2cm,minimum
height=1cm,label={[xshift=1.2cm]above:Small~Object~Log}]
(smallmerkle) {Merkle~Tree};
\node[right=0.1cm of smallmerkle,text width=4.2cm,font=\scriptsize]
(smallmerklenote) {С переменным шагом разбиения:\\один объект=один лист};
\node[ rectangle split
, rectangle split parts=4
, draw
, font=\scriptsize
, text width=3cm
, below=1cm of smallmerkle
, label={below:SmallObjectLog}
] (objlog)
{
\nodepart{one}SmallObject~1
\nodepart{two}...
\nodepart{three}SmallObject~N
\nodepart{four}...
};
\node[draw,rectangle,below=2cm of objlist,xshift=-3cm,minimum
height=1cm,label={below:Git Object}]
(merkle) {Annotated~Merkle~Tree};
\draw[-latex] (reflog.15) -- (objlist.155);
\draw[-latex] (objlist.200) to [bend right,looseness=1] (merkle.north);
\draw[-latex] (objlist.12) -| (smallmerkle.north);
\draw[-latex] (smallmerkle.south) -- (objlog.north);
\end{tikzpicture}
\end{figure}
Несмотря на то, что сейчас дерево разбивается на блоки фиксированного размера,
необходимости в этом нет. Это означает, что мы можем генерировать Merkle~Tree
таким образом, что каждому маленькому объекту будет соответствовать один объект
(лист) Merkle~Tree (т.е они не будут разбиваться: мы сначала генерируем лог
<<маленьких>> объектов, затем разбиваем его, принимая во внимание размер каждой
секции (заголовок+объект), так что каждая секция --- ровно один лист (хэш)
Merkle~Tree.
\textbf{Требование:} Каждый <<маленький>> объект должен быть достаточно
маленьким для того, что бы можно было его безопасно читать в память.
<<Большие>> объекты передаются ровно так, как сейчас, то есть каждый отдельно.
<<Большие>> это, допустим, от 1Mb.
\textbf{Плюсы:}
\begin{itemize}
\item[+] Выполняется требование отсутствия оверхеда по данным
\item[+] Нет множества <<мелких>> объектов: лог <<большой>>,
отдельные объекты тоже <<большие>>.
\end{itemize}
\textbf{Минусы:}
\begin{itemize}
\item[-] Передаваться будет дольше, чем <<большой>> лог
\item[-] Средняя сложность реализации
\item[-] <<Переменное разбиение>> $ => $ объекты git маленькие $ => $ много
маленьких объектов $ => $ \textbf{не работает}
\end{itemize}
\subsection{Ускорение скачивания мелких объектов}
Невредно сделать в любом случае, однако полезность данного механизма может
варьироваться, а сложность может быть велика. Мы рассматриваем в первую очередь
ограничения UDP, так как в настоящий момент по TCP ходят в точности такие же
протоколы, как и по UDP. Это может быть изменено, но потребуется поддержка
механизмов, которые будут динамически разрешать или запрещать протоколы в
зависимости от типов транспорта. Это возможно, сложность --- ниже средней.
\subsubsection{Пакетные запросы}
Поскольку мы можем передать по UDP 1200 --- 1400 байт в одной датаграмме,
мы можем запросить $ 1200 / 32 \approx 32 $ объекта за один раз.
Но если речь идёт о UDP, то ответ, очевидно, не может быть получен в одной
датаграмме, значит, нужен какой-то механизм стриминга/сборки ответа из кусков,
и уже имеющийся механизм не подходит, так как ответ создаётся динамически и
отсутствует в хранилище. Таким образом, его надо или создавать в хранилище (и
увеличивать число данных, причём, мусора), либо как-то создавать временный
ответ и скачивать его текущими механизмами.
Это возможно, но неизящно:
\begin{enumerate}
\item Получить запрос
\item Сформировать ответ (записать данные на /tmp допустим)
\item Посчитать хэш ответа ( как блока(!) )
\item Добавить хэш в специальную таблицу <<временные объекты>>
\item Сообщить хэш и размер запрашивающей стороне
\item Запрашивающая сторона получает блок обычным способом
\item При обработке запроса сервер смотрит, не является ли блок временным
объектом и читает его, а не хранилище
\end{enumerate}
Кроме того, ускорение может получиться не столь значительным, так как
мы можем не знать все объекты заранее, и что бы их узнать, надо сначала
скачать другие объекты.
Из наблюдаемых явлений видно, что в какой-то момент времени очередь запросов
становится весьма большой ( $ \approx 10K $ объектов ), следовательно, можно
запрашивать объекты пачками, следовательно, будет иметь место ускорение в $
\approx 32 $ раза, что приведёт к скорости отдачи мелких объектов в районе
160Kb/s. Что не бог весть что, на самом деле. Текущие скорости отдачи
"нормальных" объектов составляют около ширины канала, десятки мегабайт в
секунду.
\subsubsection{Стриминг Merkle~Tree}
Специальная команда, в ответ на которую передаются все блоки Merkle~Tree, не
дожидаясь запросов.
Проблематичная реализация на UDP, в виду возможного реордеринга и потери
пакетов, а имеющийся текущий механизм, устойчивый к реордерингу и потерям,
неприменим.
Вернее, он применим, если мы создадим механизм <<временного>> хранилища --
аналогичного обычному, но существующему лишь некоторое время. Тогда
любые промежуточные объекты могут быть созданы, существовать в
течение сессии или некоторого времени и впоследствии удалены.
Можно и не создавать временное хранилище, а помечать объекты, как временные
и рекурсивно удалять через некоторое время.
Можно создавать временный объект <<транзитивного замыкания>> для дерева,
сообщать его хэш, и давать клиенту скачивать его обычным образом.
Можно видеть, что любые варианты пакетного скачивания объектов ведут к
работе <<сервера>> и расходованию его ресурсов, т.е при незначительном
усилии со строны клиента (один запрос) сервер вынужден сканировать десятки
тысяч объектов и создавать временные объекты потенциально любых размеров,
что открывает путь для намеренных и ненамеренных атак на пира.
Если у нас есть надёжный транспортный протокол (TCP) то можно стримить данные,
не создавая временных структур, тогда затраты локальных ресурсов будут ниже,
но тем ме менее, возможность DoS остаётся: одна команда со стороны <<клиента>>
приводит к несопоставимо большой вычислительной работе <<сервера>> и передачи
большого объема данных (много больше исходного запроса).
\end{document}