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.
Algorithm 6.1 Mobile BitTorrent Algorithm
1: // Maximum number of TCP connections on the mobile
2: const KMaxConnNum=9;
3: // Current number of established TCP connections
4: var currentConnNum=0;
5: // Maximum paralell TCP initiate connections
6: const KMaxParalellStartConnNum=1;
7: // Current paralell TCP initiate connections
8: var currentParalellStartConnNum=0;
9: // Determines whether the torrent is downloaded
10: var isTorrentDownloaded=false;
11:
12: function startDownloadProcess()
13: while !isTorrentDownloaded do
14: if currentConnNum<KMaxConnNum and currentParalellStart-ConnNum<KMaxParalellStartConnNum then
15: currentParalellStartConnNum++;
16: new Thread()(startConnection(getPeerAddress())).start();
17:
18: function startConnection(peerAddress)
19: // blocks until connection is established
20: socket=openSocket(peerAddress);
21: currentParalellStartConnNum=currentParalellStartConnNum-1;
22: if socket!=null then
23: new Thread()(startPeerWireConnection(socket)).start();
24: currentConnNum++;
The startDownloadProcess() is called, when the phone starts to download con-tent related to a torrent file. While the download has not finished yet, it checks the number of active connections and if this number is smaller than the pre-defined maximum number by the platform, it initiates a new connection asynchronously.
However, this solution also checks the number of parallel connection requests and in this current case it allows only one request at a time by using the KMaxPar-alellStartConnNum constraint.
The startConnection() function is responsible for establishing the connection and it manages the constraint counters. After the connection is being established it starts the peer wire protocol with the other peer asynchronously. Accepting incoming connections is not detailed in Algorithm 6.1, however a reasonable
con-straint can also applied for the number of allowed incoming connections. Of course, when the download is finished, this number can be increased.
The other problem is the file handling, especially reading from large files (Table 6.1). For this issue we made a constraint to the total number of request that the mobile client servers while download is in progress. Another constraint also deals with the file writing but it is less strict, since it is much faster. Algorithm 6.2 and 6.3 describes the extension on the BitTorrent peer wire protocol implementation.
Algorithm 6.2 Mobile PeerWire Algorithm A
1: // Maximum paralell piece requests
2: var KMaxPieceRequest=3;
3: // Current paralell piece requests
4: var currentPieceRequest=0;
5: // Maximum paralell piece send
6: var global KMaxPieceSend=2;
7: // Current paralell piece send
8: var global currentPieceSend=0;
9:
10: function startPeerWireConnection(socket)
11: sendHandShake();
12: //start reading incomming messages and data - Algorithm 6.3
13: new Thread(startReading(socket,readerFunction)).start();
14: new Thread(startDownloading()).start();
15:
16: function startDownloading()
17: while !isTorrentDownloaded do
18: if handshakeOK and currentPieceRequest<KMaxPieceRequestthen
19: currentPieceRequest++;
20: sendPieceRequest();
21:
22: function readAndSendPiece()
23: // reading from file system can take long time even in separate thread
24: var pieceBlock=readBlockFromFileSystem();
25: sendPieceBlock(pieceBlock);
26: currentPieceSend=currentPieceSend-1;
In the startPeerWireConnection() function first a handshake message is being sent, then the reader thread is being started which handles incoming messages.
After that another thread is being started that is responsible for initiating content download. It uses theKMaxPieceRequest constraint to request only a low amount
of pieces at a same time. This constraint is responsible to limit the number of file write operations.
Algorithm 6.3 Mobile PeerWire Algorithm B
1: function readPWMessages()
2: var message=readMessage();
3: if message.type==KHandShake then
4: ...
5: else if message.type==KBitField then
6: ...
7: sendBitField();
8: ..
9: else if message.type==KHave then
10: ...
11: else if message.type==KChoke then
12: ...
13: else if message.type==KUnchoke then
14: ...
15: else if message.type==KInterested then
16: ...
17: else if message.type==KNotInterested then
18: ...
19: else if message.type==KPiece then
20: ...
21: savePieceToFileSystem(message.data);
22: currentPieceRequest=currentPieceRequest - 1;
23: ...
24: else if message.type==KRequest then
25: if currentPieceSend<KMaxPieceSend then
26: currentPieceSend++;
27: new Thread(readAndSendPiece(message.pieceIndex)).start();
28: ...
29: else if message.type==KCancel then
30: ...
ThereadPWMessages()function reads and reacts to incoming messages. When a piece arrives it stores in the file system and signs that a new piece request can be initiated. When a piece request arrives from the other peer, it checks the number of file read operations and if allowed, sends the piece block to the peer as described inreadAndSendPiece().
6.4.2 MobTorrent Engine and Parameters
During the design of MobTorrent we considered the previously mentioned limita-tions and the goal was to create a general engine which adapts to the capabilities of the target device. Figure 6.8 illustrates the high level class diagram of the engine.
The diagram contains only the most important attributes, operations and links.
The MTTorrentManager class is connected to the user interface and when a torrent is being selected, the addMTTorrent() function is being called. After that the engine calls the startDownload() function in the MTTorrent class which initializes the download process and connects to the tracker via the MTTracker-Connection class. The result of this communication is the list of peers (MTPeer) who are related to the selected torrent file. Next it connects to the peers until the amount of established peer connections reach the allowedPeerConnections value.
The currently published open source version of MobTorrent also checks whether a peer IP is alive with the help of a server before connecting to it. The MT-PeerConnection class represents an established connection; the BitTorrent peer protocol is implemented in this class. The allowedParallelPieceRequest value de-scribes the number of parallel piece requests to one peer. The MTBitfield object in the MTPeerConnection class describes which pieces have this specific peers.
When a piece arrives, the data is represented by the MTPiece class. After that the hash value of the data is being compared with the original one in the torrent file via the checkSHA1Hash() function. If the piece is valid, it is stored to the file system via the MTFileManager class. The MTFile class helps to determine the exact path and location in the file system. Finally, the MTNetworkManager class is being used for accepting incoming connections.
Proposition 6.1. The proposed mobile BitTorrent engine with Algorithm 6.1, Al-gorithm 6.2 and AlAl-gorithm 6.3 considers to the limitations of the target platform but still remains compatible with the BitTorrent protocol.
Proof. We have described the limitations of feature phones in Section 6.3, where we have discussed about file handling, processing power and file handling. In order to control the resource requirement we have added parameters in the engine.
TheallowedPeerConnectionsattribute in theMTTorrent class describes to how many peers we want to connect at the same time and the allowedIncomingPeers
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].