From 636aa5d4b66eade60cfff989451a77c638e72ac1 Mon Sep 17 00:00:00 2001 From: Oana Baron Date: Wed, 8 Jun 2011 23:40:16 +0300 Subject: [PATCH] research2: architecture - send/recv datagram --- doc/research2/src/arch.tex | 14 ++++++++++++++ doc/research2/src/testing.tex | 20 ++++++++++++++++++++ 2 files changed, 34 insertions(+) diff --git a/doc/research2/src/arch.tex b/doc/research2/src/arch.tex index 1066eb4..320500e 100644 --- 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 --- 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). -- 2.20.1