The first experimental steps towards bringing peer-to-peer technology to mo-bile phones have been taken with the implementations of Gnutella and Bit-Torrent content sharing protocols for smartphones ([Kelényi and Molnár, 2007], [I. Kelényi, 2007]). However, these solutions were implemented on the Symbian platform (for Nokia Series 60 devices) which limits their use to a subset of high end mobile devices and they do not consider simple mobile phones. In this re-search our goal is to bring peer-to-peer technology to feature phones with limited resources.
The essence of BitTorrent is that content (one or more files) is downloaded in multiple pieces. The different pieces are downloaded from separate peers (if possible) in parallel which makes the aggregate download speed much higher than downloading from a single bandwidth limited peer only. Downloadable content is described by a torrent file, which contains the address of the tracker and the
hash values of the content pieces. The tracker maintains a list of peers that are working on the download (or share) of the same content. MobTorrent can open and interpret the torrent files. Next, it connects and registers to the tracker. After, the tracker sends back addresses of several peers that are able to serve the content.
Then MobTorrent sends piece request messages to these peers which respond by starting to upload the content to us. While a peer is downloading content it can also upload the already received pieces to others.
Peer-to-peer solutions differ from general applications, their common charac-teristics are larger network intensity and distributed resource usage. Therefore we investigated BitTorrent technology and feature phones from the perspective of network handling, processing power and file handling. Following we describe our experiences and measurement results.
6.3.1 Network Handling Limitations
The BitTorrent protocol [BitTorrent 1.0, 2010] uses HTTP connections for com-municating with the tracker and TCP connections for the download and upload procedure from/to other peers. These communication protocols are supported in Java ME MIDP 2.0. While we were examining the network abilities of the simple devices, we found that there are some difficulties from peer-to-peer point of view.
We realized and checked with specialists that there are limitations about how many connections can be maintained at the same time. We also realized a socket handling problem in the Java ME implementation. A peer-to-peer application usually has to connect to several other peers. It is possible that some of the peers are off-line or not responding at all. The problem is that the timeout when the system realizes that the address is not responding is 244 seconds on S40 devices and 163 seconds on S60 devices.
Furthermore S40 platform (tested till S40 5th Edition FP1) can handle only one connection request at the same time (S60 is able to handle 8 connection requests in parallel). These show that peer-to-peer applications have different platform requirements than other type of applications and that they bring up problems that are not experienced by other ones.
6.3.2 Processing Power Limitations
Implementing BitTorrent on resource limited mobile devices sets special require-ments to the algorithms. First, we should pay attention to memory usage since its size is much more limited than on PC for example. Therefore a good guideline is to store only that data in the memory which we are currently working on.
Another important thing is to support some kind of thread handling, because BitTorrent uses several connections at the same time. With proper balancing of different connection threads, the application is able to download from several peers at the same time.
While we are developing for simple mobile devices we also have to consider that they have limited processing power. BitTorrent protocol uses the Secure Hash Algorithm version 1.0 (SHA1) for checking the consistency of the downloaded content. When the application has downloaded a piece it has to calculate the hash value of the content and compare it to the value in the original torrent file. This mechanism allows us to find and avoid the faulty or badly downloaded pieces.
Experiences shows that one piece out of 100 can be bad which means without hash checking the probability of error is quite high even for medium-sized content.
6.3.3 File Handling Limitations
In BitTorrent we need to store the downloaded content on the file system of the device. File handling in Java ME differs from the general Java file handling. The main difference is that we can access the file only via input- and output-streams.
The major difficulty is reading a file from a specific position, because there is no efficient file seek mechanism implemented. The problem is that it is not possible to move to a specific position within the stream. For instance if we want to read the last 50 kB from a 40 MB file then we have to read the whole input stream until we reach the right position, and that may take long time. We have also checked this with specialists.
We managed to round this issue in case of content download, because we cal-culate the piece hash values iteratively as they are being downloaded, thus we do not need to read the piece from the file system when it has been downloaded
completely. However this issue remains when we consider piece uploading, because piece requests can arrive from any position of the file.
Investigating this issue, we measured the speed of reading a 64KB size of piece from different position of a file.
Table 6.1. File read performance
(ms) Begin Center End
File1 (2 MB) 1092 4397 7104 File2 (3 MB) 1110 10848 20212 File3 (4 MB) 1146 14478 27213
Table 6.4 illustrates averages, how much time it takes to read the piece from a file. The values in the table are in millisecond. The measurements were made on a Nokia 6230i, 6280, 6500c, 6500 slide, N82, N91 and N93 devices. The rates are very similar on other similar devices. We chose file sizes which are typical on mobile devices like for images, mp3 music and other multimedia files. We can see that the file reading is a bottleneck. In case of BitTorrent it is possible to request the pieces in order or only serve those requests which are close to our current position in the file, but in any cases this issue should be considered carefully.