• 沒有找到結果。

Multiple-Files-Single-Torrent

In this chapter we are going to discuss the case of MFST. Actually on paper MFST is almost the same as MFMT, with only one difference: These multiple files distributed across different Torrents in MFMT are now all bundled into a single torrent in MFST. It is quite hard to distinguish their difference through mathematic modeling. In facts, its depends on the way the BitTorrent client actually handles the Multiple-file torrent MFMT and MFST could be the same. As mentioned before Tian et al. [8] do use the same model on them in his work.

Despite using the same model on MFMT and MFST, they still believe that there may be differences between these two different download methods. The difference they mentioned in their works is the concept of file correlation, which we have mentioned before. Another attribute that we think that may affect the difference between these two download methods are the number of unchoking slots used.

In most practical BitTorrent clients, the number of allowed connections and choking

slots are restricted within each task. Usually one task is added for every torrent that BitTorrent clients download no matter how many files are within the torrent. So, the difference between MFMT and MFST may occur here. Take for example; downloading

38

the same three files A, B, C and n unchoking slots are used for every task in the BitTorrent Clients. If these 3 files are downloading through three separate torrents, a total of 3n unchoking slots are going to be used; but only n unchoking slots are used when these three files are bundled intoa single torrent.

Fan et al. [10] have studied the influence of number of unchoking slots to the download performance in BitTorrent. In his model he finds that the ratio between

optimistic unchoking slots and regular unchoking will affect the download performance:

the higher the ratio of optimistic unchoking, the higher the download performance. It is very obvious because the unbiased Optimistic unchoking slot compared to the biased

regular unchoking slot does not have the bandwidth lost due to playing tit-for-tat

strategy. Most of the works including [4, 8, 9, 17] have all made the similar assumption that optimistic unchoking slot does outperform regular unchoking slot in sharing efficiency.

The ratio between two different unchoking slots do affect the performance of the BitTorrent system, but if the ratio is maintained, no matter the number of unchoking

slots are used the performance of system will stay the same [10]. It is quite easy to understand because we usually assume there are a sufficient number of peers in the system and there are always pieces to download if the bandwidth is allowed. But in the

39

real world there may be chances that even though we have enough unoccupied bandwidth, there are no desired pieces to download.

As to our knowledge of most of the commonly used BitTorrent clients, the default number of optimistic unchoking slots and regular unchoking slots are 1 and 4

respectively. They are set to the number not according to any theory or proof but by experience. We wonder if this setting by past experience may not work that well when considering the existence of multiple-file torrents.

Unfortunately, we cannot theoretically prove that if we extend the number of unchoking slots used according to the number of files in the torrent, that can affect the performance of download. As a result, we decided to examine this situation by running some simulation experiments in the next chapter.

40

Chapter 4

Experiment Result

In the previous chapter we theoretically examine some different multiple-file download approaches of BitTorrent. We have made some assumptions but there are still many cases that we have failed to analyze. In this chapter, we decided to study them through a series of simulation experiments.

The Simulator Used

The simulator we used is General Peer-to-Peer Simulator (GPS) [13]. GPS is an event-driven p2p simulator which simulates every messages passing between peers. The reason we choose GPS as our simulator is because it already has a built-in BitTorrent protocol and also support for multiple-file downloads.

GPS adopt the GT-ITM [25] as a tool to simulate the topology of a real network.

The bandwidth is also constrained according to the network topology. In the network

41

topology that GPS used there are two kinds of nodes transit node and stub node. Transit nodes are the backbone of the network and stub nodes are the edge of network or the place where peers actually exist. These two different nodes form three kinds of different connections. These connections are the connection between two transits nodes (TT), connection between two stub nodes (SS) and the connection between transit node and stub node (TS).

The bandwidths are allocated according to these connections. The propagation delays on the connections are also considered. All of the above features make GPS closer to a real network environment.

The experiments in GPS are configured by two text-based setting files; document file and event file. Document file defines the size and amount of the download files in the system. Event file defines event happened in the system.

In the following experiment 1 and 2, we are using the default setting of GPS for the bandwidths and delays on different connections. Bandwidth between two transit nodes is 1000Mbps with a 5ms of delay. Bandwidth between transit node and sub node is 100Mbps with a 10ms delay. Bandwidth between two stub nodes is 10Mbps with 30ms delay.

42

Bandwidth Transit-Transit 1000 Mbps

Bandwidth Transit-Sub 100 Mbps

Bandwidth Sub-Sub 10 Mbps

Delay Transit-Transit 5 ms

Delay Transit-Sub 10 ms

Delay Sub-Sub 30 ms

Table 3 Network setting of experiments 1 and 2

相關文件