文件列表:

bittorrent (0, 2008-03-26)
bittorrent\script (0, 2008-03-26)
bittorrent\script\simu.tcl (10287, 2007-09-27)
bittorrent\bitagent.cc (4083, 2008-03-26)
bittorrent\bittable.cc (30035, 2008-03-26)
bittorrent\bittcpapp.cc (3695, 2008-03-26)
bittorrent\bittorrent.h (11230, 2008-03-26)
bittorrent\bitagent.h (2535, 2008-03-26)
bittorrent\bittable.h (7492, 2008-03-26)
bittorrent\bittcpapp.h (5000, 2008-03-26)
bittorrent\bittorrent.cc (120428, 2008-03-26)

### How to build a program (Makefile setting) 1. Makefile In order to simulate our BitTorrent implementation, you should add a define "BITTO" to your Makefile of ns-2 and add lists of files about our BitTorrent implementation (that will be listed below section). Also, there is an additional define variables called "BIT_DOWNLOADING". If you turn on this variables, the BitTorrent node will handle the DOWNLOADING state of a block; If a block is downloading from a neighbor, a node will not request to offer that block to any other BitTorrent nodes only if there exists an imcomplete block of a piece which are not in the DOWNLOADING state. This helps to minimize the number of packets in the network, but it can make that node taken a little bit more to finish to download. 2. Modified files of the existing NS-2 In order to implement our BitTorrent, I modified some existing ns-2 implementations. Here are the lists of modified files. - $NS/Makefile - $NS/tcl/lib/ns-default.tcl - $NS/common/packet.h - $NS/ns-process.h - $NS/dsdv/dsdv.h - $NS/dsdv/dsdv.cc ### The list of C++ source code 1. bitagent.[cc/h] - These files contain the implementation of BitAgent class and struct hdr_bitAgent - BitAgent is the Agent class which will transmits the control message by using UDP protocol - hdr_bitAgent is the packet header of control message of BitTorrent - To use, "flooding_ttl_" bind variables with Tcl script should be set 2. bittable.[cc/h] - These files contain the implementation of several data structure classes (BitPeer, BitNeighbor, PeerTable, NeighborTable, Piece, PiecePool) - BitPeer represents the peer object of the BitTorrent node - BitNeighbor represents the neighbor object of the BitTorrent node - PeerTable contains the peer lists of the BitTorrent node by using Tcl_HashTable whose key is the id_ of the peer object - NeighborTable contains the neighbor lists of the BitTorrent node by using Tcl_HashTable whose key is the id_ of the neighbor object - PeerTable / NeighborTable should be initiated with the maximum number of object which it can contain - Piece represents the piece object of the file which will be shared by BitTorrent nodes --> The file is consisted with several pieces and a piece is consisted with several blocks - PiecePool contains all the pieces of the file by using Tcl_HashTable whose key is the id_ of the piece object, and maintains the status of the piece (COMPLETE, DOWNLOADING, INCOMPLETE) 3. bittcpapp.[cc/h] - These files contain the implementation of BitTcpApp class and BitTorrentControl class, and BItTorrentPayload class - BitTcpApp is inherited from the TcpApp which is the famous application to use FullTcp in NS-2 - In order to establish the TCP connection between two BitTorrent nodes, BitTcpApp object should be attached to each of the wireless nodes. Because we establish the TCP connections between every BitTorrent nodes dynamically, this TCP connection is maintained by BitConnection object. - BitTorrentControl represents the control packet of BitTorrent - BitTorrentPayload represents the packet header and the payload of data transmission - Because NS-2 doesn't support the transmission of application payload, we use CBuf and CBufList of TcpApp in order to capsulize the data transmission to BitTcpApp or BitTorrent object. 4. bittorrent.[cc/h] - These files are the main source files of BitTorrent program. These files contain the implementation of BitTorrent, BitConnection, GlobalBitTorrentList, GlobalBitConnectionList. - BitTorrent represents the BitTorrent application and implements the protocol of BitTorrent - BitConnection maintains the dynamic TCP connection between two BitTorrent (BitTcpApp) nodes - GlobalBitTorrentList maintains the global list of BitTorrent nodes in the simulation. It is only for implementation details, it is never concerned with BitTorrent protocol. - GlobalBitConnectionList maintains the global list of BitConnection objects in the simulation. It is also only for implementation details, never related with the BitTorrent protocol. ### Configurable parameters of Tcl script These are the parameters which can be configured at tcl scripts. All the default values are written at NS/tcl/lib/ns-default.tcl. Application/BitTorrent set max_peer_num_ 10 -> The maximum number of peers that node can have Application/BitTorrent set max_neighbor_num_ 10 -> The maximum number of neighbors that node can have Application/BitTorrent set max_upload_num_ 4 -> The maximum number of upload connections that node can have -> When this value set as 1, the BitTorrent performs a serial transmission. When this value set over 1, it performs a parallel transmission. Application/BitTorrent set max_download_num_ 4 -> The maximum number of download connections that node can have Application/BitTorrent set local_rarest_select_flag_ 1 -> The flag from where the BitTorrent calculate the local rarest piece -> If is 1, it will calculate from the PeerTable. -> If is 2, it will calculate from the NeighborTable. Application/BitTorrent set control_tcp_flag_ 1 -> The flag about how its control message to transmit -> If 0, use UDP. If 1, use TCP. Application/BitTorrent set use_bidirection_tcp_flag_ 1 -> The flag about whether to use its TCP connection for uni-direction or bi-direction -> If 0, it uses uni-direction. If 1, bi-direction. Application/BitTorrent set peerTable_flag_ 1 -> The flag about whether the node removes its peer which became a Seed when the node itself became a Seed. -> Recommended to use 1 always. Application/BitTorrent set selectNodeToUpload_flag_ 2 -> The flag about how to select node to upload -> If 0, it selects nodes based on a choking algorithm of original BitTorrent (named basic) -> If 1, it selects only physical 1-hop nodes (named 1HOP) -> If 2. it selects based the closest node first strategy -> If 3. a node selects nodes like basic and only the seed selects nodes randomly Application/BitTorrent set selectNeighbor_flag_ 0 -> The flag about how to select neighbors from the peerTable -> If 0, it selects the closest peers first -> If 1, it selects randomly Application/BitTorrent set try_upload_interval_ [expr 10* [Application/BitTorrent set max_upload_num_]] -> The interval to try to offer the piece to its neighbors -> The unit is sec (simulation time) Application/BitTorrent set printCPL_flag_ 1 -> The flag about whether to generate result files of the current having Piece ID list or not -> If 0, do not generate, and if 1, generate the result files. Application/BitTorrent set choking_best_slot_num_ 3 -> The number of best slot for choking algorithm Application/BitTorrent set choking_optimistic_slot_num_ 1 -> The number of optimistic slot for choking algorithm Application/BitTorrent set into_steady_state_time_ 1000 -> There are two kinds of phase in our BitTorrent. The nodes should transmit HELLO messages more frequently at the first time, because in order to share the file fastly it needs to know about the node in the network. -> Therefore, we separate the startUp phase and steady phase. This value indicates when the BitTorrent node goes into the steady phase. -> The unit is the simulation time. Application/BitTorrent set peer_update_interval1_ 100 -> The "peer_update_interval" is the interval to flood the HELLO message into the network -> This value is the peer_update_interval for startUp phase. So, we strongly recommend to set this value smaller than the value of peer_update_interval2 which is the peer_update interval for steady phase. -> When the timer for peer update is expred, the node starts to flood HELLO message. Whenever it receives the HELLO_REPLY from a node, it adds the sender of HELLO_REPLY to its peerTable. -> The peerTable is maintained based on update manner not re-creation manner. The remove procedure performed only when the node itself became a seed and at that time it removes only the seed peers from its peerTable. Application/BitTorrent set peer_update_interval2_ 500 -> The interval to update its peerList by flooding HELLO message at the steady phase Application/BitTorrent set neighbor_select_interval1_ [expr 2*[Application/BitTorrent set try_upload_interval_]] -> The interval to select neighbor from the peerTable at startUp phase -> We also strongly recommend to set this value smaller than the neighbor_select_interval2_ -> Unlike peerTable, neighborTable is maintained based on re-creation manner not update manner -> In the current version of our BitTorrent implementation, we select neighbors based on its hopcount (Closest one first), but it can be changed based on the performance results. Application/BitTorrent set neighbor_select_interval2_ [expr 2*[Application/BitTorrent set try_upload_interval_]] -> The interval to select neighbor from the peerTable at steady phase Application/BitTorrent set received_bytes_reset_interval_ 60 -> The original BitTorrent adapts the choking algorithm to facilitate the file sharing. In choking algorithm, the BitTorrent node chooses the best unchoking nodes based on how many bytes it provide to me. -> This value is the interval to reset the history about how many bytes it receives from a specific node. Agent/BitAgent set flooding_ttl_ 3 -> The time-to-live value which will be used in flooding of HELLO message PiecePool set piece_num_ 10 -> The number of pieces in the file which will be shared PiecePool set block_num_ 10 -> The number of blocks in one piece PiecePool set block_size_ [expr 10*1000] -> The size of a block. The unit is bytes. -> Therefore, the size of the file which will be shared is piece_num_ * block_num_ * block_size_. ### How to run a simulation 1. Setting of Tcl script 1.1. Other protocols or schemes used for implementation I adapted below configuration with all experiments and implementation. set opt(chan) Channel/WirelessChannel set opt(prop) Propagation/TwoRayGround set opt(netif) Phy/WirelessPhy set opt(mac) Mac/802_11 set opt(ifq) CMUPriQueue set opt(ll) LL set opt(ant) Antenna/OmniAntenna set opt(ifqlen) 50 ;# max packet in ifq set opt(seed) 0.0 set opt(rp) DSDV ;# routing protocol script $ns_ node-config -adhocRouting $opt(rp) \ -llType $opt(ll) \ -macType $opt(mac) \ -ifqType $opt(ifq) \ -ifqLen $opt(ifqlen) \ -antType $opt(ant) \ -propType $opt(prop) \ -phyType $opt(netif) \ -channel [new $opt(chan)] \ -topoInstance $topo \ -agentTrace OFF \ -routerTrace OFF \ -macTrace OFF \ -MovementTrace OFF 1.2. Parameter setting of protocols except BitTorrent And belows are the used parameters' setting for every protocols except BitTorrent. set opt(initEnergy) 99999999 set opt(rxPower) 100 set opt(txPower) 100 LL set mindelay_ 50us LL set delay_ 25us LL set bandwidth_ 0 ;# not used Queue/DropTail/PriQueue set Prefer_Routing_Protocols 1 Antenna/OmniAntenna set X_ 0 Antenna/OmniAntenna set Y_ 0 Antenna/OmniAntenna set Z_ 1.5 Antenna/OmniAntenna set Gt_ 1.0 Antenna/OmniAntenna set Gr_ 1.0 Phy/WirelessPhy set CPThresh_ 10.0 Phy/WirelessPhy set CSThresh_ 3.92405e-08 ;#Carrier Sensing Range = 70 Phy/WirelessPhy set RXThresh_ 7.69113e-08 ;#Transmission Range = 50 Phy/WirelessPhy set Rb_ 2*1e6 Phy/WirelessPhy set Pt_ 0.2818 Phy/WirelessPhy set freq_ 914e+6 Phy/WirelessPhy set L_ 1.0 Agent/DSDV set perup_ 30 1.3. BitTorrent Setting for Tcl script Belows are about how to create and intialize the BitTorrent node at Tcl scripts. set node_($i) [$ns_ node $i] set id [$node_($i) id] set bitAgent_($i) [new Agent/BitAgent] set bit_($i) [new Application/BitTorrent $id $node_($i) $opt(nn)] set addr [$node_($i) node-addr] $ns_ attach-agent $node_($i) $bitAgent_($i) $bit_($i) attach-agent $bitAgent_($i) set piecePool [new PiecePool $file_name_] $bit_($i) setPiecePool $piecePool $ns_ at $opt(measureStart) "$bit_($i) start" As you can see, you should pass the ID of node, the instance of NS-2 wireless node which the BitTorrent layer will be attached, and the number of node in the network topology to a BitTorrent node at creation. If you want to know the reasons the pass these information, please refer the constructor function of BitTorrent class (bittorrent.cc). Also, in order to use a BitTorrent node in your simulation, you should add BitAgent class to every node whcih will be deployed in the network. Unless, a BitTorrent node cannot receive a UDP control message correctly. And, you should attach a BitAgent instance to the NS-2 wireless node, and a BitAgent instance to a BitTorrent node. After that, you should create a PiecePool (file) and attach it to a BitTorrent node. A PiecePool instance should be initialized by passing the name of file, and every PiecePool of BitTorrent nodes which you want to share the file each other should be initialized by the same name. You can indicate the seed node with setting one of the PiecePool as complete by using the command of PiecePool "setAsComplete". At last, you should call the command "start" to a BitTorrent node which you want to start the functionalities of our BitTorrent protocol. The "start" command should be called during simulation time.

近期下载者：

相关文件：

评论：[我要评论] [举报此文件]

收藏者：