From: Oana Baron Date: Tue, 7 Jun 2011 18:30:20 +0000 (+0300) Subject: Update research2: finish intro X-Git-Url: http://p2p-next.cs.pub.ro/gitweb/?a=commitdiff_plain;h=875d343c0d4b39ab781d553db244e3ae86ef67a8;hp=8e8f1b9dde005398387a93317dc17326f45ade89;p=swifty.git Update research2: finish intro --- diff --git a/doc/research2/img/arch1.pdf b/doc/research2/img/arch1.pdf new file mode 100644 index 0000000..eba161b Binary files /dev/null and b/doc/research2/img/arch1.pdf differ diff --git a/doc/research2/img/tree.png b/doc/research2/img/tree.png deleted file mode 100644 index 6a34747..0000000 Binary files a/doc/research2/img/tree.png and /dev/null differ diff --git a/doc/research2/src/intro.tex b/doc/research2/src/intro.tex index e5359e0..a2f3903 100644 --- a/doc/research2/src/intro.tex +++ b/doc/research2/src/intro.tex @@ -15,17 +15,44 @@ infrastructure of a particular corporation. These are the reasons of the \emph{s primary goal to act as a generic content-centric multiparty transport protocol that allows seamless, effortless data dissemination on the big cloud represented by the Internet. -// TODO - swift description paragraph +\subsection{Swift Description} -\textbf{Contribution}. // TODO +Most features of the \emph{swift} protocol are defined by its function as a content-centric multiparty transport +protocol. A significant difference between \emph{swift} and the TCP protocol is that TCP possesses no information +regarding what data it is dealing with, as the data is passed from the user-space, while the \emph{swift} protocol has +data fixed in advance and many peers participate in distributing the same data. Because of this and the fact that for +\emph{swift} the order of delivery is of little importance and unreliability is naturally compensated for by redundancy, +it entirely drops TCP's abstraction of sequential reliable data stream delivery. For example, out-of-order data could +still be saved and the same piece of data might always be received from another peer. + +Being implemented over UDP, the protocol does its best to make every datagram self-contained so each datagram could be +processed separately and a loss of one datagram must not disrupt the flow. Thus, a datagram carries zero or more +messages, and neither messages nor message interdependencies should span over multiple datagrams. + +The verification of data pieces is realize using Merkle hash trees\cite{merkle}, \cite{merkle-ext}. That means that all +hashes necessary for verifying data integrity needs to be put into the same datagram as the data. For both use cases, +streaming and downloading, an unified integrity checking scheme that works down to the level of a single datagram is +developed. As a general rule, the sender should append to the data some meta-data represented by the necessary hashes +for the data verification. While some optimistic optimizations are definitely possible, the receiver should drop data if +it is impossible to verify it. Before sending a packet of data to the receiver, the sender inspects the receiver's +previous acknowledgments to derive which hashes the receiver already has for sure. + +The data is acknowledged in terms of binary intervals, with the base interval of 1KB "packet". As a result, every +single packet is acknowledged logarithmic number of times. This mechanism provides some necessary redundancy of the +acknowledgements and sufficiently compensates the unreliability of the datagrams. + +The only function of TCP that is also critical for \emph{swift} is the congestion control. To facilitate delay-based +congestion control an acknowledgment contains besides the dimension of the file received from its addressee a timestamp. + + +\textbf{Contribution}. Our main objective is to integrate \emph{swift} as a transport protocol in the Linux kernel +networking stack. This will provide notable performance improvement regarding data transfer. We intend to do this with +minimal intrusion effect in the Linux kernel and also to change as little as possible the current \emph{swift} +implementation. Another goal is to provide a transparent API between the kernel and the user space. A developer will use +a socket-like interface when building an application on top of the \emph{swift} protocol. In order to achieve this goal +we have implemented an intermediary step. We have simulated the kernel part in the user-space using raw sockets. This +has the advantage of providing means to have modular functionality tests. -\begin{comment} -Our main objective is to integrate \emph{swift} as a transport protocol in the Linux kernel -networking stack. This will provide notable performance improvement regarding data transfer. We intend to do this with -minimal intrusion effect in the Linux kernel and also to change as little as possible the current \emph{swift} -implementation. Another goal is to provide a transparent API between the kernel and the user space. A developer will use -a socket-like interface when building an application on top of the \emph{swift} protocol. -\end{comment} \textbf{Outline}. The rest of the paper is organized as follows. In section \ref{sec:preliminarywork} we discuss some previous approaches in designing the system with their sthrengths and weaknesess. In section \ref{sec:arch} diff --git a/doc/research2/src/preliminarywork.tex b/doc/research2/src/preliminarywork.tex index 7d2285e..6e9c9f3 100644 --- a/doc/research2/src/preliminarywork.tex +++ b/doc/research2/src/preliminarywork.tex @@ -10,13 +10,10 @@ For the integrity check the swift protocol relies on Merkle hash tree. Keeping t not scalable. The Internet content is too large to be stored in kernel. Even if the tree retains only hashes of the data disseminated, the space is insufficient. +\image[scale=0.4]{img/arch1.pdf}{img:arch1}{Previous Architecture} - -The second approach of the swift implementation is represent in the \labelindexref{Figure}{img:tree}. - -\image[scale=0.45]{img/tree}{img:tree}{Tree} - -The swift transport should have been a new kernel interface allowing the creation of specialized swift sockets. It +The second approach of the swift implementation is represent in the \labelindexref{Figure}{img:arch1}. The swift transport + should have been a new kernel interface allowing the creation of specialized swift sockets. It should have implemented the multiparty protocol allowing piece transport to/from other hosts in a peer-to-peer fashion. That implementation should have had specialized "request queues", metadata queues, to/from user space. Specialized