attribute in the MTNetworkManager class is related to the number of parallel incoming connections. The sum of these values should be less than the number of allowed connections of the mobile device. The balance between them can be changed dynamically during the operation process. We have also measured in Table 6.1 that file reading takes long time. The number of file read operations depends on the number of incoming peers and also from the incoming piece requests from those peers to whom we have connected.
The allowedParalellPieceRequests attribute in the MTPeerConnectioni class has influence to the processing power and file handling. Pieces should not arrive faster than the application is able to check their hash values and store them in the file system.
By adjusting these attributes (even dynamically) the engine is able to adapt to the capabilities of the target device.
Algorithm 6.1, Algorithm 6.2 and 6.3 does not modifies the BitTorrent mes-sages, and does not change message order, therefore it remains compatible with the original BitTorrent engine. In addition to that MobTorrent is able to joint to any BitTorrent network and participate in it as a full peer.
As a result of the general engine, the proposed mobile BitTorrent engine is ap-plicable on other Java based mobile platforms. In order to show this portability, we moved the mobile BitTorrent engine to Android platform and only by modifying the proper HTTP and TCP/IP classes it was able to run on real device. Based on this experiment we have created the AndTorrent application for Android plat-form. We have published measurements and experiences related to AndTorrent in [Erdődy-Nagy and Ekler, 2010].
engine remains on the same level. Finally we introduce measurements related to energy consumption. The described measurements are authoritative for any mobile peer-to-peer solutions.
6.5.1 Performance
First we setup an experimental environment with 1, 3, and 6 peers on PCs which were seeding the torrent. The following two tables show the download speed of MobTorrent, while we were downloading in this environment. Table 6.2 shows the speed in 3G network and Table 6.3 in a WLAN network (the 6230i, 6280, 6500c and 6500 slide device do not support WLAN technology).
Table 6.2. Download speed measurement via 3G network (kB/s) 1 peer 3 peers 6 peers
N93 16 44 51
N91 14 43 51
N82 15 45 52
6500 slide 13 41 49
6500c 14 42 49
6280 13 41 49
6230i 12 38 47
Table 6.3. Download speed measurement via WLAN network (kB/s) 1 peer 3 peers 6 peers
N93 67 46 92
N91 65 82 95
N82 69 88 98
Figure 6.1 introduces the download speeds in a real environment. All numbers are averages of 5 measurements.
Figure 6.1. Download speed in real environment
6.5.2 Memory Requirements
As we have mentioned earlier feature phones have limited amount of memory, there-fore it is very important that the memory requirement should not increase during the download process. In order to measure the memory requirements of MobTor-rent we have used the Nokia Energy Profiler for Symbian platform [ene, 2010].
Follwoing we show that the memory requirement of the proposed mobile Bit-Torrent engine remains on a relatively constant level during the download process.
In addition to that, a reasonable download performance is reachable during the whole process.
In order to examine the behavior of MobTorrent we executed download process 5 times and we examined the average of these measurements. Figure 6.2 illustrates the memory usage plot. It shows that starting the application requires 2-3 MB, this is the amount of memory what Symbian allocates when starts a Java application.
On feature phones this memory is pre-allocated for the Java Virtual Machine, which is always in the memory. After that during the download the small peaks show the periodical memory allocation of Symbian, it allocates periodically a specific amount of memory and later free it, since it is not needed. A small decrease at around 300 sec shows when the download finishes.
The download speed plot is illustrated on Figure 6.1. The measurement was made in parallel with the memory requirement measurement. The plot is typical
Figure 6.2. Memory requirements in real environment
in BitTorrent because the piece arrival from peers is not continuous. We can see that the avarage of the download speed was around 50 kB/sec.
The BitTorrent performance measurements of [Pouwelse et al., 2007] found that download speed for 90% of the peers were below 65 kB/sec, thus the per-formance of mobile phones are close to this value.
We have made several additional measurements on different devices with the same result and feedbacks from users was also positive.
6.5.3 Energy Consumption
Energy consumption is very important in mobile applications as the battery of the device is very limited. Therefore it is always important to analyzie the energy consumption of a new, resource intense solution.
Proposition 6.2. The energy requirement of the proposed mobile BitTorrent en-gine can be estimated with P = DCS
APA , where CS is the content size, DA = 50kB/sec is the average download speed and PA = 1.25W is the average energy consumption. The energy consumption remains on a relatively constant level dur-ing the whole download process.
Proof. The energy consumption plot is illustrated on Figure 6.3. This measurement was made in parallel with the previously introduced memory requirement and
performance measurements. It shows that during the download the consumption level is around 1.25 W. At the beginning the higher peak indicates when the screen backlight is on. After the 300 sec we can see that basically the consumption is zero.
It also indicates that MobTorrent does not use unnecessary energy if it does not download or upload.
Figure 6.3. Energy consumption in real environment
Considering energy consumption (Figure 6.3) and download performance (Fig-ure 6.1) meas(Fig-urements by applaying an average DA = 50kB/sec download speed and PA = 1.25W energy consumption level, an estimated energy requirement (P) can be calculated to a specific content size (CS), that is intended to download:
P = CS
DAPA (6.1)