url = {http://dblp.uni-trier.de/db/conf/p2p/p2p2006.html#GarbackiIES06},
year = 2006
}
+
+@inproceedings{swift,
+ author = {Osmani, Flutra and Grishchenko, Victor and Jimenez, Raul and
+ Knutsson, Bj\"{o}rn},
+ title = {Swift: the missing link between peer-to-peer and
+ information-centric networks},
+ booktitle = {Proceedings of the First Workshop on P2P and
+ Dependability},
+ series = {P2P-Dep '12},
+ year = {2012},
+ isbn = {978-1-4503-1148-9},
+ location = {Sibiu, Romania},
+ pages = {4:1--4:6},
+ articleno = {4},
+ numpages = {6},
+ url = {http://doi.acm.org/10.1145/2212346.2212350},
+ doi = {10.1145/2212346.2212350},
+ acmid = {2212350},
+ publisher = {ACM},
+ address = {New York, NY, USA},
+ keywords = {distributed systems, networking, transport
+ protocol},
+}
+
+@inproceedings{multiparty,
+ author = {Chandra, Ashok K. and Furst, Merrick L. and Lipton, Richard
+ J.},
+ title = {Multi-party protocols},
+ booktitle = {Proceedings of the fifteenth annual ACM symposium on
+ Theory of computing},
+ series = {STOC '83},
+ year = {1983},
+ isbn = {0-89791-099-0},
+ pages = {94--99},
+ numpages = {6},
+ url = {http://doi.acm.org/10.1145/800061.808737},
+ doi = {10.1145/800061.808737},
+ acmid = {808737},
+ publisher = {ACM},
+ address = {New York, NY, USA},
+}
\documentclass{article}[12pt]
\usepackage{listings}
\usepackage[utf8]{inputenc}
+\usepackage{graphicx}
% paper info
\begin{abstract}
-This is the abstract of the paper.
+Peer-to-peer file sharing applications generate the largest amount of traffic
+in the Internet nowadays. Over the past few years there was a lot of research
+effort invested in this direction, analyzing and improving peer-to-peer
+applications such as BitTorrent, Kazaa or Shareaza but also developing new
+multiparty\cite{multiparty} protocols.
+
+This paper proposes a design for the SWIFT\cite{swift} generic multiparty
+transport protocol. Although it is an application layer protocol, our
+implementation resides at the kernel level. We believe that this approach
+would reduce the Operating System latency and would offer better performance
+than an userspace implementation such as a library. This paper also presents
+a performance comparison between our approach and the best currently existing
+solution, based on the \texttt{sendfile} system call.
\end{abstract}
\section{Design}
\label{sec:design}
-Nowadays all the peer to peer protocols run in user space. One of the
-most important delay appear when file transfers occurs. For every open,
-read or write operation which is made on a file or a socket, a
-system call is made. This generate a context switch, which waste a
-lot of time, mainly because of the translation lookaside
-buffer(TLB) flush.
-
-In our design we try to remove this waste time, by doing all the
-operation which generate a system call in kernel space. This mean,
-from the sender perspective opening the file, reading from the
-file and writing data into the socket and from the receiver
-perspective, opening the file, reading data from socket and
-writing data into the file in kernel space. The approach eliminate
-almost all the system calls. The only informations which must be
-sent from user space into kernel space, are in the sender case,
-the name of the file which must be transferred and the address of
-the receiver or receivers. In the case of the receiver a system
-call can be used to get informations about the transfer, like the
-files which are transferred and the status of the operations.
-
-In our implementation we use datagram to send and receive information. The UDP protocol is simple and the overhead is very small, but the protocol is not connection oriented which can lead to loss of informations. In the next subsections I will give more information about the our sender and receiver kernel modules design.
+Nowadays the vast majority of the peer-to-peer applications run in user space.
+And this is one of the most important delays that appear at the Operating
+System layer, while file transfers occurs. For every file operation such as
+\texttt{open}, \texttt{read}, \texttt{write}, etc, as well as socket
+operations, a system call is made. This induces a huge overhead caused by the
+system calls interrupts and context switches.
+
+In our design we have tried to eliminate as much system calls overhead as
+possible, by doing as many operations as possible directly in the kernel
+space. Having this in mind, we have outlined the module's architecture as
+illustrated in Figure \ref{fig:arch} and described in Section
+\ref{subsec:arch}.
+
+Our model also changes the perspective of a user space programmer. Until now,
+in order to simulate our module's behavior, the sender would have to open the
+file it has to send, read data from it and then write the data through the
+socket. Similar, a receiver has to open the file for writing, read data from
+the network socket and write it down into the file. All these operations have
+to be done repetitively in order to ensure that the file was properly
+sent/received. And therefore a huge overhead could be avoided if all these
+operations would be implemented directly in kernel, and would be substituted
+with a single system call.
+
+Our approach eliminates almost all the \texttt{open}, \texttt{read},
+\texttt{write} system calls, replacing them with a single
+\texttt{write}/\texttt{read} operation. The only information that has to be sent
+from user space into kernel space is, for the sender, the full path of the file
+that must be transferred and the IP address of the receiver, or receivers in
+case there are more than one. In the receivers' case, the system call can be
+used to get information about the transfer, like the files that are transferred
+or the status of the operation.
+
+\begin{figure}[h!]
+ \centering
+ \includegraphics[scale=0.5]{img/architecture.png}
+ \label{fig:arch}
+ \caption{P2PKP Module Architecture}
+\end{figure}
+
+Our implementation uses datagrams to send and receive information over
+the network. Although the UDP protocol is simple and the generated overhead is
+quite small, the protocol is not connection oriented which can lead to loss of
+packages/data. However, this matter is beyond our interests in this research,
+as we are now focusing on developing an efficient solution in terms of
+latency, without considering network issues.
+
+\subsection{P2PKP Architecture}
+\label{subsec:arch}
+
+The architecture of our protocol implementation resides completely in kernel
+space, in shape of a kernel module. As Figure \ref{fig:arch} illustrates, the
+communication between user space and our module is done completely through the
+\texttt{read}, \texttt{write}, \texttt{connect} system calls. However, our
+module is not a standalone entity, but it interacts with the Linux VFS
+(Virtual File System) and NET layer in order to read/write files in kernel
+space and deliver/receive them through the network. Section
+\ref{sec:implementation} describes the interactions between all these components
+and how they are linked together in order to provide the desired behavior.
\subsection{P2PKP Sender}
\label{subsec:sender}
-The sender module use a socket, to communicate from user space to kernel space, The system calls used are connect and write. When a user want to transfer a file to one or more peers the name of the file, and the ip address of the receivers must be provided. The connect system call is used to specify a destination, for a file. Multiple destinations can be specified by using multiple connect operations. After all the destinations are sent from user space to kernel space, a write operation must be used, to send the name of the file, which must be transferred to the peers. The name of the file, represent the absolute path of the file which will be transferred to the peers. After this operations are sent from user space to kernel space, all the transfer will occur in kernel space, so no additional system calls will be made.
+The sender module uses the UNIX socket interface in order to communicate from
+user space to kernel space. The system calls used for a receiver scenario are
+\texttt{connect} and \texttt{write}. When an user wants to transfer a file to
+one or more peers, the module needs only the local filename and the set of
+peers address. The \texttt{connect} system call is used to specify
+destinations of a single file. Multiple destinations can be specified by using
+multiple \texttt{connect} operations. After all the destinations are specified
+from user space to kernel space, a \texttt{write} operation must be used, in
+order to send the file over the network to all specified peers. The name of the
+file, represents the absolute path of the file which will be transferred to the
+peers. After this operations are sent from user space to kernel space, the
+whole file transfer will occur in kernel space, hence no additional system calls
+must be made.
-For each connect system call the kernel module create a new socket for the communication with the specified peer. After the write system call the kernel module, try to open the file. If the operation succeed, the module start reading data from the file, and writing into all the sockets created after connect operations. After all the content of the file is read and write to each socket, the file and the sockets are closed.
+For each \texttt{connect} system call, the kernel module creates a new socket
+for each socket specified for communication. After the \texttt{write} system
+call, the kernel module tries to open the file. If the operation succeeds, the
+module start reading data from the file, and writing into to the sockets created
+after the \texttt{connect} operations. After the whole content of the file is
+transferred each socket, the file descriptor and the sockets are closed.
-Every socket created in the user space is designed to transfer one or more files to multiple destinations. The total number of system calls used to transfer multiple files to multiple recipients is equal with the number of files plus the number of recipients.
+Every socket created in the user space is designed to transfer one or more files
+to one or multiple destinations. The total number of system calls used to
+transfer the files to each peer is equal to the number of files transferred plus
+the total number of recipients.
\subsection{P2PKP Received}
\label{subsec:receiver}
-The receiver module is implemented with a kernel module. The communication with user space is realised using a socket. Bind system call is used to set the port on which the module will listen for incoming data. The read operation is used to specify the file in which the incoming informations are stored. The file is specified using a global path name. At this moment we store all the data in the same file. We only try to view if the transfer time is good enough.
+The receiver part of the module is also implemented in kernel module. The
+communication between the user space and the module is realised using the
+kernel socket interface. The \texttt{bind} system call is used to set the
+interface and the port that the module will listen on for incoming requests.
+The \texttt{read} operation is used in order to specify the file where the
+incoming data is stored. The file has to be specified using the global path,
+rather than relative name. Currently, our implementation stores the whole data
+in a single file. We haven't advanced in more complex scenarios, as our
+initial goal was only to see if this design is good enough to fight with other
+implementations, like \texttt{sendfile}.
-After the bind operation, the module start listening and when informations are received, they are stored in the file specified with read system call. At this time the total number of system calls used to receive files is only two.
+After the \texttt{bind} operation, the module starts listening for data. As
+pointed in the previous paragraph, the whole data is transferred in a single
+file specified by the \texttt{read} system call. Therefore, summing up all the
+system calls needed to receive a single file over the network reduces to two.
\section{Introduction}
\label{sec:intro}
-Paper introduction.
+
+Peer-to-peer protocols currently form the most heavily used protocol class in
+the Internet, along with BitTorrent, the most popular protocol for content
+distribution. A high number of studies and investigations have been undertaken
+to measure, analyse and improve the inner workings of the BitTorrent protocol.
+However, enhancing the protocols used at the network layer is not the only
+approach to improving file sharing techniques, but also optimizing the client
+implementations (P2P applications). As usually these applications are not CPU
+but rather I/O bound, new research opportunities have appeared in the
+Operating Systems field.
+
+This paper aims to improve peer-to-peer technologies by providing a reliable
+and performing implementation of the SWIFT\cite{swift} multiparty protocol at
+the kernel level. Basically we developed a new UNIX kernel module that
+provides the implementation of a completely new protocol, capable of
+transferring multiple files between multiple peers using a single system call.
+We are very confident that this approach must improve the performance of P2P
+file sharing application by reducing the overhead of the kernel context
+switches caused by multiple system calls.
+
+Currently, the most efficient implementation of an file content distribution
+application in an UNIX environment is using the \texttt{sendfile} system call.
+This implementation uses a zero-copy mechanism that transfers the content of a
+file from the hard disk to the network interface without passing any data to
+userspace. Considering these qualifications, we have compared our module's
+benchmarks with \texttt{sendfile}'s in order to classify the enhancements
+brought by this implementation.
+
+The content of this paper is organized as it follows: in the next section we
+will present some related work on the multiparty topics. In Section
+\ref{sec:design} we describe how the kernel module was designed to be
+used in userspace, followed by the actual implementation in Section
+\ref{sec:implementation}. In the next two sections we will present
+some performance tests we have conducted along with the results achieved.
+Finally, in Section \ref{sec:conclusions} we will draw some conclusions
+followed by the some further work that has to be done.
\section{Related Work}
\label{sec:related}
-Measurements and improvements in Peer-to-Peer systems have been the focus of commercial and scientific players alike. Thorough analysis, a diversity of approaches, different interests have sparked a plethora of novel mechanisms, architectures, updates and extensions to existing applications as well as new and improved implementations to both old and new problems. Recent years have shown particular interest in the streaming capabilities of Peer-to-Peer solutions, resulting in a surge of updates, extensions and trials. Novel protocols such as swift are proof to the continuous birth of new protocols in the ever evolving Internet.
+Measurements and improvements in Peer-to-Peer systems have been the focus of
+commercial and scientific players alike. Thorough analysis, a diversity of
+approaches, different interests have sparked a plethora of novel mechanisms,
+architectures, updates and extensions to existing applications as well as new
+and improved implementations to both old and new problems. Recent years have
+shown particular interest in the streaming capabilities of Peer-to-Peer
+solutions, resulting in a surge of updates, extensions and trials. Novel
+protocols such as swift are proof to the continuous birth of new protocols in
+the ever evolving Internet.
-Most measurements and evaluations involving the BitTorrent protocol and applications are either concerned with the behavior of a real-world swarm or with the internal design of the protocol. There has been little focus on creating a self-sustained swarm management environment capable of deploying hundreds of controlled peers, and subsequently gathering results and interpreting them.
+Most measurements and evaluations involving the BitTorrent protocol and
+applications are either concerned with the behavior of a real-world swarm or
+with the internal design of the protocol. There has been little focus on
+creating a self-sustained swarm management environment capable of deploying
+hundreds of controlled peers, and subsequently gathering results and
+interpreting them.
-The PlanetLab infrastructure provides a realistic testbed for Peer-to-Peer experiments. PlanetLab nodes are connected to the Internet and experiments have a more realistic testbed where delays, bandwidth and other are subject to change. Tools are also available to aid in conducting experiments and data collection \cite{planetLab}.
+The PlanetLab infrastructure provides a realistic testbed for Peer-to-Peer
+experiments. PlanetLab nodes are connected to the Internet and experiments have
+a more realistic testbed where delays, bandwidth and other are subject to
+change. Tools are also available to aid in conducting experiments and data
+collection \cite{planetLab}.
-Pouwelse et al. \cite{pouwelse} have done extensive analysis on the BitTorrent protocol using large real-world swarms focusing on the overall performance and user satisfaction. Guo et al. \cite{guo} have modeled the BitTorrent protocol and provided a formal approach to its functionality. Bharambe et al. \cite{bharambe} have done extensive studies on improving BitTorrent’s network performance.
+Pouwelse et al. \cite{pouwelse} have done extensive analysis on the BitTorrent
+protocol using large real-world swarms focusing on the overall performance and
+user satisfaction. Guo et al. \cite{guo} have modeled the BitTorrent protocol
+and provided a formal approach to its functionality. Bharambe et al.
+\cite{bharambe} have done extensive studies on improving BitTorrent’s network
+performance.
-Garbacki et al. \cite{garbacki} have created a simulator for testing 2Fast, a collaborative download protocol. The simulator is useful only for small swarms that require control. Real-world experiments involved using real systems communicating with real BitTorrent clients in the swarm.
+Garbacki et al. \cite{garbacki} have created a simulator for testing 2Fast, a
+collaborative download protocol. The simulator is useful only for small swarms
+that require control. Real-world experiments involved using real systems
+communicating with real BitTorrent clients in the swarm.
#ifndef P2PKP_DEBUG
/* uncomment to turn debugging off */
- #define P2PKP_DEBUG yes
+ //#define P2PKP_DEBUG yes
#endif
#ifdef P2PKP_DEBUG
printk(KERN_DEBUG "[%s:%d] " format "\n", __func__, __LINE__, ## args); \
} while (0)
#else
-#define LOG(s) \
+#define DEBUG(format, args...) \
do {} while (0)
#endif
-5000 sleep
-send (B/MB) receive (B/MB) time (s)
-------------------------------------------------------------
-1048576/1 1048576/1 1
-33554432/32 25030616/24 24
-67108864/64 49692348/48 44
-134217728/128 89076884/85 89
-268435456/256 125071216/120 164
-
-
-send (B/MB) receive (B/KB) time (s)
-------------------------------------------------------------
-1048576/1 139332/137 1
-33554432/32 344232/337 6
-67108864/64 368820/361 8
-134217728/128 434388/425 19
-268435456/256 1901472/1946 53
+send (B/MB) receive (B/KB) t(s) 2p 3p 6p
+-----------------------------------------------------------------------
+33554432/32 344232/337 4 10 18 49
+67108864/64 368820/361 10 20 35 80
+134217728/128 434388/425 20 42 58 226
+268435456/256 1901472/1946 41 75 129 385
MODULE_DIR=../module
CLIENT=client/client
SERVER=server/server
-FILE=/tmp/testfile1
+FILE=/tmp/testfile32
+OUTPUT_DIR=/tmp
IP="127.0.0.1"
-WAIT_TIME=5
+WAIT_TIME=3
LISTENERS_PORTS=(
- 60000
+ 50000
+ 50001
+ 50002
+ 50003
+ 50004
+ 50005
)
-
#use nc.traditional
echo 2 | update-alternatives --config nc &> /dev/null
-[ -e $FILE ] || exit
+[ -d $OUTPUT_DIR ] || mkdir -p $OUTPUT_DIR
#increase tests debugging
-set -x
+#set -x
-# listen for UDP packets on localhost, port 60000 (run in background)
+# listen for UDP packets on localhost, port 50000 (run in background)
for port in "${LISTENERS_PORTS[@]}"; do
- $SERVER $IP $port testfile.$port &
+ $SERVER $IP $port $OUTPUT_DIR/testfile.$port &
pids="$pids $!"
ARGUMENTS="$IP $port $ARGUMENTS"
done
# wait for netcat to start listening
-sleep 1
+sleep $WAIT_TIME
-$CLIENT $FILE $ARGUMENTS
+if [ $# -eq 0 ]; then
+ [ -e $FILE ] || exit
+ $CLIENT $FILE $ARGUMENTS
+else
+ for file in $@; do
+ [ -e $file ] || continue
+ $CLIENT $file $ARGUMENTS
+ done
+fi
sleep $WAIT_TIME
# kill netcat
-send (B/MB) receive (B/MB) time (s)
-------------------------------------------------------------
-1048576/1 210944/0.2 1
-33554432/32 8388608/8 17
-67108864/64 18874368/18 37
-134217728/128 40894464/39 90
-268435456/256 57671680/55 133
+send (B/MB) receive (B/MB) t(s) 2p 3p 6p
+-----------------------------------------------------------------------
+33554432/32 8388608/8 24 29 35
+67108864/64 18874368/18 49 53 67
+134217728/128 40894464/39 101 118 142 308
+268435456/256 57671680/55 193 223 277
MODULE_DIR=../module
CLIENT=client/client
SERVER=server/server
-FILE=/root/Dropbox/school/p2pkp/test/client/test_file
+FILE=/tmp/testfile32
+OUTPUT_DIR=/tmp
IP="127.0.0.1"
-WAIT_TIME=2
+WAIT_TIME=3
LISTENERS_PORTS=(
60000
+ 60001
+ 60002
+ 60003
+ 60004
+ 60005
)
#use nc.traditional
echo 2 | update-alternatives --config nc &> /dev/null
-[ -e $FILE ] || exit
+[ -d $OUTPUT_DIR ] || mkdir -p $OUTPUT_DIR
#increase tests debugging
-set -x
+#set -x
# insert module, causing the message to be sent
insmod $MODULE_DIR/$MODULE_NAME.ko
# listen for UDP packets on localhost, port 60000 (run in background)
for port in "${LISTENERS_PORTS[@]}"; do
- $SERVER $IP $port testfile.$port &
+ $SERVER $IP $port $OUTPUT_DIR/testfile.$port &
pids="$pids $!"
ARGUMENTS="$IP $port $ARGUMENTS"
done
# wait for netcat to start listening
-sleep 1
+sleep $WAIT_TIME
+
+
+if [ $# -eq 0 ]; then
+ [ -e $FILE ] || exit
+ $CLIENT $FILE $ARGUMENTS
+else
+ for file in $@; do
+ [ -e $file ] || continue
+ $CLIENT $file $ARGUMENTS
+ done
+fi
-$CLIENT $FILE $ARGUMENTS
sleep $WAIT_TIME
# kill netcat
projects / p2p-kernel-protocol.git / commitdiff
