From: Oana Baron Date: Mon, 6 Jun 2011 20:58:21 +0000 (+0300) Subject: Add research2 draft X-Git-Url: http://p2p-next.cs.pub.ro/gitweb/?a=commitdiff_plain;h=8e8f1b9dde005398387a93317dc17326f45ade89;p=swifty.git Add research2 draft --- diff --git a/doc/research2/API.txt b/doc/research2/API.txt new file mode 100644 index 0000000..d90851c --- /dev/null +++ b/doc/research2/API.txt @@ -0,0 +1,48 @@ +This is the swift structures: +// swift interface +typedef struct swift { + int socketListener, socketData; + struct sockaddr_in socketListenerAddr; +} *Swift; + +// swift_addr structure similar with in_addr +struct swift_addr { + unsigned short N; // e.g. number of s_addr + unsigned long s_addr[MAX_IPs]; // i.p. ip list +}; + +// swift struct similar with sock_addr +typedef struct sockSwiftaddr { + short sin_family; // e.g. AF_INET + unsigned short sin_port; // e.g. htons(3490) + struct swift_addr sin_addr; // see struct swift_addr, below +} *SockSwiftaddr; + +// list of swift_addr +struct listsockaddr { + unsigned short N; + struct sockaddr_in sa[MAX_IPs]; +}; + +With this new structures we modify the normal socket api and the new api is: + +// Function to create a Swift socket +Swift socketSwift(); + +// Function to close a Swift socket +void closeSwift(Swift); + +// Function to listen to a port +int listenfromSwift (Swift s, void *buf, size_t len, int flags, + struct sockSwiftaddr * __restrict__ from, socklen_t *fromlen); + +// Function to bind a port for swift socket +int bindSwift(Swift s, const struct sockSwiftaddr *my_addr, socklen_t addrlen); + +// Function to receive a message +ssize_t recvFromSwift(Swift s, void *buf, size_t len, int flags, + struct sockSwiftaddr *from, socklen_t *fromlen); + +// Function to send a message +ssize_t sendToSwift(Swift s, const void *buf, size_t len, int flags, + const struct sockSwiftaddr *to, socklen_t tolen); diff --git a/doc/research2/Makefile b/doc/research2/Makefile new file mode 100644 index 0000000..5c87740 --- /dev/null +++ b/doc/research2/Makefile @@ -0,0 +1,29 @@ +BASENAME = my-report +PDF = $(addsuffix .pdf, $(BASENAME)) +DVI = $(addsuffix .dvi, $(BASENAME)) +TEX = $(addsuffix .tex, $(BASENAME)) +BIB = $(addsuffix .bib, $(BASENAME)) +LATEX = latex +PDFLATEX = pdflatex +BIBTEX = bibtex + +.PHONY: all clean + +all: $(PDF) + +$(DVI): $(TEX) $(BIB) src/ + $(LATEX) $< + $(BIBTEX) $(BASENAME) + # Twice, so TOC is also updated + $(LATEX) $< + $(LATEX) $< + +$(PDF): $(TEX) $(BIB) src/ + $(PDFLATEX) $< + $(BIBTEX) $(BASENAME) + # Twice, so TOC is also updated + $(PDFLATEX) $< + $(PDFLATEX) $< + +clean: + -rm -f *~ *.aux *.log *.blg *.bbl *.out *.pdf src/*~ *.backup src/*.backup diff --git a/doc/research2/img/.gitignore b/doc/research2/img/.gitignore new file mode 100644 index 0000000..e69de29 diff --git a/doc/research2/img/AppFinal.pdf b/doc/research2/img/AppFinal.pdf new file mode 100644 index 0000000..eba161b Binary files /dev/null and b/doc/research2/img/AppFinal.pdf differ diff --git a/doc/research2/img/RD.pdf b/doc/research2/img/RD.pdf new file mode 100644 index 0000000..9152371 Binary files /dev/null and b/doc/research2/img/RD.pdf differ diff --git a/doc/research2/img/arch-overview2.dia b/doc/research2/img/arch-overview2.dia new file mode 100644 index 0000000..f4ba392 --- /dev/null +++ b/doc/research2/img/arch-overview2.dia @@ -0,0 +1,952 @@ + + + + + + + + + + + + + #Letter# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #Application (libswift)# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #wrapper library (swiftlib)# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #Multiparty protocol (Tranport Layer) (raw sockets) (state automaton)# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #peer discovery +overlay# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #sys_socket# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #sys_bind# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #sys_recvfrom# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #sys_sendto# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #socketSwift# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #listenfromSwift# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #recvfromSwift# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #sendToSwift# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #hash# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #peers# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #hash# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #peers# + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/doc/research2/img/header.dia b/doc/research2/img/header.dia new file mode 100644 index 0000000..68a6128 Binary files /dev/null and b/doc/research2/img/header.dia differ diff --git a/doc/research2/img/tree.png b/doc/research2/img/tree.png new file mode 100644 index 0000000..6a34747 Binary files /dev/null and b/doc/research2/img/tree.png differ diff --git a/doc/research2/img/untitled folder/AppFinal.png b/doc/research2/img/untitled folder/AppFinal.png new file mode 100644 index 0000000..7f40b45 Binary files /dev/null and b/doc/research2/img/untitled folder/AppFinal.png differ diff --git a/doc/research2/img/untitled folder/AppFinal_bak.png b/doc/research2/img/untitled folder/AppFinal_bak.png new file mode 100644 index 0000000..1042df3 Binary files /dev/null and b/doc/research2/img/untitled folder/AppFinal_bak.png differ diff --git a/doc/research2/img/untitled folder/App_Fin.svg b/doc/research2/img/untitled folder/App_Fin.svg new file mode 100644 index 0000000..9ac289b --- /dev/null +++ b/doc/research2/img/untitled folder/App_Fin.svg @@ -0,0 +1,405 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + Page-1 + + + + Rounded rectangle.3 + Kernel Space + + + + + + + Kernel Space + + Rounded rectangle + User Space + + + + + + + User Space + + Cloud + Internet + + + + + + + Internet + + Data store + Swift Socket (Data transfer) + + + + + + + + Swift Socket(Data transfer) + + Pointer (1-D) + + + + + + + Pointer (1-D).11 + + + + + + + Pointer (1-D).12 + + + + + + + Pointer (1-D).13 + + + + + + + Data store.14 + UDP Socket (Information update) + + + + + + + + UDP Socket(Information update) + + Pointer (1-D).19 + + + + + + + Pointer (1-D).20 + + + + + + + Pointer (1-D).21 + + + + + + + Pointer (1-D).22 + + + + + + + Pointer (1-D).27 + + + + + + + Pointer (1-D).28 + + + + + + + Pointer (1-D).29 + + + + + + + 12pt. text + … + + + + + + + + + + … + + 12pt. text.32 + … + + + + + + + + + + … + + Pointer (1-D).33 + + + + + + + 12pt. text.31 + … + + + + + + + + + + … + + Rounded rectangle.34 + Swift Library + + + + + + + Swift Library + + Rounded rectangle.23 + Application which uses SWIFT Library + + + + + + + Application which uses SWIFT Library + + Pointer (1-D).35 + + + + + + + Rounded rectangle.36 + Swift Transport Layer + + + + + + + Swift Transport Layer + + Rounded rectangle.37 + IP 1 + + + + + + + IP 1 + + Rounded rectangle.38 + Physical Layer 1 + + + + + + + Physical Layer 1 + + Rounded rectangle.39 + Data Link 1 + + + + + + + Data Link 1 + + Rounded rectangle.7 + Data Link N + + + + + + + Data Link N + + Rounded rectangle.8 + IP N + + + + + + + IP N + + Rounded rectangle.9 + Physical Layer 1 + + + + + + + Physical Layer 1 + + Rounded rectangle.5 + UDP Transport Layer + + + + + + + UDP Transport Layer + + Rounded rectangle.15 + Data Link + + + + + + + Data Link + + Rounded rectangle.24 + IP + + + + + + + IP + + Rounded rectangle.16 + Physical Layer + + + + + + + Physical Layer + + diff --git a/doc/research2/img/untitled folder/RD.png b/doc/research2/img/untitled folder/RD.png new file mode 100644 index 0000000..8b7a54c Binary files /dev/null and b/doc/research2/img/untitled folder/RD.png differ diff --git a/doc/research2/img/untitled folder/RD_.pdf b/doc/research2/img/untitled folder/RD_.pdf new file mode 100644 index 0000000..696d573 Binary files /dev/null and b/doc/research2/img/untitled folder/RD_.pdf differ diff --git a/doc/research2/img/untitled folder/RD_.svg b/doc/research2/img/untitled folder/RD_.svg new file mode 100644 index 0000000..2a076eb --- /dev/null +++ b/doc/research2/img/untitled folder/RD_.svg @@ -0,0 +1,212 @@ + + + + + + + + + + + + + + + + + + + + + + Page-1 + + + + Function / subroutine + Swift Application + + + + + + + Swift Application + + Function / subroutine.2 + Swift Library + + + + + + + Swift Library + + Invocation + + + + + + + + Invocation.4 + + + + + + + + Function / subroutine.5 + Kernel Space + + + + + + + Kernel Space + + Function / subroutine.6 + Kernel Space 1 + + + + + + + Kernel Space 1 + + Invocation.7 + + + + + + + + Invocation.8 + + + + + + + + Function / subroutine.9 + Kernel Space N + + + + + + + Kernel Space N + + Invocation.13 + + + + + + + + 12pt. text + Request + + + + + + + + + + Request + + 12pt. text.16 + SysCall + + + + + + + + + + SysCall + + 12pt. text.17 + ……….. + + + + + + + + + + ……….. + + Invocation.18 + + + + + + + + Invocation.19 + + + + + + + + 12pt. text.20 + Network communication + + + + + + + + + + Network communication + + Invocation.10 + + + + + + + + diff --git a/doc/research2/my-report.bib b/doc/research2/my-report.bib new file mode 100644 index 0000000..728f1ee --- /dev/null +++ b/doc/research2/my-report.bib @@ -0,0 +1,81 @@ +# sample entry +@inproceedings{large-scale-p2p-sim, + author = {Dinh, Tien Tuan Anh and Theodoropoulos, Georgios and Minson, Rob}, + title = {{Evaluating Large Scale Distributed Simulation of P2P Networks}}, + booktitle = {DS-RT '08: Proceedings of the 2008 12th IEEE/ACM International Symposium on Distributed Simulation and Real-Time Applications}, + year = {2008}, + isbn = {978-0-7695-3425-1}, + pages = {51--58}, + doi = {http://dx.doi.org/10.1109/DS-RT.2008.36}, + publisher = {IEEE Computer Society}, + address = {Washington, DC, USA}, +} + +@misc{binmaps, + author = {V. Grishchenko, J. Pouwelse}, + title = {{Binmaps: hybridizing bitmaps and binary trees}}, + year = {2009}, + howpublished = {http://bouillon.math.usu.ru/articles/binmaps-alenex.pdf}, +} + +@misc{merkle, + author = {R. Merkle}, + title = {{A Digital Signature Based on a Conventional Encryption Function}}, + booktitle = {Proceedings CRYPTO'87}, + year = {1987}, + pages = {369--378}, + address = {Santa Barbara, CA, USA}, +} + +@misc{bittorrent, + author = {Bram Cohen}, + title = {{Incentives Build Robustness in BitTorrent}}, + howpublished = {http://www.bittorrent.org/bittorrentecon.pdf}, +} + +@misc{merkle-ext, + author = {Arno Bakker}, + title = {{Merkle hash torrent extension}}, + booktitle = {BEP 30}, + howpublished = {http://bittorrent.org/beps/bep\_0030.html}, +} + +@misc{ledbat, + author = {S. Shalunov}, + title = {{Low Extra Delay Background Transport (LEDBAT)}}, + howpublished = {http://www.ietf.org/id/draft-ietf-ledbat-congestion-00.txt}, + year = {2009}, +} + +@misc{ledbat2, + author = {S. Shalunov, G. Hazel}, + title = {{Low Extra Delay Background Transport (LEDBAT)}}, + howpublished = {http://tools.ietf.org/html/draft-ietf-ledbat-congestion-03}, + year = {2010}, +} + + +@misc{peer-to-peer, + author = {B. Ford, P. Srisuresh, D. Kegel}, + title = {{Peer-to-Peer Communication Across Network Address Translators}}, + howpublished = {http://www.brynosaurus.com/pub/net/p2pnat/}, +} + +@misc{cdnwiki, + title = {{Wikipedia Content Delivery Network(CDN) page}}, + howpublished = {http://en.wikipedia.org/wiki/Content_delivery_network}, +} + +@misc{kernel, + author = {R. Love}, + title = {{Linux Kernel Development}}, + booktitle = {{Talking Directly to the Kernel and C Library}}, + year = {2004}, +} + +@misc{socket, + author = {R. Stevens}, + title = {{UNIX Network Programming, Volume 2, Second Edition}}, + booktitle = {{Interprocess Communications}}, + year = {1999}, +} \ No newline at end of file diff --git a/doc/research2/my-report.tex b/doc/research2/my-report.tex new file mode 100644 index 0000000..543d110 --- /dev/null +++ b/doc/research2/my-report.tex @@ -0,0 +1,107 @@ +% vim: set tw=78 sts=2 sw=2 ts=8 aw et ai: +\documentclass[12pt]{article} + +\usepackage[paper=a4paper, top=2cm, bottom=3cm, left=2.5cm, right=2.5cm]{geometry} + +\usepackage{ucs} +\usepackage[utf8x]{inputenc} +\usepackage[english]{babel} +\usepackage{hyperref} % use \url{http://$URL} or \href{http://$URL}{Name} +\usepackage{underscore} % underscores need not be escaped +\usepackage{subfigure} +\usepackage{verbatim} +\usepackage{float} +\usepackage{booktabs} + +% Support for including graphics +\usepackage{graphicx} +\DeclareGraphicsExtensions{.pdf,.png,.jpg} + +\usepackage{hyperref} + +\hypersetup{% + colorlinks=true, + linkcolor=blue, + anchorcolor=black, + citecolor=black, + urlcolor=blue, + bookmarks=true, + bookmarksnumbered=true +} +\urlstyle{same} + +\newcommand{\labelindexref}[2]{\hyperref[#2]{#1~\ref*{#2}}} +% command for inserting labeled figures +\newcommand{\image}[4][]{ +\begin{figure}[htb] +\begin{center} +\includegraphics[#1]{#2} +\caption{#4 \label{#3}} +\end{center} +\end{figure} +} + +\setlength{\parindent}{0pt} +\setlength{\parskip}{2ex} + + +\title{\bfseries{SWIFT in the Linux Kernel\\ +\large{\vspace*{0.4cm}Scientific supervisor: Nicolae Țăpuș\\ Technical supervisor: Răzvan Deaconescu}}} + +\author{Oana Baron, Bogdan Druțu\\ +Automatic Control and Computers Faculty\\ +University Politehnica of Bucharest\\ +Splaiul Independenței nr. 313, Bucharest, Romania \\ +\emph{\{oana.baron, bogdan.drutu\}@cti.pub.ro}} + +\date{\today} + +\begin{document} + +\maketitle + +%\begin{abstract} +%\input{src/abstract} +%\end{abstract} + +{\bf \hspace*{0.8cm} \textbf{\emph{Keywords}} -- bittorrent, multiparty, transport protocol, linux kernel,\\ +\hspace*{0.8cm} Merkle hash trees, binmaps} + +\section{Introduction} +\label{sec:introduction} +\input{src/intro} + +\section{Preliminary Work} +\label{sec:preliminarywork} +\input{src/preliminarywork} + +%\pagebreak + +\section{Architecture} +\label{sec:arch} +\input{src/arch} + +\section{Raw Sockets} +\label{sec:rawsock} +\input{src/rawsock} + +\section{Testing and Evaluation} +\label{sec:testing} +\input{src/testing} + + +\section{Conclusion and Further Work} +\label{sec:summary} +\input{src/summary} + +%\section*{Acknowledgment} +%\label{sec:acknowledgment} + +%The authors would like to thank XYZ for their support and dedication. + +\pagebreak + +\bibliographystyle{abbrv} +\bibliography{my-report} + +\end{document} diff --git a/doc/research2/src/arch.tex b/doc/research2/src/arch.tex new file mode 100644 index 0000000..e69de29 diff --git a/doc/research2/src/intro.tex b/doc/research2/src/intro.tex new file mode 100644 index 0000000..e5359e0 --- /dev/null +++ b/doc/research2/src/intro.tex @@ -0,0 +1,35 @@ +%\section{\fontfamily{phv}\selectfont{\large{\bfseries{INTRODUCTION}}}} + +The \emph{swift} protocol is a generic multiparty transport protocol. Its mission is to disseminate content among a +swarm of peers. Basically, it answers one and only one request: \emph{'Here is a hash! Give me data for it!'}. Such +entities as storage, servers and connections are abstracted and are virtually invisible at the API layer. Given a hash, +the data is received from whatever source available and data integrity is checked cryptographically with Merkle hash +trees. + +If you need some data it is somewhat faster and/or cheaper downloading it from a nearby well-provisioned replica, but +on the other hand, this process requires that multiple parties (e.g. consumers, the data sources, CDN +sites\cite{cdnwiki} , mirrors, peers) have to be coordinate. As the Internet content is in a continuous increasing +nowadays, the overhead of peer/replica coordination becomes higher then the mass of the download itself. Thus, the niche +for multiparty transfers expands. Still, current, relevant technologies are tightly coupled to a single use case or even +infrastructure of a particular corporation. These are the reasons of the \emph{swift} protocol appearance with its +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 + +\textbf{Contribution}. // TODO + +\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} + presents our current approach to integrate the \emph{swift} protocol as a transport layer protocol into the Linux +kernel. Section \ref{sec:rawsock} presents a preliminary implementation using raw socktes that prepares the ground for +the final stage of the project. We describe our testing scenariou in detail in section \ref{sec:testing}. Section +\ref{sec:summary} concludes the article and refers to future work. diff --git a/doc/research2/src/preliminarywork.tex b/doc/research2/src/preliminarywork.tex new file mode 100644 index 0000000..7d2285e --- /dev/null +++ b/doc/research2/src/preliminarywork.tex @@ -0,0 +1,43 @@ +While designing our system, we have tackled a few different ideas, each with its strengths and weaknesees. We present +now some of those preliminary ideas that lead to the our current desing choice. + +The first approach we thought of was to include all of the swift protocol into the kernel space. This +approach had the advantage of simplicity and would have implied minimal architectural changes. The current user space +implementation could have been ported to a kernel module. + +Though simple, this approach could not be implemented because of the restriction of memory size in the kernel. +For the integrity check the swift protocol relies on Merkle hash tree. Keeping this tree in the kernel space memory is +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. + + + +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 +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 +system call API should have allowed user space applications to interact with the above +mentioned queues and, thus, with the multiparty transport protocol implementation. + +Innate differences from a classical one-to-one communication such as UDP or TCP means the system call API shouldn't have +followed the classical send/receive paradigm. In order to compensate this and to provide a rather "friendly" interface +to user space applications, a library was designed that to provide a simpler interface. Peer and piece discovery should +have been the responsibility of the user space application. The SWIFT Library may also provide wrappers over a UDP-based +channel for discovery. + +Merkle hashes should have stored and computed in user space. This approach couldn't be implemented because of the +restriction of the library implementations (e.g. a users application design would be more restrictive). Moreover the +kernel implementation should have been like an UDP which support multicast transfer. + + +The third approach of the swift implementation was to detach the transport layer from the original swift implementation +and to manage it. When we started to implement this we found a lot of inconvenience like our code duplicate a lot of +application code, we cannot implement the discovery protocol, and again our kernel implementation should have been like +a multicast-UDP. + +This approach also couldn't be implemented because of the complexity of the transport layer management, moreover we +didn't find strengths to confirm that our implementation could be better than original implementation. \ No newline at end of file diff --git a/doc/research2/src/rawsock.tex b/doc/research2/src/rawsock.tex new file mode 100644 index 0000000..e69de29 diff --git a/doc/research2/src/summary.tex b/doc/research2/src/summary.tex new file mode 100644 index 0000000..e8950dd --- /dev/null +++ b/doc/research2/src/summary.tex @@ -0,0 +1,21 @@ +%\section{\fontfamily{phv}\selectfont{\large{\bfseries{SUMMARY}}}} + +The \emph{swift} protocol is a multiparty content-centric protocol that aims to disseminate content among a swarm of +peers. This paper proposes an approach for the optimization of the currently \emph{swift} protocol. The integration of +the communication in the kernel space as a multiparty transport protocol that is solely responsible for getting the +bits moving improves the over all protocol performance. It ensures maximum efficiency of data transfer by decreasing +switches between user and kernel space and eliminating some performance penalties due to context switches. + +\subsection*{Directions for Future Work} + + +After we complete the implementation and the functional tests, we want to test extensively our new features in a real +environment. We plan to do stress tests using a cluster. This tests will help us to make an overview about our +implementation and we could compare with the user-space implementation of the \emph{swift} to determine exactly what +performance we encountered. If the results are satisfactory, we will continue to optimize our program and we will add +new features. + +It will be very useful to have a real application on top of the \emph{swift} protocol. If not, one solution would be to +port an application strictly for this task. This would give us the opportunity to extend and refine our implementation, +and also to extend the library API. + diff --git a/doc/research2/src/testing.tex b/doc/research2/src/testing.tex new file mode 100644 index 0000000..e69de29