research2: architecture - send/recv datagram

diff --git a/doc/research2/src/arch.tex b/doc/research2/src/arch.tex
index 1066eb4..320500e 100644 (file)
--- a/doc/research2/src/arch.tex
+++ b/doc/research2/src/arch.tex
@@ -39,4 +39,18 @@ over only one socket.
 
 \image[scale=0.55]{img/recvdata.png}{img:recvdata}{Leecher}
 
+\labelindexref{Figure}{img:recvdata} presents the conceptual model of the Leecher. The Leecher is the one that wants
+to receive a data. In order to do this it must connect to the multiparty protocol by creating and binding to a
+multiparty socket. When it binds to a socket, it uses the hash as a parameter to find a connection with a peer that
+has the respective file. This discovery is done the peer discovery overlay. The Leecher then waits for packets
+from the seeders.
+ 
+
 \image[scale=0.55]{img/sendmsg.png}{img:sendmsg}{Seeder}
+
+
+\labelindexref{Figure}{img:sendmsg} presents the conceptual model of the Seeder. The Seeder is the one that serves
+data to other Leechers. In order to do this it must connect to the multiparty protocol by creating, binding and
+listening to a mutliparty socket. When binding the Seeder practically uses the hash as a parameter. This means that
+for every file hashed there will be a socket on which the seeder can receive and serve requests. The Seeder then waits
+for requests and sends data packets as requested.

diff --git a/doc/research2/src/testing.tex b/doc/research2/src/testing.tex
index e69de29..46e9872 100644 (file)
--- a/doc/research2/src/testing.tex
+++ b/doc/research2/src/testing.tex
@@ -0,0 +1,20 @@
+The  protocol is a generic multiparty transport protocol. Its mission is to disseminate content among a swarm of peers. 
+Given a hash, the data is received from whatever source available and data integrity is checked cryptographically with
+Merkle hash trees. 
+
+Our main focus when modifying the swift implementation is to have an impact on time performance. With a communication
+protocol the greatest latency is usually generated by waiting for the results from the network. The multiparty
+communication model already takes care of this, so the next best thing is to enhance the application time. We are doing
+this by decreasing the time penalties due to context switches between user space and kernel space. The main idea is to
+reduce the number of system calls made from user space into the kernel. This implicitly reduces the number of preemption
+moments.
+
+Firstly, we have implemented a test suite for every socket system call, which test all possible cases.  This unit tests
+are made to ensure the code quality, and to validate if the system call respond in the same mode as other similar
+system call. 
+
+Secondly, we have implemented a functional tests to validate a simple workflow. For this purpose we have a sender that
+acts as the seeder and a receiver which have the leecher role. We transfer a small file between this entities.  
+
+Also we will implement performance tests that will validate our design and implementation. This tests will compare the
+number of system calls for both implementation (original implementation and our implementation).