Conference PaperPDF Available

Asterism: Decentralized File Sharing Application for Mobile Devices


Abstract and Figures

Most applications and services rely on central authorities. This introduces a single point of failure to the system. The central authority must be trusted to have data stored by the application available at any given time. More importantly, the privacy of the user depends on the service provider capability to keep the data safe. A decentralized system could be a solution to remove the dependency from a central authority. Moreover, due to the rapid growth of mobile device usage, the availability of decentralization must not be limited only to desktop computers. In this work we aim at studying the possibility to use mobile devices as a decentralized file sharing platform without any central authorities. This was done by implementing Asterism, a peer-to-peer file-sharing mobile application based on the Inter-Planetary File System. We validate the results by deploying and measuring the application network usage and power consumption in multiple different devices. Results show that mobile devices can be used to implement a worldwide distributed file sharing network. However, the file sharing application generated large amounts of network traffic even when no files were shared. This was caused by the chattiness of the protocol of the underlying peer-to-peer network. Consequently, constant network traffic prevented the mobile devices from entering to deep sleep mode. Due to this the battery life of the devices was greatly degraded.
Content may be subject to copyright.
Asterism: Decentralized File Sharing Application
for Mobile Devices
Olli-Pekka Heinisuo
Tampere University
Tampere, Finland
Valentina Lenarduzzi
Tampere University
Tampere, Finland
Davide Taibi
Tampere University
Tampere, Finland
Abstract—Most applications and services rely on central au-
thorities. This introduces a single point of failure to the system.
The central authority must be trusted to have data stored by the
application available at any given time. More importantly, the
privacy of the user depends on the service provider capability to
keep the data safe. A decentralized system could be a solution to
remove the dependency from a central authority. Moreover, due
to the rapid growth of mobile device usage, the availability of
decentralization must not be limited only to desktop computers.
In this work we aim at studying the possibility to use mobile
devices as a decentralized file sharing platform without any
central authorities. This was done by implementing Asterism,
a peer-to-peer file-sharing mobile application based on the Inter-
Planetary File System. We validate the results by deploying and
measuring the application network usage and power consumption
in multiple different devices.
Results show that mobile devices can be used to implement
a worldwide distributed file sharing network. However, the
file sharing application generated large amounts of network
traffic even when no files were shared. This was caused by
the chattiness of the protocol of the underlying peer-to-peer
network. Consequently, constant network traffic prevented the
mobile devices from entering to deep sleep mode. Due to this the
battery life of the devices was greatly degraded.
Index Terms—decentralized file sharing, peer-to-peer, mobile,
Sailfish OS, InterPlanetary File System
The usage of mobile devices has increased significantly
during the past 10 years. The users of all these network
connected devices are producing and consuming more data
than ever before
Many of the mobile devices are connected to one or multiple
services which are often running on cloud platforms such
as Amazon’s AWS and Microsoft’s Azure. These platforms
provide computing resources, for example storage space
and processing power, to build scalable web-based software
services. To the end users cloud services are usually completely
transparent: they make it possible for software applications to
share data between different devices everywhere in the world.
Cloud usage has been growing rapidly in recent years and
it will continue to grow in the future [1]. Consequently, more
and more personal data of the end users is stored in large
centralized data centers which are owned and controlled by a
few large private enterprises [2]. While centralized storage is
proven to work well, it has many implications regarding privacy,
security and control of the data. Facebook’s and Cambridge
Analytica’s illegal usage of 50 million user profiles is a recent
example of these issues [3].
To avoid the issues of centralization, data can to be stored
without any central authorities. Decentralized storage and
content distribution can be achieved with peer-to-peer (P2P)
networking. In peer-to-peer networking every node of a network
is both a client and a server [4]. The nodes then talk to each
other without any central service as opposed to centralized
systems where all communication goes through dedicated
central servers.
Peer-to-peer (P2P networks and file sharing are rather
common on desktop environments but they have been rarely
used on mobile devices due to more restricted resources.
However, the growth of the mobile ecosystems has changed
the situation: the processing power of mobile devices is getting
better every year [5]. Similarly, the mobile network speeds
are growing fast [6]. While mobile devices are used a lot,
a considerable amount of processing power and network
bandwidth remains still unused. Additionally, mobile devices
are almost always on and connected to the Internet. These
unused resources could be used to power a worldwide P2P
data sharing network.
The goal of this paper is to understand if it is possible
to transform mobile devices into fully decentralized content
delivery network without any central servers or authorities.
We implemented Asterism
, a file sharing mobile application
based on a P2P network and then we evaluate the P2P software
affects to the performance of the mobile device.
We defined our Research Question (RQ) as:
: is it possible to transform mobile devices into
decentralized distributed content delivery network without any
central servers or authorities?
The remainder of this paper is structured as follows.
Section II described related works. Section III introduce the
background and the requirements of our proposed decentralized
while Section VI reports on the implementation of the system.
Section VII reports on the experimental analysis performed to
compare the performance of our system. Finally, Section VIII
draws conclusions and ideas for further development.
Matuszewski et al. [7] analyzed the user’ attitude towards
mobile peer-to-peer (P2P) content sharing applications, high-
lighting the need for such applications and reporting that
most of the users they interviewed were willing to run the
1Asterism. Source code and Binaries:
P2P application only for a short periods of time given that
they are familiar with the people they are sharing content
with. Heikkinen et al. [8] measured the mobile P2P TCP/IP
traffic generated by GSM/UMTS networks of three major
Finnish operators. Different P2P applications were identified
by transport protocol port numbers. As a result, direct P2P
traffic was not observed but instead 9-18 % unidentified
traffic was detected, probably as a cause of the usage of P2P
applications while using phones as wifi routers. In addition to
direct network traffic analysis, a panel study was conducted.
The study revealed that only one mobile P2P client application,
Fring, had significant usage levels across all participants.
The BitTorrent protocol and different implementations based
on it has been studied widely in mobile environments in many
different contexts.
Nurminen et al. [9] proved that P2P content sharing is
feasible from power consumption point of view. In the research
the power consumption of a mobile BitTorrent client was
measured. The power consumption was on the same level
as mobile phone voice calls. It must be noted that the
measurements were done in 2008: mobile devices and their
properties, most notably power usage due to more powerful
hardware, has significantly changed since then.
Bori et al. [10] studied the reliability of BitTorrent protocol
in mobile environment based on a mobile BitTorrent application
called DrTorrent with 5000 active users. They concluded that
BitTorrent is generally realiable, but the client applications
must be capable of handling different anomalies such as failed
TCP connections and corrupted data.
A hybrid BitTorrent based content sharing solution has been
also studied: Ekler et al. [11] proposed a new content sharing
solution based on BitTorrent and central servers controlled
by mobile operators. The solution supports both mobile and
PC clients. The central server and and operator’s central unit
help to distribute the content more efficiently which in turn
helps to reduce service provider costs. Two different BitTorrent
client implementations, SymTorrent and MobTorrent, were
also addressed in the paper by Ekler et al. [11]. When the
implementations were compared, SymTorrent was faster than
MobTorrent on both 3G and WLAN networks. According to the
authors this is due to the fact that MobTorrent was implemented
in Java ME and SymTorrent had been written natively in C++.
The Java implementation suffers from the overhead of the Java
Virtual Machine and socket handling limitations of Java ME.
The content lifecycle and client usage in BitTorrent network
has been studied by the data provided by MobTorrent mobile
application by Csorba et al. [12] and Ekler et al. [13]. In the
papers, 2 and 3 to 4 years of data collected via the MobTorrent
client was analyzed. The data suggests that mobile BitTorrent
has become more popular every year. The results show also
that there were more unfinished downloads than completed
downloads caused by multiple simultaneous downloads of the
same content. Three largest categories by accessed torrents
were videos, applications and audio.
In addition to BitTorrent, also other P2P protocols has been
studied from energy consumption point of view in mobile
environments. Gurun et al. [14] studied Chimera P2P protocol
with an application on a embedded device. Most of the energy
was consumed by the wireless interface when it was waiting for
transmissions in idle state. As a energy conservation technique
the wireless card was switched to a low power mode when no
network communication was observed. This approach resulted
in power savings. As a result, the study suggested that P2P
protocols and applications can be used on low-power embedded
The general performance of DHT-based P2P overlays in
mobile environments was measured by Chowdhury et al. [15].
Five different DTHs were analyzed: Chord, Pastry, Kademlia,
Broose and EpiChord. The measurements were done in an
simulated environment. According to the results, the best choice
for a mobile P2P overlay under heavy churn is Kademlia due
to its good 97 % lookup success ratio while consuming 316
bytes/s of bandwidth. Additionally, EpiChord performs also
well by achieving a 63 % success ratio while consuming only
70 bytes/s of bandwidth.
Khan et al. [16] introduced a P2P network data store targeted
for mobile environments. Their goal was to mitigate the
previous issues related to the resource limitations, by structuring
the P2P network into redundant clusters of peers and by
updating the routing tables with a gossip-based protocol. In their
simulations they achieved 12- 48 % better look-up success rate
than MR-Chord and Chord based P2P systems. Additionally,
due to good churn and workload adaptation capabilities, they
also managed to distribute requests more evenly than the two
other systems.
In summary, the previous work has studied P2P networking
in mobile environments from different perspectives including
topics such as P2P usage level measurements, mobile BitTorrent
clients, power consumption measurements and different DTH-
based systems. This paper aims to extend the previous research
by providing a fresh practical approach on P2P networking
on mobile devices. Further, by creating an actual mobile
application on top of an existing modern P2P network the
behavior and performance of the system can be evaluated in
real environment.
In this section we first describe the different mobile file
sharing systems available and how we selected the most
appropriate for this work. Then we describe the different
mobile operating systems where the file sharing system can be
implemented together with the selection of the most suitable
for our purpose.
Many new peer-to-peer (P2P) content sharing networks
have emerged in the last few years. Most prominent of these
systems are InterPlanetary File System (IPFS) [17], Dat [18]
and Swarm [19]. These three systems were selected to this
comparison due to their popularity, open source implementa-
tions and the large development efforts behind them. Based
on this comparison one of them will be selected to be used as
the back end in the application implemented in this paper.
InterPlanetary File System is a P2P distributed file system
[17]. Its ultimate target is to replace Hypertext Transfer Procotol
(HTTP) and build a new decentralized Internet infrastructure.
IPFS combines multiple different proven techniques of past
successful distributed systems to create a new solution which
attempts to connect all computing devices under a single
worldwide file system. Among these are for example Kademlia
DHT, BitTorrent and distributed version control system Git
Dat is a P2P protocol which is designed for syncing versioned
data [18]. It attempts to replace cloud based storage services
such as Dropbox and Google Drive due to their centralized
nature, high costs, slow transfer speeds and privacy issues. Dat
has many similarities with IPFS: it’s inspired by projects such
as Git and BitTorrent. However, Dat’s main idea is narrower: it
offers a free and encrypted versioned P2P data syncing system.
Similarly to IPFS and Dat, Swarm is a distributed platform
which provides P2P data storage services [19]. Swarm is closely
related to the Ethereum blockchain ecosystem [21]. Its primary
target is to serve as decentralized and redundant storage system
for all data related to Ethereum. Unlike Dat and IPFS, Swarm
does not require that the uploaders host the content themselves.
This is possible due to a built-in incentive system which rewards
nodes that are hosting content.
These three systems are compared from the perspective of
the mobile application development. To be able to select the
best system for the use case in this thesis and to be future proof,
the following properties have been selected to the comparison:
Initial release year
Existing protocol implementations by programming lan-
Developer community size, roughly estimated by the
project’s pages at Github
Maturity of the software
IPFS and Dat have been published a few years before Swarm.
Due to this, IPFS and Dat projects have had more time to
develop and test the system. Dat is the only project which
has been able to achieve a stable release. However, despite
IPFS being still in alpha state it is being used all around the
world. The IPFS reference implementation, go-ipfs, is mostly
functional but it lacks some features of the original specification
[22]. On the other hand, Swarm is only at a proof-of-concept
phase and is more likely to undergo larger changes in the
Swarm is backed both by a very large user-base and
developer community because it is tightly related to the
Ethereum blockchain ecosystem. IPFS has a medium-sized
community behind it and is being actively developed. Dat
has the smallest developer community, but the development is
active and it is unlikely that the developers would abandon the
project at this point.
The main implementations of IPFS and Swarm are written
in Go. Go is an open source programming language [24].
It makes it easy to run both IPFS and Swarm almost on
any device. In addition to Go, IPFS has also a JavaScript
implementation which makes it possible to run IPFS in web
browsers. The development efforts of Dat are focused solely on
JavaScript. Like IPFS, Dat can be run on web browsers. Outside
browsers Dat needs a JavaScript runtime or some browser based
environment to be able to run. This is a drawback, since it
makes it harder to develop applications especially for mobile
devices due to the special runtime environment needs.
While all the three projects are similar on higher level, their
approaches to P2P content sharing are very different when
observed more closely. Swarm is part of the large Ethereum
ecosystem but it means that it requires Ethereum to work
properly. Additionally, Swarm is not as mature as the other two
projects. Dat has had multiple stable releases, but JavaScript
makes it hard to integrate it into resource constrained mobile
environments. The remaining candidate is IPFS. Go-ipfs, the
reference implementation of IPFS, can be considered stable
enough for a proof-of-concept mobile application in this paper.
InterPlanetary File System (IFPS) is a P2P network protocol
that integrates multiple techniques to create a distributed and
versioned file system with no single point of failure. This
section goes through the basics of the architectural stack of
IPFS and explains how IPFS works.
The IPFS stack can be divided into five sections [22] (see
Figure 1 for more details).
Applications can be implemented on top of the IPFS protocol.
Go-ipfs is the main reference implementation of the IPFS
protocol [22]. Besides being able to run a full IPFS node,
go-ipfs can used also as an application to control the node.
Naming system
Self-certified naming system inspired by SFS
Data Structure
Merkle DAG with versioning inspired by Git
Data Exchange
BitSwap protocol inspired by BitTorrent
Based on Kademlia DHT
libp2p stack
go-ipfs, js-ipfs
Overview of the IPFS Architecture
Applications built on IPFS
Fig. 1. Overview of the IPFS architectural stack. [17], [22]
A. Existing IPFS Mobile Applications
For iOS or Sailfish OS there are no known IPFS applications
while there is an Android IPFS mobile application called
IPFSDroid [25], targeted primarily for developers. IPFSDroid
ships with a full go-ipfs binary and runs go-ipfs as a separate
daemon next to the application.
The software architecture used in the IPFSDroid application
has many drawbacks. Handling the IPFS daemon as a separate
process on a mobile device is complicated as the main
application becomes responsible for the daemon process. In
Property IPFS Dat Swarm
Initial Release 2014 2013 2016
Protocol Implementations Go (reference implementation),
JavaScript Go
Community Size Medium, 100+ contributors Small, about 100 contributors Large, hundreds of contributors
Implementation Maturity Alpha, latest reference
implementation version 0.4.17
Stable, latest version 13.11.4 Alpha (proof-of-concept), latest
version 0.3
addition, the daemon starts a separate HTTP server. The
application uses the HTTP interface provided by this server
to access the IPFS. This adds extra overhead to all operations
since the files must be transferred over HTTP to the IPFS
daemon. On a mobile device this approach is sub-optimal and
makes the application architecture complicated.
B. Operating System Selection
The operating system for which the application is imple-
mented may limit the functionality of the application. This
is true especially for the background execution requirement.
More importantly, also the the flexibility of the platform must
be considered from the application development point of view.
In this comparison it is assumed that an interface to IPFS
is provided via a shared library. Due to these reasons, three
different mobile operating systems were selected as candidates:
Android, iOS and Sailfish OS.
Java is the main programming language of Android applica-
tions. Android allows also low level application development in
C++. This makes it possible to use external shared libraries via
the C++ code. However, in the end a C++ application would
need a bridge to Java code to be able use the normal Android
application programming interfaces.
On iOS applications can be developed in Objective-C which
makes it possible to link a shared library directly with the
application [26]. Running long or indefinite background tasks
is not allowed in iOS. Consequently, application with a IPFS
node would most likely lead to rejection from the application
Sailfish OS uses C++ as the main programming language
[27]. Therefore, shared libraries are supported natively by
the environment. Sailfish OS allows indefinite execution of
background tasks: all started applications run in the background
unless explicitly closed.
Both Android and iOS could be used to implement the IPFS
application but the application development and distribution
would likely require much more work than on Sailfish OS.
Additionally, Sailfish OS has a special focus on openness and
user privacy [27]. These aspects align better with the mission
of IPFS than the other two systems which depend heavily on
massive centralized organizations.
C. Sailfish OS
Sailfish OS is a mobile operating system developed by Jolla
[27]. Version 1.0 of the operating system was released in 2013.
Sailfish OS has been actively developed since: the latest version
of the operating system is released in September 2018.
Sailfish OS is based on Linux kernel and resembles many
desktop GNU/Linux distributions [27]. Despite being a mobile
operating system it can be run on a variety of devices including
desktop systems. The Linux kernel of different Sailfish OS
mobile devices is usually based on a device specific Android
kernel. In practice, most of the mobile devices which run
Sailfish OS have been originally Android devices. Sailfish
OS has been ported on these devices by hardware adaptation
work done by Jolla or community members. A separate glue-
layer between Android-specific device drivers and Sailfish OS
makes it possible the reuse the Android drivers in Sailfish
OS. Sailfish OS can also run Android applications through a
separate proprietary Android runtime. On top of these stacks
there is a proprietary Sailfish user interface layer. The native
applications and user interfaces are developed with cross-
platform framework Qt by combining C++ and Qt modeling
language (QML).
For the purposes of this work, Sailfish OS can be seen to be
the best platform for the IPFS application implementation. The
following aspects of the operating system and the application
development environment were considered to be better on
Sailfish OS than on Android and iOS:
True multitasking support. Running applications are killed
only in the rare case of out-of-memory event.
Applications are programmed with C++. A go-ipfs based
shared library can be used directly from C++ without
extra software layers.
Native access to full GNU/Linux system and terminal
without rooting or jailbreaking the device. This makes
system metrics monitoring straightforward.
Access to many command line applications which would
be hard to come by in the other two operating systems.
In this Section, we describe the implementation of the mobile
file sharing application, its architecture, and how we come up
with its minimum viable product [28].
A. Requirements
We identified six requirements for the system:
The application can start/stop a fully working IPFS node.
The application is able to run in the background while
other applications are running.
The application can display basic information about the
node and its status in the user interface.
The application user interface can be used to change
basic settings of the node.
The application user interface allows adding content to
IPFS and retrieving content from IPFS.
The application provides a file system style interface for
managing the added files.
B. Overview of the Architecture
The file sharing application architecture was designed
keeping in mind the fact that the application will be running on
a mobile device with restricted resources. Running a separate
go-ipfs based on daemon is suboptimal and impractical ap-
proach in mobile environments. Additionally, shipping multiple
executables in an application package to the official Sailfish
OS application store is not allowed.
Instead of interfacing with a separate daemon process we
interface the application directly with go-ipfs via a separate
wrapper library. In addition to easier application packaging,
the direct integration also removes any overhead caused by the
HTTP server interface of the go-ipfs daemon. The resulting
library is not Sailfish OS specific: if needed, the library can
be used also in other operating systems in the future.
The high level overview of the architecture can be seen in
Figure 2. The resulting IPFS client application was named as
Asterism. The go-ipfs wrapper library is called as Lipipfs and
it is embedded to the application package. Together, these two
programs form the full application package.
Sailfish OS
Application package
System Libraries
Go runtime
Fig. 2. Overview of the file sharing application architecture.
C. Mobile Client Application
The application utilizes Libipfs
to provide a user interface
for sharing files and interacting with the IPFS. Asterism was
written for Sailfish OS in C++ and QML with the Qt framework
based on the system requirements identified before.
The user interface of Asterism consists of four main views.
The first view allows to view basic information of the IPFS
node and makes it possible to start and stop the node. The
second view provides an interface to the mutable file system
(MFS) with the possibility to add files to the IPFS. The added
files are pinned automatically. The MFS can be browsed like a
regular file system. Additionally, new directories can be created.
Screenshots of these views can be seen in Figure 4.
The third view includes a listing of the currently connected
peers. The list includes the node identifier and address for each
peer. Peer count could be limited via go-ipfs configuration file.
Asterism does not provide user interface for changing the peer
limit values.
The last view is the settings view. In the settings view user
can change the mode of the IPFS node from full DHT mode to
client only mode. This mode determines how the DHT works.
In the client only mode the node does not serve requests to
the rest of the network and should limit the network usage of
the node to some extent.
In the settings view there are also settings for maximum
repository size and manual garbage collection. The repository
size limits the disk space used by the IPFS. Garbage collection
allows to remove all unused or cached resources from the
repository manually. An example of this kind of content are
unpinned files. The garbage collections is also run periodically
by the go-ipfs and when the maximum disk usage limit is
approaching. Screenshots of the peers and settings views can
be seen in Figure 5.
Special actions, such as stopping or starting the node, can
be accessed via the pulley menu at the top of the screen. It
is a part of Sailfish OS user interface paradigm and can be
accessed by pulling the screen down.
Asterism IPFS File Add Sequence
Fig. 3. File sharing application file add sequence diagram.
Asterism uses the exported functions of Libipfs to interact
with the IPFS. An example of the file add sequence is visualized
Fig. 4. Asterism info and MFS views. Fig. 5. Asterism peers and settings views.
in the Figure 3. The add function and most of the other
exported functions are run in the background as goroutines.
These asynchronous operations are presented in the sequence
diagram by the goroutine bounding box.
To add a file to the IPFS, Asterism passes a file path to
Libipfs add function which will in turn add the file to the
IPFS with the help of go-ipfs. The return value of the file add
operation is a hash identifier of the file contents. Effectively
this means that the filename information has been lost during
the operation.
Asterism uses the MFS implementation of go-ipfs to preserve
the filenames and to provide a file system like interface to
the added files. In practice, an entry by the original name of
the file is created to the MFS by copying the hash which was
returned from the add operation to the MFS. After the copy
operation has been finished the MFS contents are refreshed by
fetching the latest file listing from go-ipfs.
During the development we paid a special attention in apply-
ing the most appropriate mobile and cloud-native architectural
patterns [29] and avoid anti-patterns [30], [31].
In this Section, we focus on the evaluation of the file sharing
To answer to the research question, the application per-
formance was measured on several Sailfish OS based mo-
bile devices. The performance measurements include battery
consumption and network usage measurements. Additionally,
the general functionality and usability of the application is
A. Measurements
Capabilities of mobile devices are much more limited than
normal desktop computers. P2P applications have a continuous
need for data exchange caused by the data lookups and changes
in the network routing. This will have an effect on the network
usage: a P2P application will use network more actively than
a normal centralized network architecture based application.
Consequently, active network usage will most likely have a
negative effect on the battery life of a device. Therefore, both
the battery consumption and network usage were measured
while the file sharing application was running on a mobile
device. With these measurements it can be evaluated is it
worthwhile to run a P2P application on a mobile device.
The measurements were done on official Sailfish OS
version It was the latest available version when
the measurements were performed. The go-ipfs version used
by the Asterism file sharing application was 0.14.7. During
measurements the Android support layer of the Sailfish OS
was turned off to avoid possible measurement bias caused by
the additional power consumption of the layer.
The battery consumption measurements were done on three
different devices. As reported in Table II, the devices fall
into different categories, also considering their price point and
features. All three devices have been released during a timespan
of one year in 2015 and 2016. Two of the devices are mobile
phones and one of them is a tablet.
The first device, Sony Xperia X, is the latest and most
powerful of the devices. It can be seen as a mid-range device
which represents most of the commonly used mobile phones.
The second device is the Jolla Tablet. The tablet was selected
for measurement to get samples also from a device which is not
a mobile phone. On the tablet measurements were done only on
WLAN interface because the tablet has no cellular connectivity.
The last device, Jolla C, is a low-end mobile phone with a less
powerful processor than the two other devices. Jolla C is also
known as rebranded Intex Aqua Fish device.
1) Power Consumption: The power consumption measure-
ments were executed in multiple different configurations.
IPFS node was run in full DHT mode or in client only
mode. Additionally, the IPFS modes were combined with
Property Sony Xperia X Jolla C Jolla Tablet
Release Date 2016, February 2016, May 2015, July
Chipset Qualcomm MSM8956 Snapdragon
Qualcomm MSM8909v2
Snapdragon 212
Intel Atom Z3735F
Central Processing Unit (CPU)
4 x 1,4 GHz Cortex-A53 & 2 x 1,8
GHz Cortex-A72
4 x 1,3 GHz Cortex-A7 4 x 1,8 GHz
Battery 2620 mAh 2500 mAh 4450 mAh
Network Interfaces GSM / HSPA / LTE & WLAN
(Wi-Fi 802.11 a/b/g/n/ac,
(Wi-Fi 802.11 b/g/n)
WLAN (Wi-Fi 802.11 a/b/g/n,
Talk Time 19 h 20 h N/A
different network combinations: both 4G and WLAN enabled,
only WLAN enabled and only 4G enabled. The idle power
consumption was measured for all devices while all network
interfaces were enabled and no applications were running.
During all measurements the screen of the device was turned
off. No content was added to the IPFS and no content was
downloaded from the IPFS before or during the measurements.
The power consumption was measured with Charge Monitor
application available in the official Sailfish OS applications
store. The application is able to log the battery level of the
device into a log file. All measurements were started from
a battery level of 100 %. Battery levels were logged for 4
hours. A linear regression line was fitted to the obtained data
points. With the fitted line the battery life of the device can be
estimated with a reasonable accuracy. The estimated battery
life in the next paragraphs have been rounded to 10 minutes
accuracy and the percentage differences in 5 % accuracy.
B. Results
The firsts two figures, 7 and 8, show measurements which
were done on the mobile phones when all network interfaces
were enabled. The idle consumption of the devices is also
included in these two figures. The battery of the Xperia X is
estimated to last about 780 minutes in full DHT mode and
about 850 minutes in client only mode. For Jolla C the same
numbers are 620 minutes and 710 minutes.
Both devices have similar power consumption trends. The
idle power consumption is low which is also expected because
no applications were running. The difference between the
battery life of the devices is large. On full DHT mode the
battery of the Xperia X lasts significantly longer than Jolla C’s.
Similarly, Xperia X performance is better than Jolla C’s when
the IPFS node is run in the client only mode.
The difference in power consumption between the DHT
modes on the both devices is noticeable. On Xperia X the
client only mode adds about 10 % more battery life when
compared to the full DHT mode. On Jolla C the change is
a bit larger, about 15 %. As the estimated battery lives are
better than in the 4G only figures and worse than in WLAN
only figures, IPFS node has probably defaulted to the WLAN
interface during the measurements.
The next three figures, 9, 10 and 6, are WLAN only
measurements. For Xperia X, the estimated battery life in
full DHT mode is 880 minutes and in client only mode 1080
minutes. For Jolla C the estimations are 720 minutes in full
DHT mode and 1020 in client only mode. For the Jolla Tablet
the numbers are 720 minutes and 820 minutes.
The battery lives of the Xperia X and Jolla C are longer on
WLAN only when compared to the measurements where both
WLAN and 4G were enabled. The percentage changes between
the DHT modes are about 20 % on Xperia X, 40 % on Jolla C
and 15 % on Jolla Tablet. The Tablet results are similar with
the two mobile phones. However, the results indicate that the
WLAN interface of the Tablet is less energy efficient because
it should last longer given the capacity of the battery.
0 100 200 300 400 500 600 700 800 900
Time (min)
Battery level (%)
Battery Consumption, Jolla Tablet, WLAN
y=0.0140 x+ 99.9321
y=0.1399 x+ 100.151
y=0.1222 x+ 99.7254
IPFS Client Only
Fig. 6. Jolla Tablet WLAN battery consumption.
The last set of power consumption measurements were done
on 4G interface only. The results of these measurements are in
figures 11 and 12. For the 4G only measurements, the estimated
battery life for Xperia X is 420 minutes in full DHT mode
and 430 minutes in client only mode. For Jolla C the same
numbers are 420 minutes and 440 minutes.
The 4G only results have close to none difference between
the different DHT modes. Running IPFS node on 4G clearly
consumes much more power than when using only WLAN.
Both devices perform very similarly on these measurements:
battery life on both devices is approximately the same. The
WLAN interface is far more energy efficient than 4G on both
1) Network Usage: The network usage measurements were
done only on Xperia X. Network usage was measured in full
DHT mode and client only mode with Nethogs [32] traffic
monitoring tool. Both networking interfaces, WLAN and 4G,
were turned on because it is the most likely default setup during
common mobile phone use. After Asterism had been started
Nethogs was run for 140 minutes. The total sent and received
data was logged to a log file in MB every 10 seconds
The results of the measurements are presented in Figure 13
and 14. Asterism downloaded in both modes approximately the
same amount of data. Client only mode reduced the sent data
about 30 %. The amount of the downloaded and uploaded data
is very large. The application downloaded close to 800 MB in
140 minutes in both modes. Upload numbers were about 440
MB full DHT mode and about 300 MB in client only mode.
The networking layer used in go-ipfs was able to bypass
Network Access Translation (NAT) and possible firewalls of
the cellular network operators. This was confirmed by adding
previously unknown content to the IPFS while running only on
4G. After this the content could be downloaded from a public
IPFS gateway indicating that go-ipfs can upload content through
cellular networks to the other nodes of the P2P network.
C. Discussion
The analysis and discussion in this section is based on the
results in Section
. The results indicate that running a
full IPFS P2P network node on mobile devices is possible.
However, the node causes large amounts of network traffic and
affects negatively to the battery life of the device.
It is important to notice that no content was downloaded
or uploaded during the measurements. All network traffic was
caused by the chattiness of the IPFS protocol. DHT routing
updates cause some of this traffic and it is likely that the IPFS
Bitswap protocol is also responsible partly for the traffic. The
amount of network traffic increases if a node downloads or adds
some popular content and thus participates in the distribution
of that content. This behavior is caused by the data exchange
protocol which is similar to BitTorrent.
The go-ipfs implementation is not mature and there is a
lot of room for optimization. On a mobile device the amount
of traffic caused by the IPFS node is not acceptable in most
cases due to the monthly upper traffic limits on mobile network
subscriptions. Setting the DHT mode to client only has only
minimal effect to the amount of the sent data. Therefore,
traffic limit setting should be built to the IPFS protocol
implementations to avoid excessive bandwidth usage.
Due to the constant network traffic the device can never enter
to deep sleep mode. In the idle measurements the deep sleep
behavior could be observed. The battery level logs contained
longer gaps because the values were logged only when the
device periodically briefly woke up to perform some tasks. The
constant network traffic caused by the IPFS node prevents the
device from entering to the deep sleep mode. Consequently,
this behavior also prevents constant churn caused by the
disconnections despite affecting negatively to the battery life.
The measurements were done on a stable environment. The
devices were located close to a cellular tower and a WLAN
router. Device movement and connection quality would most
likely have an additional negative effect to the battery life.
Additionally, mobile devices are usually used also for other
tasks. Browsing the web or playing games while the IPFS node
is running would consume the battery even faster.
The mobile BitTorrent measurements done by Nurminen et
al. [9] had similar results when compared to our results. Client-
only mode reduced the power consumption and the cellular
network interface was less energy efficient than WLAN. The
power consumption was on the same level with phone calls
when run on 3G. In contrast, Asterism consumed more power
than phone calls: the results indicate that on 4G the battery life
is about one third of the talk time of the Xperia X and Jolla
C. However, on 3G connection Nurminen et al. performed the
measurements only for content download since the BitTorrent
implementation could not bypass NAT and firewalls of cellular
operators. Due to this, the results are not directly comparable.
Asterism was able to upload previously unknown content
through the cellular network connection. This is an important
finding: if the mobile node is not able to upload new content
on cellular networks, the node cannot act as a full peer and
only consumes the resources of the rest of the network. While
the client only mode can be desirable due to the bandwidth and
battery life savings the negative effect must be also considered.
If a large amount of mobile client only IPFS nodes were to
suddenly to join the IPFS, the network would not likely perform
as well as before.
In this work we examined the possibility to transform mobile
devices into decentralized content delivery network without
any central servers or authorities by implementing a peer-to-
peer mobile file sharing application and measuring how the
application affects to the performance of the mobile device. We
implemented the application based on the Sailfish operating
system and on the InterPlanetary File System.
The file sharing application was developed in two phases. In
the first phase a wrapper library was written for the reference
implementation of the InterPlanetary File System. With this
approach a separate daemon process was avoided. In the second
phase the shared library was utilized in the implementation of
the mobile file sharing application. The application provides an
easy to use user interface to the peer-to-peer file system. The
user interface makes it possible to manage the added content
in a way similar to common file system browsers. Additionally,
the application can show basic information about the node and
peer nodes as well as to control some settings of the node.
The network usage and the power consumption of the
application was measured on three different devices. Two of
the devices were mobile phones and one of them was a tablet.
No content was added or fetched from the network during the
measurements. All devices were able to run the application
without problems. The application was able to upload content
not only via WLAN but also through cellular connection.
The results show that the application consumed large
amounts of network bandwidth. The traffic was caused by
the chattiness of the peer-to-peer network protocol. Distributed
hash table routing updates and the BitSwap protocol of the
InterPlanetary File System are the most likely causes for the
excessive bandwidth usage. When the distributed hash table
routing mode was changed to client only mode the amount of
the sent data was reduced by about 30 %.
Due to the constant network traffic the devices could never
enter to deep sleep mode. This led to large power consumption.
On WLAN interface the battery of the measured devices was
estimated to last about 720 to 880 minutes depending on device.
When the distributed hash table routing mode was changed to
client only mode the devices gained 15 to 40 % more battery
life. When run on 4G interface only the estimated battery life
dropped down to 420 minutes on both mobile phones which
is about one third of the estimated talk time of the phones.
Client only routing mode had negligible effect on the battery
life when the application was run only on 4G connection.
The amount of bandwidth consumed by the application is
too excessive for continuous usage due to the data limits in
usual mobile network data subscriptions. With a unlimited data
subscription the application could be run constantly given that
a user accepts greatly degraded battery life. The application
could be also highly beneficial for phones used as edge devices,
always connected to a power source.
Therefore, decentralized solutions could be potentially used
in the future to replace centralized clouds and servers on mobile
devices. However, for mainstream use cases the InterPlanetary
File System needs network usage optimizations or bandwidth
limits. Another future works will be on the implementation of
the distributed file-system based on Ethereum [33] or based
on a decentralized microservices architecture [34].
“Cisco global cloud index: Forecast and methodology,
20162021,” Cisco, White Paper, 2018. [Online]. Avail-
global-cloud- index-gci/white-paper-c11-738085.pdf
P. De Filippi and S. McCarthy, “Cloud computing: Centralization and
data sovereignty,European Journal for Law and Technology, vol. 3,
no. 2, 2012. [Online]. Available:
M. Rosenberg, N. Confessore, and C. Cadwalladr, “How trump
consultants exploited the facebook data of millions,” New York
Times, 2018. [Online]. Available:
us/politics/cambridge-analytica- trump-campaign.html
R. Schollmeier, “A definition of peer-to-peer networking for the classi-
fication of peer-to-peer architectures and applications,” in Int. Conf on
Peer-to-Peer Computing. IEEE, August 27–29 2001, pp. 101–102.
M. Halpern, Y. Zhu, and V. J. Reddi, “Mobile cpu’s rise to power:
Quantifying the impact of generational mobile cpu design trends on
performance, energy, and user satisfaction,” in Int. Symposium on High
Performance Computer Architecture (HPCA). IEEE, March 12–16 2016,
pp. 64–76.
G. Fettweis and S. Alamouti, “5g: Personal mobile internet beyond what
cellular did to telephony,” IEEE Communications Magazine, vol. 52,
no. 2, pp. 140–145, 2014.
M. Matuszewski, N. Beijar, J. Lehtinen, and T. Hyyrylainen, “Under-
standing attitudes towards mobile peer-to-peer content sharing services,
in Int. Conf. on Portable Information Devices. IEEE, 2007, pp. 1–5.
M. V. Heikkinen, A. Kivi, and H. Verkasalo, “Measuring mobile peer-
to-peer usage: Case finland 2007,” in Int.Conf. on Passive and Active
Network Measurement. Springer, 2009, pp. 165–174.
J. Nurminen and J. Nyrnen, “Energy-consumption in mobile peer-to-peer-
quantitative results from file sharing,” in Consumer Communications and
Networking Conf. IEEE, 2008, pp. 729–733.
A. Bori and P. Ekler, “The analysis of bittorrent protocol reliability in
modern mobile environment,” in Eastern European Regional Conf. on
the Engineering of Computer Based Systems. IEEE, 2013, pp. 120–126.
P. Ekler, I. Kel
enyi, I. D
evai, B. Bakos, and A. Kiss, “Hybrid peer-to-peer
content sharing in mobile networks.” JNW, vol. 4, no. 2, pp. 119–132,
K. Csorba, P. Ekler, and I. Kel
enyi, “Analyzing content life cycle in
mobile content sharing environment,” in East. European Conf. on the
Engineering of Computer Based Systems (ECBS-EERC). IEEE, 2011.
P. Ekler and K. Csorba, “The usage and behavior patterns of mobile
bittorrent clients,” Journal of Advanced Computational Intelligence and
Intelligent Informatics, vol. 18, no. 3, pp. 320–323, 2014.
S. Gurun, P. Nagpurkar, and B. Y. Zhao, “Energy consumption and
conservation in mobile peer-to-peer systems,” in Int. Ws.on Decentralized
resource sharing in mobile computing and networking. ACM, 2006,
pp. 18–23.
F. Chowdhury, J. Furness, and M. Kolberg, “Performance analysis of
structured peer-to-peer overlays for mobile networks,Int. Journal of
Parallel, Emergent and Distributed Systems, vol. 32, no. 5, pp. 522–548,
M. A. Khan, L. Yeh, K. Zeitouni, and C. Borcea, “Mobistore: A system
for efficient mobile p2p data sharing,Peer-to-Peer Networking and
Applications, vol. 10, no. 4, pp. 910–924, 2017.
J. Benet, “Ipfs-content addressed, versioned, p2p file system,” arXiv
preprint arXiv:1407.3561, 2014.
[18] M. Ogden, “Distributed dataset synchronization and versioning,” 2017.
“Swarm,” Swarm, 2018. [Online]. Available:
[20] “Git,” Git, 2018. [Online]. Available:
[21] “Ethereum project.” [Online]. Available:
[22] “Ipfs github.” [Online]. Available:
[23] “Dat github project.” [Online]. Available:
[24] “Go programming language.” [Online]. Available:
[25] “Ipfsdroid.” [Online]. Available:
[26] 2018. [Online]. Available:
[27] “Sailfish os,” Jolla, 2018. [Online]. Available:
V. Lenarduzzi and D. Taibi, “Mvp explained: A systematic mapping study
on the definitions of minimal viable product,” in Euromicro Conference
on Software Engineering and Advanced Applications (SEAA), Aug 2016,
pp. 112–119.
D. Taibi, V. Lenarduzzi, and C. Pahl, “Architectural patterns for microser-
vices: A systematic mapping study,” in 8th International Conference on
Cloud Computing and Services Science (CLOSER), 2018, p. 8.
D. Taibi, V. Lenarduzzi, and C. Pahl, “Processes, motivations,
and issues for migrating to microservices architectures: An empirical
investigation,IEEE Cloud Computing, vol. 4, no. 5, pp. 22–32, Sep.
D. Taibi and V. Lenarduzzi, “On the definition of microservice bad
smells,” IEEE Software, vol. 35, no. 3, pp. 56–62, May 2018.
“Nethogs,” 2018. [Online]. Available:
V. Lenarduzzi, M. I. Lunesu, M. Marchesi, and R. Tonelli, “Blockchain
applications for agile methodologies,” in 19th International Conference
on Agile Software Development (XP2018).
R. Tonelli, M. Lunesu, A. Pinna, D. Taibi, and M. M., “Implementing a
microservices system with blockchain smart contracts,” in 2019 IEEE
International Workshop on Blockchain Oriented Software Engineering
(IWBOSE) - Colocated with SANER 2019.
Fig. 7. Battery Consumption, Xperia X, 4G and WLAN
0 100 200 300 400 500 600 700 800
Time (min)
Battery level (%)
Battery Consumption, Jolla C, 4G and WLAN
y=0.0216 x+ 99.1920
y=0.1573 x+ 97.2996
y=0.1366 x+ 97.6034
IPFS Client Only
Fig. 8. Battery Consumption, Jolla C, 4G and WLAN
Fig. 9. Battery Consumption, Xperia X, WLAN
Fig. 10. Battery Consumption, Jolla C, WLAN
Fig. 11. Battery Consumption, Xperia X, 4G
Fig. 12. Battery Consumption, Jolla C, 4G
Fig. 13. Network traffic in full DHT mode.
Fig. 14. Network traffic in client only mode.
... Specifically, we focus on IPFS [12], Swarm [13], the Hypercore Protocol [14], SAFE [15], Storj [16], and Arweave [17]. In particular, IPFS has gained popularity as storage layer for blockchains [18,19,20,21,22,23,24] and was subject of a series of studies [25,26,27,28,29,30,31,32,33,34]. Furthermore, we put our overview of these systems in context to preceding systems and research directions, namely Bit-Torrent, information-centric networking, and blockchains. ...
... IPFS is a popular research topic. Next to investigation of possible use case for IPFS, IPFS is also investigated [25,26,27,28,29,30,31,32,33,34], with researchers analyzing performance and efficiency of the system. V. RELATED P2P DATA NETWORKS Next to IPFS, many data networks are in development. ...
... There exist other research analyzing the performance of IPFS, e.g., the read and write latency [26,29], using IPFS cluster for Internet of Things data sharing [27], improving the system [28,34], or analyzing the network [32,33]. Heinisuo et al. [30] showed that IPFS needed improvement to be used on mobile device due to high network traffic draining the battery. Research concerning IPFS's competitors is lacking. ...
Decentralized, distributed storage offers a way to reduce the impact of data silos as often fostered by centralized cloud storage. While the intentions of this trend are not new, the topic gained traction due to technological advancements, most notably blockchain networks. As a consequence, we observe that a new generation of peer-to-peer data networks emerges. In this survey paper, we therefore provide a technical overview of the next generation data networks. We use select data networks to introduce general concepts and to emphasize new developments. We identify common building blocks and provide a qualitative comparison. From the overview, we derive future challenges and research goals concerning data networks.
... Furthermore, they enable additional benefits like low latency, cheap cost, and the complete removal of confidence in a third party [1]. Another critical issue with such centralized storage of documents is the privacy of users as these documents may contain a lot of personal information, and their leak due to a data breach can be utilized to launch phishing attacks on the individuals [2]. ...
Conference Paper
Document verification is the first step whenever we enter any organization or institute. In any organization, it is essential to track, verify, and check the person's background who will become a part of the organization. This process is very time-consuming and hectic for both parties involved. Various governments provide cloud-based digital locker services for the citizens storing the public document on a centralized server. But due to its centralized nature, this type of service is weak against information breaches and Denial of Service (DoS) attacks. Also, there are some privacy concerns with such centralized digital locker services as the stored documents may contain users' crucial personal information. This paper proposes a blockchain-based digital locker in a decentralized application using Ethereum Blockchain to securely store personal documents with high availability. The proposed solution also verifies documents with ease, confidentiality, access control, data privacy, authenticity, and maintaining the integrity of documents.
... Using IPFS, users can access their files from IPFS nodes where they are encrypted and stored, while the fingerprints of the files are stored in blockchain ledger for verification [69][70][71][72][73][74]. ...
Full-text available
Background: Blockchain technology is a distributed electronic ledger containing digital records, transactions or events that are protected with advanced encryptions, extremely hard to tamper, and updateable through a consensus algorithm agreeable to all connected network nodes. In Sub-Sahara Africa, the technology has started to be adopted in real estate, supply chain, agriculture, and financial sector. Unfortunately, there is a lack of effort in introducing this technology in the healthcare sector. Therefore, this study aims to explore the issues facing electronic healthcare systems in Sub-Sahara Africa taking Tanzania as a case study and introduce blockchain-based solutions for the discovered issues. Methods: The study used qualitative methods for data collection and analysis. Data were collected through interviews, observation and documentary analysis. Interviews were done with the sample size of 50 participants who were selected from groups of healthcare facility leaders, ICT experts, government representatives, doctors, nurses, laboratory technicians, pharmacists, accountants, and receptionists. Direct observation and participatory observation were used to assess different electronic healthcare records systems' functions. Moreover, researchers used document analysis to collect data from public records (like policy manuals), personal documents (like incident reports), and physical evidence (like training materials and handbooks). NVivo 11 software was applied in managing and organizing data analysis. Results: Out of 710 healthcare facilities involved in this study, 34.5% fully implemented electronic healthcare records systems and 78% installed Mfumo wa Taarifa za Uendeshaji Huduma za Afya (MTUHA) also known as (District Health Information Software (DHIS) II). The findings showed that the issues facing electronic healthcare records are; difficulties in taking care of the patients' private information, problems in safely sharing medical information between healthcare facilities, bandwidth issues, and improper handling of data integrity. Conclusion: The existing issues facing electronic healthcare records systems can be tackled through blockchain based solutions like self-sovereign identity and sharing and storing patients' medical data securely in blockchain ledgers and interplanetary file system. Therefore, healthcare facilities owners are recommended to use the findings of this study to elucidate the existing issues.
Decentralized, distributed storage offers a way to reduce the impact of data silos as often fostered by centralized cloud storage. While the intentions of this trend are not new, the topic gained traction due to technological advancements, most notably blockchain networks. As a consequence, we observe that a new generation of peer-to-peer data networks emerges. In this survey paper, we therefore provide a technical overview of the next generation data networks. We use select data networks to introduce general concepts and to emphasize new developments. Specifically, we provide a deeper outline of the Interplanetary File System and a general overview of Swarm, the Hypercore Protocol, SAFE, Storj, and Arweave. We identify common building blocks and provide a qualitative comparison. From the overview, we derive future challenges and research goals concerning data networks.
Conference Paper
Full-text available
Blockchain technologies and smart contracts are becoming mainstream research fields in computer science and researchers are continuously investigating new frontiers for new applications. Likewise, microservices are getting more and more popular in the latest years thanks to their properties, that allow teams to slice existing information systems into small and independent services that can be developed independently by different teams. A symmetric paradigm applies to Smart Contracts as well, which represent well defined, usually isolated, executable programs , typically implementing simple and autonomous tasks with a well defined purpose, which can be assumed as services provided by the Contract. In this work we analyze a concrete case study where the microservices architecture environment is replicated and implemented through an equivalent set of Smart Contracts, showing for the first time the feasibility of implementing a microservices-based system with smart contracts and how the two innovative paradigms match together. Results show that it is possible to implement a simple microservices-based system with smart contracts maintaining the same set of functionalities and results. The result could be highly beneficial in contexts such as smart voting, where not only the data integrity is fundamental but also the source code executed must be trustable.
Conference Paper
Full-text available
We present an application of Blockchain technology and Smart Contracts to the management of Agile projects, using Scrum or Lean-Kanban processes. In our application the duties of the Product Owner for certifying the correctness of the outcomes are delegated to one or more Smart Contracts deployed on the Ethereum Blockchain and written in Solidity. An agreement with the Customer can also allow the Smart Contracts to automatically enable payments, to introduce penalties or grants on the basis of the outcome. Product Owner duties and work can thus be relieved allowing to allocate resources on more proï¿¿table and productive tasks. Other possibilities are examined as well.
Full-text available
Code smells and architectural smells (also called bad smells) are symptoms of poor design that can hinder code understandability and decrease maintainability. Several bad smells have been defined in the literature for both generic architectures and specific architectures. However, cloud-native applications based on microservices can be affected by other types of issues. In order to identify a set of microservice-specific bad smells, researchers collected evidence of bad practices by interviewing 72 developers with experience in developing systems based on microservices. Then, they classified the bad practices into a catalog of 11 microservice-specific bad smells frequently considered harmful by practitioners. The results can be used by practitioners and researchers as a guideline to avoid experiencing the same difficult situations in the systems they develop.
Conference Paper
Full-text available
Microservices is an architectural style increasing in popularity. However, there is still a lack of understanding how to adopt a microservice-based architectural style. We aim at characterizing different microservice architectural style patterns and the principles that guide their definition. We conducted a systematic mapping study in order to identify reported usage of microservices and based on these use cases extract common patterns and principles. We present two key contributions. Firstly, we identified several agreed microservice architecture patterns that seem widely adopted and reported in the case studies identified. Secondly, we presented these as a catalogue in a common template format including a summary of the advantages, disadvantages, and lessons learned for each pattern from the case studies. We can conclude that different architecture patterns emerge for different migration, orchestration, storage and deployment settings for a set of agreed principles.
Full-text available
Microservices have been getting more and more popular in recent years, and several companies are migrating monolithic applications to microservices. Microservices allow developers to independently develop and deploy services, and ease the adoption of agile processes. However, many companies are still hesitant to migrate because they consider microservice as a hype or because they are not aware of the migration process and the benefits and issues related to migration. For this purpose, we conducted a survey among experienced practitioners who already migrated their monoliths to microservices. In this paper, we identify a process framework based on the comparison of three different migration processes adopted by the interviewed practitioners, together with the common motivations and issues that commonly take place during migrations. In this work, we describe the results and provide an analysis of our survey, which includes a comparison of the migration processes, a ranking of motivations, and issues and some insights into the benefits achieved after the adoption. Maintainability and scalability were consistently ranked as the most important motivations, along with a few other technical and non-technical motivations. Although return on investment was expected to take longer, the reduced maintenance effort in the long run was considered to highly compensate for this.
Full-text available
MobiStore is a P2P data store for decentralized mobile computing, designed to achieve high availability and load balance. As P2P platforms, mobile devices connected to the Internet through WiFi or cellular networks are different from wired devices in two main aspects: (1) higher churn due to mobility, weak wireless signals, or battery constraints, and (2) significant variability in bandwidth and latency based on the point of attachment. These problems affect the stored content availability and skew the content serving load over the peers. MobiStore structures the mobile P2P network into clusters of redundant peers. The topology uses both algorithmically-defined and random edges among the peers of different clusters. The routing information is updated using a gossip-based protocol. Thus, MobiStore achieves, with high probability, O(1) lookup operations despite high churn and link variability. Inside the clusters, all peers replicate the content, which improves the content availability. Furthermore, based on the current load, MobiStore dynamically changes the number of peers inside the clusters and routes content request to randomly selected peers. These two dynamic techniques along with using consistent hashing to map content to peers balance the load over the peers. While some of these techniques are well known, the main contribution is on the novel ways of applying them to design and implement an efficient mobile P2P data store. Simulation results show MobiStore achieves an availability, i.e., lookup success rate, between 12–48 % higher than two baseline systems built over the MR-Chord and Chord P2P protocols; and it reduces the latency up to 9 times compared to these protocols. Finally, the results show MobiStore adapts to churn and workload to evenly distribute the requests across clusters and peers better than both baseline solutions.
Distributed Hash Table (DHT) based Peer-to-Peer (P2P) overlays have been widely researched and deployed in many applications such as file sharing, IP telephony, content distribution and media streaming applications. However, their deployment has largely been restricted to fixed, wired networks. This is due to the fact that supporting P2P overlays on wireless networks such as the public mobile data network is more challenging due to constraints in terms of data transmissions on cellular networks, limited battery power of the handsets and increased levels of node churn. However, the proliferation of smartphones makes the use of P2P applications on mobile handsets very desirable. In this article, we have analysed and evaluated the performance and efficiency of five popular DHT based structured P2P overlays (Chord, Pastry, Kademlia, Broose and EpiChord) under conditions as commonly experienced in public mobile data networks. Our results show that the conditions in mobile networks, including a high churn rate and the relatively low bandwidth availability is best matched by Kademlia and EpiChord. These overlays exhibit a high lookup success ratio and low hop count while consuming a moderate amount of bandwidth. These characteristics make these two overlays suitable candidates for use in mobile networks.
With the many changes in mobile phone use, it is now common for users to connect to the Internet and share social and multimedia data, and peer-to-peer technology remains one of the most efficient solutions to content sharing. We analysed the lifecycle of content shared using the BitTorrent network, focusing on torrents retrieved by mobile phone clients using our MobTorrent application. MobTorrent, a complete Bit- Torrent client for feature phones, enables anonymous usage statistics to be collected. Based on statistics collected over the last three years, we analyze how mobile BitTorrent clients are being used. We discuss the success of individual sessions by additionally measuring peer connection download and success ratio statistics. This research can be considered as a pioneer work in the field of mobile content sharing solutions.