Basically this project intends to simulate a wired environment and on top of it analysis it with P2P file sharing. In order to do analysis on the wired environment a huge number of nodes is needed. Overall this project is to research in how efficient P2P file sharing is over wired. One of the key feature of this project is to research on the behaviour of wired nodes and their drawbacks.
The file sharing protocol that are going to be tested and implemented on wired will be mainly P2P file sharing protocol like BitTorrent since it is widely use by the online community. Analysis will be made to see if BitTorrent run as well in certain condition such as more nodes appear in to network compare to less nodes appear in the network and etc. Parameters of the node will be tweak in order to get some comparison such as the number of the node, the rate package lost and etc. With the comparison result gained, the problem might be pin-pointed and something can be done to improve on that part.
INTRODUCTION
Problem Statements
In nowadays world, the world is all connected by a network call the internet.
With the internet files can be shared and send all around the world. Now that we can
even connect wireless instead of on a wired network. People are expecting a more sophicated file transfer protocol compare to the conventional protocol. This when the term peer to peer file transfer protocol is introduced.
Of the many peer to peer file sharing protocol existence, the Bittorent is one of the most famous and managed to attract millions of users. In a P2P network, one node is connected to the others. This indirectly says that the connectivity of the nodes play an important role in file transferring. Since P2P is based in peers and there will be disconnecting and reconnecting of peers and this will effect the file transfer.
Another thing will be the speed of file transfer rate and lagness of the file sharing. Each peers is responsible of maximizing its own download rate by suitable peers, and peers with high upload rates will with high probability also be able to download wit high speeds.
Project Scope
This project will focus on computational jobs. A simulation of a peer to peer environment and the analysis of file sharing over this environment will be measured. In order to simulate many nodes of network, the OMnet++ network simulator program is used. Using Omnet++ will enable simulations of nodes starting from 1 up to 100 nodes of which is difficult to gather that amount of computer in real life to run this project. Few scenarios will be ran and compared in term of rate packet lost, time need to transfer certain files and etc.
Objectives
There are several objectives for doing this project and are as listed below :
To make comparision between small quantity of nodes and large quantity of nodes
To get the average rate of packet lost while transferring using peer to peer protocol
Calculate the time needed for the entire file sharing session
System Requirement
1.4.1 Software Requirement
Below are the software applications and environment will be used in this project:
Programming Language: C++
Compiler: GCC (GNU Compiler Collection) version 4.5.0
P2P network simulator: Oversim (OMNeT++ based network simulator)
Operating System: Windows OS (Windows 7 64-bit)
Hardware Requirement
Below are the hardware devices will be used in this project:
Processor: Intel(R) Core(TM)2 Duo CPU 2.2 GHz
RAM: 4.00 GB
Required Hard Disk Space: Minimum 10 GB
BACKGROUND AND LITERATURE REVIEW
Background
P2P(node to node) is a type of distribute network in which the nodes are directly connected to each other. There are no centralized servers in a P2P network. Nodes can play both the client and server roles. P2P environment are popular for file sharing network. Comparing with client-server based environment, transfer speed is faster in a P2P environment. The nodes can act as both client and server, they can directly exchange information among the neightbouring nodes. For example, in a client-server base environment, when a node A requests information from node B, node A will send the request to a server and wait for the server to contact node B and wait for the reply. This action consume times as compare to direct contact in a P2P network. Unlike client-server based architecture, all nodes in P2P environment can stay independently. When a node is down in a P2P network, other nodes still get connected and the exchanging resources can still keep on going once the node stay in the network. Yet unlimited P2P traffic can generate a great amount of traffic. This makes the network hard to be administrated. The traffic load always overloaded than the load for which the network was designed. Large amount of traffic will affect the bandwidth of a network which might affect others web activities and the users of the particular network.
Literature Review
File transfer is a act of transmitting files over a computer network or the internet. There are a few ways and protocols to transfer files over networks. Computers which provide a file transfer service are called file servers. File transfer can take place over a variety of levels such as transparent file transfers over network file systems, explicit file transfers from dedicated file transfer service like FTP, distributed file transfer over peer-to-peer networks like Bittorrent and etc.
According to Cohen ( 2003), BitTorrent operates the sharing of file by enabling the file available using HTTP and is uploaded to a hosting machine. When multiple users are downloading at the same time, the file is actually downloaded from pieces that are transferring and distributing to each user. In order to run a BitTorrent deployment, a static file with the extension .torrent is inserted on an ordinary web server. This file contains data and information such as the file, length, name, hashing information and the URL of the trackers. The tracker plays vitally important role because it is solely responsible to find more download sources for that certain file. It works by a simple protocol that is layered on top of HTTP in which a downloader sends information about what file it is downloading and it will link and connect with other applicants who are also downloading the same file. This will greatly boost the downloading speed as the more users with the file readily available, the faster the downloading process can be completed and finished. The user who downloads which have the completed downloading the file will be labelled as a seed where in the future if there is any request for the file, this downloader will act as the uploading station as well. There is a logistical obstacle of file downloading as interactions between peer needed to be handled. The tracker is responsible to collect information about the rate of downloads and uploads. The tracker primary responsibilities and obligations are just tied down to help peers to find each other. In accordance for the tracker to know which peer has which pieces of the file, the BitTorrent cuts files into pieces of fixed size. Every node will report in to all peer connecting to it on what pieces of files it has. However there is a down side of this file transferring protocol which is downloading can only be happened to peers that are connected which means the file is available if only there is a peer seeding it. The BitTorrent protocol also has an algorithm to select pieces to download which is in an orderly fashion so as to enhance the performance of downloading. When looking for pieces to be downloaded next, peers basically download pieces which the fewest of their own peers have at first. This is to ensure that peers have pieces which all of their peers want so the uploading process can be done when it is demanded. Information theory clarifies that no download can complete the downloading process until every part of the files have been uploaded by the seed. In BitTorrent there is this phenomenon known as the Endgame Mode where in some circumstances a piece will be requested from a peer with very slow transfer rates. This might not look like a problem for downloading in BitTorrent but could be laggish upon download completion. To encounter this problem, once all sub-pieces which a peer doesn't have are actively being requested, it sends a request for all sub-pieces to all peers. Sub-pieces which arrived are cancelled to keep too much bandwidth wastage on redundant sending.
Bittorent protocol
What is Bittorent?
Bittorent is one of the efficient content distribution system using file swarming. Usually does not perform does not perform all the functions of a typical p2p system, like searching.
Bittorent Traffic
Cache Logic estimated (around 2003 or so) that BitTorrent Traffic accounts for roughly 35% of all traffic on the internet.
File Sharing
To share a file or group of files, a peer first create a .torrent file, a small file that contains metadata about the files to be shared, and information about the tracker, the computer that coordinates the file distribution. Peers first obtain a .torrent file, and then connect to the specified tracker, which tells them from which other peers to download the pieces of the file. Large files are broken into pieces of size between 64kb and 1mb.
Publishing a file
Let's say Ahmad wanted to share some files through bittorent. Firstly, he have to create a .torrent file such as abc.torrent. Next, he have to upload it the web server and also add in the tracker info. When downloader A wishes to download the file, he have to get the abc.torrent file. Once downloader A has finished downloading, his status from downloader will be changed to seeder just like seeder B. This process continues until there is no new downloader and all seeder has stop seeding. The .torrent file that is been uploaded to the web server should consist of the URL of the tracker, pieces <hash1, hash 2, .., hash n> , piece length , name of the file and also length of file.
As for the tracker. It should consist of IP address, port, peer id , state information (completed of downloading) and also returns a random list of peers.
An example
Seeder = a peer that provides the complete file.
Initial seeder = a peer that provides the initial copy.
For the diagram above we can see that the initial seeder has 5 color boxes. Initial seeder had sent all the 5 boxes to the seeder of which earlier on is known as leecher. Leecher B existed in the network and based on the bitTorrent protocol, leecher B received color box red and light blue from seeder and color box purple from initial seeder as leecher B doesn't have and color box with it. Next, leecher A appears. Seeder send red, blue and black to leecher A. At the same time, leecher B, send light blue and purple and not red even though leecher B has red color box with it. This is because leecher A already received red color box from seeder. This process of file sending continues until every leecher has all the five color boxes and their status is changed from leecher to seeder.
General Idea
The initial seeder chops the file into many pieces. Leecher will first locate the .torrent file that directs it to a tracker, which tells which other peers are downloading the file. As a leecher downloads pieces of the file, replicas of the pieces are created. This means that more downloads mean more replicas available. As soon as a leecher has a complete piece, it can potentially share it with other downloaders. Eventually each leecher becomes a seeder by obtaining all the pieces, and assembles the file. Checksum is verified at the last of it to make sure every file received is correct.
Pieces and Sub-Pieces
As mention above, large files are broken into pieces of size between 64kb and 1mb. From all these pieces, it is further broken into sub-pieces of which sized typically at 16KB. Unless a piece is assembled, the downloading will only download the sub pieces of that piece only. This policy will help the pieces to assemble quickly.
Pipelining
When transferring data over TCP, always have several requests pending at once, in order to avoid a delay between requests pending at once, to avoid a delay between pieces being sent. At any point in time, some number, typically 5, are requested simultaneously. Every time a piece or a sub-piece arrives, a new request is sent out.
Piece Selection
The order in which pieces are selected by different peers is critical for good performance. If an inefficient rule is used, then peers may end up in a condition where each has all identical set of easily available pieces, and none of the missing ones. If the original seed is prematurely taken down, then the file cannot be completely downloaded. There are few rules to apply when come to choosing the correct pieces. Rules such as strict priority, rarest first, random first piece, endgame mode. For random first piece rule to be applied. A peer must have nothing to trade and is it important to get a complete piece as soon as possible. A random piece of the file will be selected and downloaded. Next, for the rarest piece first policy. In this policy, the most rare piece among the peers will be determined and will be downloaded first. This will ensure that the most commonly available pieces are left till the end to download. As for endgame mode, towards the end of the file transferring, missing pieces are requested from every peer containing them. When the piece arrives, the pending requests for that pieces are cancelled. This will ensure that a download is not prevented from completion due to a single peer with a slow transfer rate. Yet, some bandwidth is wasted but in practice this wastage is not too much.
Internal Mechanism
Chocking Algorithm
Choking is a temporary refusal to upload situation. It is one of BitTorrent's most powerful idea to deal with free riders. Free riders are those who only download but never upload. In order to implement this algorithm the tit-for-tat strategy is used. Tit-for-tat strategy is based on game theoretic concepts. Besides to avoid free riders, the choking algorithm is used to prevent network congestion. This means that a good choking algorithm will caps the number of simultaneous uploads for good TCP performance and it will avoids choking and unchoking too quickly. Peers will try out unused connections once in a while to find out if they are any chances that there are better connection that the current ones (optimistic unchoking). Optimistic unchoking is one feature of which a bittorrent peer has to which it uploads regardless of the current download rate from it. This peer rotates in every 30 seconds. The reason this feature is implemented is to discover currently unused connections are better than the ones being used and also to provide minimal service to new peers.
Upload-Only mode
Once downloading process is completed, a peer will change it status to uploading and it has no long the download rates to use for comparison nor has any need to use them. This is when the problem comes of which nodes to upload to? Based on this policy uploading is done to those with the best upload rate. This will ensures that pieces get replicated faster, and new seeders are created fast.
Trackerless Torrents
BitTorrent also supports "trackerless" torrents, featuring a DHT implementation that allows the client to download torrents that have been created without using a BitTorrent tracker.
Existing P2P Simulator
OMNet++
Omnet++ is one of the well-known open-source discrete event network simulators. It is written in C++. The coding procedures and processes are well documented and it also offers multiplicities of network simulation models. The development of a simulation model with OMNet++ has the following steps: Description of the system structure using the NED language; implementation of the simple modules in C++; compilation; and configuration of the simulation [3]. According to Ariza-Quintana, Casilari and Cabrera (2008) , the OMNeT++ simulator has several benefits such as it is an open public source code tool so that programmer is able to add in new libraries and make some modifications to the existing ones according to requirements of the scenario. It also possesses a friendly and simple programming interface which assists in development of new code. The simulator also presents a modular structure where inclusion of new protocol does not require much knowledge of how other parts of the code have been actualized. It also has reduction in simulation time compare with other simulator like the NS-2.
OverSim
Oversim is an OMNet++ based network simulator for overlay and P2P network. It comprises of a few models for both structured and unstructured P2P network. An OverSim feature includes Flexibility. Structured and unstructured networks can be simulated in Oversim. The modular uses Common API to facilitate the extension with new feature. Interactive GUI. GUI helps in debugging and validating new or existing network protocol. User can visualize network topologies, message and nodes sate variables. Exchangeable underlying network models. OverSim gives fully configurable network topology with realistic bandwidth, packet delay and packet loses and simple alternative model for high simulation performance. Scalability. OverSim has the ability to boost up to 10,000 nodes in normal computer and had successfully simulated 100,000 nodes before. Based overlay class. Based overlay class provides a RPC interface, generic lookup class and a common API key based routing interface to the application. Reuse of the simulation code. The implementations of the overlay protocols are reusable for the real network application. Statistics. OverSim collects and keeps statistical data such as sent, received, or forwarded network traffic per node, successful or unsuccessful packet delivery, and packet hop count. It helps user to referring back and producing statistical graph.
METHODOLOGY
3.1 Introduction
BitTorent is a Peer-To-Peer content distribution system, comprised of a set of network protocols for realizing communication between the seeds. It utilizes a simple bartering to prevent parasitic behaviors where peers only download and not uploading anything content. Every time a host wants to distribute a files through BitTorent, the file will organized as a sequence of bytes, these files will be splits into equal size pieces and a hash value will be calculated for each piece. Next, a server will host the file exchange is located of which is also known as tracker.
The content metadata and supporting information such as hash value, piece size, file size, tracker address and etc, are recorded in a file with an arbitrary name that acts as a description and summary of the content. This metafile can then be distributed over the internet so that search engines can match user queries with metafile data.
When presented with a metafile, a client connects to indicated tracker and asks for hosts that are in the swarm and currently are taking part in that particular exchange. Next , each client constructs and maintains a bitmap with the pieces that it has. Then, each client randomly contacts other clients and exchanges bitmaps with them. Based on the bitmaps and other available data, such as path delay or bandwidth, each client can freely select the peers it will exchange pieces with.
The success of BitTorrent stems from two key characteristics. Firstly, its ability to distribute resource consumption among the participating entities, thus avoiding the bottleneck of centralized distribution. Second, to its aptitude to avoid performance deterioration and service unavailability by enforcing cooperation.
3.2 Bittorent protocols
BitTorrent are implemented with two protocols of which Tracker Protocol and Peer-Wire Protocol .The tracker protocol are responsible to help peers to discover one another and form a swarm. To distribute a new files using bittorent must start with publishing a .torrent metafile. As for peer-wire protocol, it provides the core Bittorent functionality. There are several parts to be taken into consideration for peer-wire protocol. Firstly, protocol overview of which a client will establish TCP connections with peers of which listed in the tracker, after get connected with the tracker. A HANDSHAKE message will be exchanged among the peers. Next, connections. The client will learn about other peers periodically by utilizing the tracker protocol and parsing the peer list returned. Besides that, piece downloading strategy is also one of the parts. The piece downloading strategy refers to the rules in selecting the pieces that will be requested from a peer. This will heavily affects the diversity of pieces available in each peer. Followed by the queuing. In queuing, requested messages refer to specific blocks of a piece. This facilitates fine grained data exchange by enabling queuing of data requests.
Next is the super seeding. The super seed feature is especially useful for content distribution as it helps the initial seeder to avoid excessive bandwidth consumption while fostering data exchange between participating peers. Lastly is the endgame mode of which the endgame mode addresses the problem of slow transfers fro the last data blocks of and exchange, since at that stage most pieces have been downloaded, therefore the degree of parallelization is low.
3.3 Implementation
3.3.1 Tracker Protocol
The tracker protocol consists of two principle modules which are BTTRACKERBASE and BTTRACKERCLIENTBASE. The former is the server module, which is part of the tracker, while the latter is the client module, which is part of the BitTorrent application. These modules manage to communicate with each other through the BTTRACKERMSGANNOUNCE and BTTRACKERMSGRESPONSE messages, both derived from the CMESSAGE class. The first class necessary fields, with their corresponding semantics, while the second class encodes the tracker's responses.
The functionality of the tracker is implemented in the BTTRACKERBASE module as a multi-threaded network application. Once the connection to the tracker is launched and established, a thread is generated to drive the session between the tracker and the peer. The BTTRACKERCLIENTHANDLERBASE module is stemmed from the INET TCPSERVERTHREADBASE, which is used to encapsulate and modularize the details of tracker-to-peer communication such as message exchanged, input validation, reply construction, while BTTRACKERSBASE monitors and operates the underlying low-level operations. The client part is applied in BTTRACKERCLIENTBASE including the functionality needed to retrieve tracker responses and feed the bittorent application with the received information.
3.3.2 Peer-wire protocol
The application and implementation of the protocol comprise of two principle modules which are BTPEERWIREBASE and BTPEERWIRECLIENTHANDLERBASE. The main objective for the Bittorrent client is the BTPEERWIREBASE module that encompasses the following functionalities:
Tracker protocol information retrieval, that is, communicating with the tracker client module to retrieve the peer set information provided by the tracker
Managing the connection establishment policy
Implementing the piece selection strategy. This functionality involves maintaining state on
Data availability in the client and throughout the part of the swarm that we connected to.
A client's current data exchanges.
Informing peers about the availability of new pieces, in both the normal and super seeding modes.
Choking algorithm implementation
Coordinating the endgame mode
The BTPEERWIRECLIENTHANDLERBASE class, derived from the INET TCPSERVERTHREADBASE, handles the communication with a single peer. This means that all peer-wire protocol message exchanges between peers are driven by instances of this class. The coordination of individual threads (e.g assuring that a certain block is not requested from more than one peer, except while in the endgame mode) is performed by BTPEERWIREBASE.
The TCPSRVHOSTAPP model creates a new socket for each passive connection which is handled by a new TCPSERVERTHREADBASE instance. In order for our implementation to reflect the completely symmetric character of peer connections, functionality of the client side. Because of that, this BTPEERWIREBASE class allows each new active connection to be handled by a separate BTPEERWIRECLIENTHANDLERBASE thread object. Hence, when a client decides to establish a TCP connection with a peer it creates a new socket, establishes the connection and creates a new BTPEERWIRECLIENTHANDLERBASE instance to be set as the callback object of the socket. In effect, symmetry is achieved, since the connection is handled by two identical thread objects; code structure is therefore simplified, since the peer-wire protocol functionality is incorporated in a single event-based class.
Apart from the classes presented above, this implementation employs two additional utility classes: BITFIELD and BTUTILS. The former represents a peer's bitmap, including block information, and provides all necessary handling functions, such as initialization, updates and queries. The latter is used for handling all the protocol state information described above.
3.3.3 Statistics
The collection of application and protocol statistics is facilitated by BTSTATISTICS, a module of which is responsible for collecting and aggregating statistics. The currently available set of statistics includes the download duration for those peers that have managed to download the desired file in its entirety and the number of downloaded blocks for those peers that have failed (i.e peers who cannot find a peer to provide their missing blocks/pieces). A failed peer is a peer that have failed if it receives empty tracker responses for maxNumEmptyTrackerResponses times before downloading completes. The statistics collected for each peer includes the number of distinct data providers and the number of blocks downloaded from seeder. The former quantifies the degree in which the downloading process is spread across the swarm, while the latter reveals whether users tend to download directly from the initial seeder. For all the above metrics, both individual measurements (vector statistics) and aggregated values (scalar statistics) are recorded, accommodating both coarse and fine grained analysis of the collected data.
3.4 Creating Simulation Scenarios
The implementation was developed as a stand-alone INET framework application, hence,a network topology must be provided and the appropriate module must be loaded as sub modules of the compound modules representing the peers and the traker is a must in order to execute the BitTorrent simulation.While this procedure is sufficient for testing the modules, it is cumbersome to use when constructing realistic scenarios such as :
Large-scale network topologies that require careful handling of node module placement and interconnection.
Random introduction of client into the simulation, both topologically and chronologically, as network description files cannot capture such dynamics.
These indicate that there is a need for globally controlled, network-wide dynamic module loading in the building of the simulation scenario. Therefore, the OverSim overlay simulation framework is used. This is because the OverSim provides several of the features required to establish realistic and dynamic simulation scenarios.
3.4.1 Topologies
One of the most concerning matter in creating realistic simulation platform for BitTorrent is the underlying network topologies. OverSim provides a few underlying network structure, both simple and composite. However, those model present has significant limitations in representing a realistic network substrate.
The SIMPLEUNDERLAY model was designed with the purpose to provide a simple and scalable network substrate specially tailored for simulations focusing on the functionality of higher layer protocols, such as the set of overlay routing schemes provided by OverSim. Packets are exchanging between end hosts directly and are completely neglecting the functionality of the underlying protocol stack in this model. Packet delivery is performed by simply considering the characteristics of the communicating end hosts' access links and samples of end to end propagation delays derived.
This lack of protocol functionality and step by step routing in SIMPLEUNDERLAY has made the implementation shifted to the more realistic IPv4UNDERLAY model. However, there is two important limitations of this model. First, the model only provides a distinction between backbone and access routers neglecting the complex structure imposed by the existence of multiple autonomous administrative domains. Second, the model provides no support for routing policy weights. Enhancements have been made to overcome this problem. However, this give raise to two more significant limitations for IPv4UNDERLAY model.
The first problem is revealed when considering the locality properties of data exchanges in P2P content distribution, such as BitTorrent. It has been shown that BitTorrent's network agnostic peer-wire protocol has an adverse impact on capacity related ISP costs by allowing downloads from peers residing in external domains, even when the desired data are already present locally.
Second, OverSim does not make any distinction between the downlink and uplink characteristics of access links. However, this distinction is important to provide a realistic networking environment, since typical current access technologies, such as ADSL, do present this asymmetry. This issue becomes more important due to the fact that bandwidth heterogeneity results in a systematic unfairness of the peer-wire protocol, as the download rates achieved are based on the tit-for-tat mechanism. Hence, OverSim IPv4UNDERLAY model is further enhanced to support a range of data rate, error rate, and propagation delay characteristics of a link for two directions of each access link.
3.4.2 Host Deployment
After establishing a realistic network topology, the next challenge is to deploy the corresponding entities on it. As long as the tracker is concerned, avoiding coupling the network topology description file with the application is a must. Therefore, the OverSim IPv4UNDERLAYCONFIGURATOR module is modified to dynamically introduce the BitTorren tracker in the network.
Regarding the initial seeder, a separate deployment scheme is implemented, since in many realistic scenarios the initial seeder has different characteristics from ordinary peers. For example, the content might be a new Linux distribution hosted by a dedicated server with a high capacity access link, while ordinary peers participate in the swarm through ADSL links. Protocol parameters may also be altered to achieve a differentiated behaviour between the initial seeder and the peers. The next example is that, the initial seeder may optimistically unchoke multiple peers to speedup the distribution of the offered file. This can be achieved by extending IPv4UNDERLAYCONFIGURATOR and ACCESSNET modules functionality and employing a separate host description file for the initial seeder: BTHOSTSEEDER.
Unlike the tracker and initial seeder, peers need to be randomly introduced into the network both in a topological and chronological sense. The churn models provided by the OverSim platform, together with the underlying IPv4UNDERLAY configuration mechanism, constitute a flexible mechanism for dynamically deploying peers in the network. However, the churn models available in OverSim were not designed to reflect the arrival processes of real applications. Instead, they provide a generic mechanism for the arrival process and several distributions, which describe the duration of a peer's presence in the network. Since in BitTorrent this duration depends on protocol operation rather than on a predetermined distribution, focus are on modelling the arrival process. Using the OverSim churn generator mechanism, the BITTORRENTCHURN model that reproduces the arrival process of BitTorrent clients presented is implemented.
4. Simulations
4.1 Scenarios Implementation
Before any software to be installed Ubuntu version 8 is used as the operating system for this project. OMnet++ simulator version 3.3p1 is used. This is because as stated above the module is built based on a version 3 omnet++ architecture. On top of that INET framework is installed and the version used is INET-20061020-OverSim-3. Finally the OverSim version 20080919 is installed. Once all the prerequisite software is installed, implementing the BitTorrent protocol can carried out. Changes at the settings of the software is made so that the BitTorrent can function as mention above.
4.2 Scenarios Execution
After everything is set up, in order to run the simulations certain parameter have to be set in the omnetpp.ini file. This is the setting of which the standard is done and comparison will be made based on this settings :
include ./defaultBitTorrent.ini
include ./default.ini
[General]
#network = IPv4Underlay
network = IPv4Network
#network = SimpleNetwork
**.statisticsModulePath = "globalObserver.globalFunctions[0]"
sim-time-limit = 2000 # about 33 minutes
[Run 1]
**.peerWire.file_size = 5 #MB
**.targetOverlayTerminalNum = 10
#**.peerWire.file_size = 2500
#**.targetOverlayTerminalNum = 10
description = "No lingering, all-at-once arrival"
**.peerWire.timeToSeed = 0
**.bittorrentDistName = "allAtOnceArrivalRate"
**.bittorrentDistPar1 = -1
output-scalar-file = "results/BitTorrent-1.sca"
output-vector-file = "results/BitTorrent-1.vec"
Below is the screenshot of the scenario:
Bittorent
Oversim BitTorrent Protocol ScreenShot
The picture shows an example of simulation of BitTorrent using Oversim with OMNeT++. It is the basic setting to simulate the Bittorent module after implementing it in OMNeT++
Screenshot of the .sca file of which is the scalar statistics
This picture shows one of the trace file that is created after the simulations had been run based on the standard. This trace file collects only scalar units.
Screenshot of the .vca file of which is the vector statistics
This picture shows one of the trace file that is created after the simulations had been run based on the standard. This trace file collects only vector units.
4.3 Parameter Tweaks and Comparison
As mention, the file sharing will be implemented using OMnetpp and the configuration state will be taken as the standard of which is the most ideal case. From the standard setting (omnetpp.ini) , tweaking will be made. Parameter like file sizes, numbers of nodes and etc. As mention above regarding the protocol, the more nodes exist at the network the faster file transfer can be done. This shows that again that changing the numbers of nodes is one of the key how Bittorent helps in file transfers. Once all these tweaking have been done and data is to be exacted so that comparison can be made. These comparison consist of :-
Rate of packet loss
The delay time
File transfer rate
Rate for the seeds to be in ready state for downloading
The comparison that had been made will be plotted into graphs so that a clearer view on analysis of BitTorrent file sharing can be seen. The data from the graph will be extracted based on the trace file generated by the OMnetpp simulator. From there, the optimization of file sharing with BitTorrent protocol should be able to be derived.
Besides that, data extraction plays an important role in making comparison. In order to extract data out efficiently AWK is used. AWK is a programming language designed for processing text-based data, either in files or data streams. It is an example of a programming language that extensively uses the string datatype, associative arrays and regular expressions.
AWK is one of the early tools to appear in Version 7 Unix and gained popularity as a way to add computational features to a Unix pipeline. A version of AWK language is a standard feature of nearly every modern Unix-like operating system available today. AWK is mentioned in the Single Unix Specification as one of the mandatory utilities of a Unix operating system. Besides that, AWK is the only other scripting language available in standard Unix environment.
Once the script also known as AWK is done data from the trace file of which is generated from the simulation can be extracted according to the pattern written in AWK. Once the data is extracted out graphs can be plotted and information such as rate of packet lost and the rest mentioned above can be easily seen and comparison can be made.
Chapter 5 conclusion
The usage of simulation is important for this project as to research and analysis of the file sharing over Peer-To-Peer protocol, we need a certain number of nodes and it will be too costly to implement it physically. The Peer-To-Peer protocols are available publically for usage with the OMNeT++ simulator. Inside the Peer-To-Peer protocol if several protocol such as the Swarm, BitTorrent and etc. The Swarm had been simulated and analysis. The nodes work by sending request messages to other nodes and waits for a acknowledgement reply for connection to be establish between nodes.
There is also several file sharing protocol available publically mainly the Oversim P2P simulator . The BitTorrent protocol that is implemented inside the Oversim package The project objectives will be bring forward to the Project Phase 2 in order for deeper research to be made in running certain scenarios of BitTorrent on the OMNeT++ simulator.
