RNCDDS - RANDOM NETWORK CODED DISTRIBUTED DATA SYSTEM
Hiroshi Nishida 1 , Thinh Nguyen 2
1

ASUSA Corporation, 2 School of EECS, Oregon State University

ABSTRACT
Many Random Network Coding based storage systems havebeen proposed to increase robustness in terms of data preservation and storage efficiency. However, there are two major practical issues: (1) slow encoding and decoding speedsand (2) difficult access to the data. In this paper, RNCDDS
solves problem (1) by introducing a new and efficient Galois Field arithmetic library and problem (2) by employing
a new JavaScript program. As a result, RNCDDS is not
only theoretically more robust and storage efficient than major distributed data systems such as Hadoop (HDFS) and
GlusterFS, but also outperforms them in all speed measurements. Also, the proposed JavaScript program enables easy
data fetch through a web browser including watching a video
with an HTML5 video player and has potential for drasticallyreducing data storage amount in a cloud system or Content
Delivery Network.

Fig. 1: Hadoop splits a file into pieces and distributes theirreplications to servers.

Fig. 2: GlusterFS places replications on servers.

Index Terms— Distributed System, Data Storage, Random Network Coding, Galois Field, Multimedia Streaming,Content Delivery Network, Cloud Computing

1=3 the size of the original file to each server requires only

1. INTRODUCTION

storage for R = 2 compared to Hadoop or GlusterFS. However, current RNC based systems suffer from the following
two major issues:

Distributed data systems are widely employed in cloud computing not only to store a huge amount of data but also toassure semi-permanent data preservation. Hadoop [1], a defacto standard distributed data system in cloud computing, isused by many enterprises and serves a vast amount of datain their data centers. However, due to their simple raw data
distribution scheme, most distributed data systems do not always achieve both high robustness and storage efficiency at
the same time. For instance in a Hadoop cluster, a file is split
into some pieces and their replications are distributed to theservers as shown in Fig. 1. To guarantee the redundancy of R
servers, i.e., the retrieval of data under concurrent failure of
R servers, Hadoop requires 1 + R storage size in a cluster. In
other words to store a 1GB file, 3GB storage is necessary ina Hadoop cluster consisting of original server plus two otherfault-tolerant servers. This is also applicable to the case inwhich simple replications of the original file are placed on thestorage servers such as GlusterFS [2] (Fig. 2). On the other
hand, a distributed data system based on Random Network
Coding (RNC) that for instance distributes encoded data with

1 + R=3 storage in a cluster, which saves as much as 44%

1. The slow processing speed in encoding and decoding
2. The difficulty in access to data from clients
In our investigation, fast processing in encoding and decoding
turned out to be difficult to achieve due to lack in an efficientGalois Field (GF ) arithmetic library with a lax license (seeSec. 3 and 4). Also, users may hesitate to use dedicated client
programs employed in most RNC based systems to access theencoded data for security reasons and will prefer to watch avideo on a web browser. RNCDDS solved those issues andmade an RNC based system practical by introducing the following two programs:
1. gf-nishida-16: a new and efficient GF arithmetic library
2. RNC.js: a JavaScript program to download and decode
RNC encoded data and to play a video with an HTML5
video player
Moreover, RNCDDS is planned to be open source and will be
publicly downloadable in the future.
c ASUSA Corporation c IEEE 2017

This paper presents the architecture of RNCDDS together
with the fundamentals of RNC, a brief explanation of gfnishida-16, its advantages over the other major cloud storage
systems, and its efficiency in delivering multimedia contents.
2. RELATED WORK
Fig. 3: RNC distributes encoded data to servers, where thesize of each encoded file is approximately 1/3 of the original.

Other than Hadoop and GlusterFS, many storage systems,
such as OpenAFS [3], Ceph [4], MooseFS [5], Quantcast File
System (QFS) [6] and Pyramid Codes [7], have been proposed and we believe they play an important role in cloudcomputing. Among those systems, Hadoop, GlusterFS, OpenAFS, Ceph and MooseFS are based on non-coded data distribution, while QFS and Pyramid Codes employs coded data
distribution by Erasure Coding or similar techniques in order to increase the robustness and storage capacity efficiency.
Erasure Coding is very similar to RNC but basically limits
the number of encoded data. Therefore unlike RNCDDS, itcannot distribute as many different encoded data as possible
to servers, which restricts the usage in multimedia streaming.
RNC based storage systems are mostly proposed for used in
P2P networks [8] [9] [10] and are proved to be robust, resilientand efficient in storage capacity. However to the best of ourknowledge, there are few papers that refer to the encoding anddecoding speeds [11]. In our research, we concluded that an
RNC based storage system could not be fast enough without
an efficient GF arithmetic library (see Sec. 3).
As for multimedia streaming with RNC, many papers arefocused on the usage in P2P networks [12] [13] [14] or wireless networks [15] [16], and there are few practical systems
based on the client-server style except for [17] which introduces a unique P2P assisted client-server system. Also, there
is little information on the accessibility to RNC data, and wehave not confirmed if there is a program to decode and directly access RNC data on a web browser. To the best of
our knowledge, there is no practical RNC based multimedia
streaming system in a pure client-server style with easy accessfrom the clients.

employed by RNC. RNC splits a file into some pieces, say x1 ,x2 , x3 , and creates linear equations (encode) with randomly
generated coefficients as such as:8>< 11 1+ 12 2+ 13 3 = 1++=>: 21 1 22 2 23 3 2

x

x

x

x

x

x

x

x

x

x

x

a ; x

b

a ; x

a ; x

b

(2)

Then, each of b1 , b2 ,    is distributed to each server together
with associate coefficients as and composes one encoded fileas shown in Fig. 3. To restore the original file, we need to collect only three encoded files from any combination of threeservers and to obtain x1 , x2 , x3 by solving the system of linear equations (decoding). In other words, as long as threeservers that have the encoded files are alive in the system, theoriginal file can be regained. Therefore in Fig. 3, the cluster
guarantees the retrieval of data under the failure of any twoservers.
Also, note that the size of bn ; 8n is equal to that of x1 ,x2 , x3 (= 1/3 of the original file size) because the arithmetic
computations in (2) are executed in GF . Since the size ofas (16bits  3) is usually negligibly small compared to thatof bn , we can safely regard the size of each encoded file asalmost equal to 1/3 of the original file size. As a result, thestorage size in Fig. 3 is only 5=3 with the redundancy of twoservers, while Hadoop and GlusterFS require a size of 3 storage with the same redundancy.
The only drawback of RNC will be the computation time;creating linear equations (encoding) and solving a system of
linear equations (decoding) require certain amounts of time
especially in GF . In our development of RNCDDS, we noticed the times taken for encoding and decoding were greatly
affected by the computation speed in GF . We first started our
project with one of open source GF arithmetic libraries without considering its speed, which later turned out to be very
slow and to be impractical. We afterward employed anotheropen source library called GF-Complete [18] that focused on
the processing speed using SSE, and gained preferable results,
though it has been removed by its author due to the possible
patent infringement [19]. Using SSE for GF arithmetic computation seems to be caught on a patent. However, it encouraged us to develop an original GF arithmetic library and gave
us the idea to create gf-nishida-16.

RNC provides high robustness and storage efficiency by utilizing the characteristics of linear equations. Suppose we havethree integers x1 = 3, x2 = 1, x3 = 2 and randomly create
many linear equations such as:
x

a ; x

a ; x



3. FUNDAMENTALS OF RNC

8 2 + 5 + = 13
>
1
2
3
>
>
< 7 1 + 3 2 + 8 3 = 42
4 1 + 2 + 2 3 = 19
>
>
5
+4
+9
= 33
>
: 1 2 3

a ; x

(1)



To obtain the original x1 , x2 , x3 , we basically need only threeequations out of them, which is the fundamental technique2

Table 1: Elapsed times (ms) in multiplication and division
with GF (2n ) arithmetic libraries (the shorter, the faster).

4. GF-NISHIDA-16
Though arithmetic computation in GF is indispensable forcoded data systems, it costs expensive and therefore affects
the system performance. Moreover, some computation techniques are patented and do not allow users to easily use them.
Gf-nishida-16 [20], an open source GF (216 ) arithmetic library with a 2-Clause BSD license, resolves those issues andprovides high speed arithmetic computation in GF (216 ). Dueto space limitations, we skip the explanation on its details butnote the high speed processing in gf-nishida-16 is achievedby optimizing two step memory lookup. Please see our technical paper [21] for the full description. In this section, we
introduce its benchmark results and show its efficiency.
We measured the elapsed times for multiplication and division with the following open source GF libraries:

Library
gf-nishida-region-16
gf-complete-64
gf-nishida-8
gf-basic-8
gf-nishida-16
gf-complete-32
gf-plank-logtable-16
gf-plank-32
gf-plank-16
gf-plank-8
gf-clmul-128
gf-ff-64
gf-ff-32
gf-aes-gcm-128

gf-nishida-8 An 8bit version of gf-nishida-16.
gf-nishida-16 Our main library.
gf-nishida-region-16 A region computation version of gfnishida-16 employed by RNCDDS which speeds up therepeated computation of a  x or a  x in GF where ais fixed and x is variable (see [21]).
gf-complete-* An efficient GF (2n ) library with SSE [18][19].
gf-basic-8 A simple 8bit library [22].
gf-plank-* A library based on [23].
gf-plank-logtable-16 A 16bit library similar to gf-nishida16 [23].
gf-clmul-128 A 128bit program retrieved from Solaris
source code that uses Intel CLMUL instruction set specialized for GF (2n ) multiplication.
gf-ff-* A library downloaded from [24].
gf-aes-gcm-128 A 128bit GF program retrieved from
FreeBSD source code that uses no special techniques.

Multiplication
41583
55106
61171
61195
1188501684292449353140163917924062991281013523152010464125
14013111

6Bytes 6Bytes 6Bytes

Division
41557
442499686159
1142921189731005310925101027664514
3693523605535393946
105356429-...

2Bytes 2Bytes 2Bytes
x1
x2
x3

Fig. 4: RNCDDS splits a file every 6bytes and assigns each
2bytes to x1 , x2 , x3 .
chunk is assigned to x1 , x2 , x3 as illustrated in Fig. 4. Eachchunk is encoded by calculating bk = ak;1 x1 + ak;2 x2 +ak;3 x3 ; 8k 2 f1; 2; 3; 4g with gf-nishida-16 and newly obtained 2byte data bk is sent to server k , which is repeatedtill the end of the file. Note the size of the encoded data
is basically 1/3 of the size of the original file. However asa header containing the coefficients ak;1 , ak;2 , ak;3 , file attributes, checksum, etc is appended to it, the final size of an
encoded file stored on each server becomes slightly greaterthan it.

Note that the results in division exclude some libraries that do
not have division functions.
The benchmark results are shown in Table 1. As a consequence, gf-nishida-16, especially gf-nishida-region-16 usedby RNCDDS shows excellent performance in both multiplication and division. Considering its performance and risklessness of patent infringement, we believe gf-nishida-16 is
the best library for the GF arithmetic computation in RNC.

5.2. Decoding
Decoding starts with searching for the servers that have thetarget files, where RNCDDS performs it by using ConsistentHashing [25] without a metadata server (see Sec. 5.3). If
two or fewer servers have the files, the decoding fails. If
three or more servers have the files, then the client chooses
three servers and collects the coefficients ak;1 , ak;2 , ak;3 fromthem. The client next retrieves the encoded data and solves
the following system of linear equations for each 2byte chunkof bk by the Gaussian Elimination:

5. RNCDDS
5.1. Encoding
Suppose a client distributes four encoded files to servers in acluster, then it first decides three 16bit coefficients for eachof them such as ak;1 , ak;2 , ak;3 ; 8k 2 f1; 2; 3; 4g. The client
next sends them to each server together with other file information such as the file size, modification time. In encoding,a file is cut down every 6bytes and each 2bytes in the 6byte

8>< 11 1+ 12 2+ 13 3 = 1++=>: 23 11 11 + 23 22 22 + 23 33 33 = 23

3

a ; x

a ; x

a ; x

b

a ; x

a ; x

a ; x

b

a ; x

a ; x

a ; x

b :

(3)

In RNCDDS, servers in a cluster maintain a common
server list and a client retrieves it when it connects to one ofthem. The client then creates a hash ring based on it as shownin Fig. 6 (a) and looks up files in a way illustrated in Fig. 6(b) (c). Once the hash ring is created, the time complexity
for the file lookup is only O(1). Note RNCDDS locates files
by broadcasting messages to all servers even if there is a discrepancy with the server lists owned by servers and CH takes
no effect. Thus, RNCDDS pays scrupulous attention to data
preservation.

2Bytes 2Bytes 2Bytes
x1
x2
x3

2Bytesbk = ak,1x1+ ak,2x2+ ak,3x3

Fig. 5: RNCDDS encodes 6byte data to 2byte data.

5.4. Programs
RNCDDS consists of three C programs tested with FreeBSD
11 and CentOS 7 and a JavaScript program. The C programs
depend on only a few external libraries such as OpenSSL,
FUSE, libevent2 (only for CentOS, the FreeBSD version uses
kqueue) so that they can be easily ported to other platforms.
rncddsd is a server program that communicates withclient programs rncdds and rncfsd and receives/sends,
saves/reads encoded files. It is usually run as a daemon process.
rncdds, corresponding to Hadoop’s hadoop fs, is acommand line client program that encodes, uploads, decodes,
downloads files and sends other messages to rncddsd. For
example,% rncdds put fileA /dirA/
uploads fileA under /dirA on the servers. Note rncdds is designed to achieve fast directory upload and download by multithreaded parallel pipeline processing, where encoding/decoding and reading/saving processes are executed simultaneously. Our benchmark results in Sec. 7 show its superior performance.
rncfsd mounts RNCDDS as a filesystem through FUSE
userland filesystem library [26] so that one can access thefiles as if they were on the local host. This is very convenient
though it does not perform as well as rncdds (see Table 2).
However, using an SSD and/or a small size of HDD as cacheto store the decoded files, rncfsd minimizes the overheads
for decoding. Both rncdds and rncfsd check the consistency of encoded files by their timestamps and inspect the
decoded files with SHA256.
RNC.js is a JavaScript program that downloads RNC encoded data from three servers via HTTP using XMLHttpRequest and decodes them. If the decoded data is a video,
RNC.js plays it on a web browser with an HTML5 player.
It is currently capable of playing segmented MP4 and WebM
video data and appends a segment of data at a time to thebuffer of the video player while playing it. Due to the overheads for decoding through JavaScript, video playback with
RNC.js consumes slightly higher CPU power than directly
playing MP4 or WebM data though the difference is verysmall. Fig. 7 compares the CPU usages in direct playback(left) and playback by RNC.js (right), where there is no re-(a) An initial state of a hash ring.

(b) Before adding a server.

(c) After adding server 5.

Fig. 6: An example of file management by Consistent Hashing.

Since x1 , x2 , x3 hereby are 2bytes, the original file is restored
every 2  3 = 6bytes. The decoding ends at the end of thefile and the decoded file is checked with SHA256.
5.3. File Management by Consistent Hashing
Hadoop manages file information such as the attributes andlocations by a metadata server. A metadata server easily
scales the cluster but can be a single point of failure andits failure disables the access to all data in the cluster. In
RNCDDS, on the other hand, files are managed by Consistent Hashing (CH) that provides resilient data distribution with minimum reorganization when servers are added ordeleted without a metadata server. For instance, suppose that
there are four servers and four files test.c, Makefile,
Readme.txt and TODO. CH initially locates the servers asshown in Fig. 6 (a) by hashing their names and then locatesthe four files in a similar way as seen in 6 (b). Since the hashcode or owner of a file in CH is the closest node (server) in
the clockwise direction on the ring, the owner of TODO becomes server 3 and that of test.c becomes server 2. When
server 5 is added to the ring as seen in Fig. 6 (c), the only filewhose owner is affected is TODO, where its new owner becomes server 5. Thus, CH achieves resilient and scalable file
management.
4Non-RNC

RNC.jsFig. 9: Servers store the same files in a typical CDN.
Fig. 7: Comparison in CPU usage between direct playback
and playback by RNC.js. There is no remarkable difference.

(a) Five HTTP servers.

Fig. 10: RNCDDS reduces the data storage amount in a CDN.

(b) An HTTP service system by five RNCDDS servers.

2. The RNCDDS system with data redundancy such as
R = 2 can be operated under the fault of two servers,
which increases robustness and reliability of the system.
Note the overheads for decoding can be alleviated by
rncfsd’s cache which temporarily stores decoded data on
an SSD.

Fig. 8: An example of load distribution by RNCDDS.

markable difference between their CPU usages except for the
spike in each playback due to page loading. Suppose the CPU
usage for direct playback of MP4 data is 6 to 7%, RNC.js uses
roughly 7 to 9% CPU power. If decoding functions written in
C are incorporated into the web browsers, the CPU usage will
be even lowered.

6. MULTIMEDIA STREAMING WITH RNCDDS
Many multimedia streaming services are provided through aContent Delivery Network (CDN) which is closely connectedwith cloud storage systems. In a typical CDN, servers store
the same files as shown in Fig. 9 in order to distribute accessfrom clients. However, it requires a vast amount of storage
space and causes significant performance degradation for thefollowing reasons:

5.5. Load Distribution by RNCDDSRNCDDS is designed not only to distribute data but also to
distribute load on the servers. In this subsection, we introduce
a unique HTTP service system that distributes the load on theservers by RNCDDS as its application example.
Suppose we have five regular HTTP servers as shown in
Fig. 8 (a). If we replace these servers with an RNCDDS system consisting of five servers that store all the data the original
HTTP servers owned as seen in Fig. 8 (b) and run a filesystemclient program rncfsd (see Sec. 5.4) on each server, then all
the data become retrievable from all the RNCDDS servers.
If we also run an HTTP service program such as Apache or
Nginx on each server, then all the data the original HTTP
servers had can be served from any new RNCDDS server andherewith the load by HTTP access can be distributed to all
RNCDDS servers. This system provides the following advantages:

1. The usage rate of HDDs over SSDs increases and thethroughput drops in consequence.
2. The cache hit ratio decreases.
If we replace those files with RNC encoded files and letclients access them through RNC.js as seen in Fig. 10, thestorage size becomes 1/3 and therefore not only a large
amount of budget can be saved but also the throughput will be
improved. This is a huge advantage and we expect RNCDDS
to be employed by many video streaming CDNs. We also
note that there is almost no need to re-configure the server
settings; if the servers provide video data via HTTP with Nginx or Apache, all what the administrators have to do are to
replace the original video files with the corresponding RNC
encoded files and to add a few lines such as ”add header’Access-Control-Allow-Credentials’ ’true’;” to their configuration files as a client needs a cross-origin request (CORS)
to access three different RNC encoded file servers. Also, notethe total amount of traffic does not change because a client

1. Heavy access to a server in Fig. 8 (a) degrades the performance and sometimes causes inaccessibility to theserver. The load distribution by a system in Fig. 8 (b)decreases the possibility of server inaccessibility.
5Table 2: Elapsed times for uploading/downloading 63GB
file/directory (the shorter, the faster).

File upload
Dir upload
File download
Dir download

Hadoop10m30.2s
48m34.0s
10m31.9s
20m51.0s

GlusterFS
17m26.4s
54m18.5s
10m51.3s
25m10.0s

rncdds8m49.6s
12m31.1s
8m40.0s
16m51.1s

rncfsd8m56.6s
17m04.5s
9m12.8s
34m54.5s

Fig. 11: A client first accesses a portal site server and thenretrieves RNC encoded data from three RNC servers.
% cp -a
was used towards the mounted directories.
The results are shown in Table 2. Overall, rncdds shows
excellent performance and surpasses Hadoop and GlusterFSin all metrics. The directory upload with Hadoop andGlusterFS takes much longer than that with rncdds andrncfsd. The performance degradation in handling small
files with Hadoop seems to be a known issue [27] [28]. The
overheads by the filesystem interface reduces the performanceof rncfsd compared to rncdds, which is conspicuous at
the directory download. rncdds downloads, decodes andsaves multiple files simultaneously, while rncfsd has toprocess the files one by one because the filesystem does notpass the order for the next file till the order for the current file has been completely processed. Note both rncdds
and rncfsd consume more CPU power than Hadoop andGlusterFS. Therefore, use of a fast CPU is recommended for
RNCDDS.

downloads three encoded files whose sizes are 1/3 of the original.
In our prototype system, a client first accesses a portal site and downloads RNC.js and the information on thethree RNC encoded file servers. The client then fetches
RNC encoded data from them via HTTP and plays a video
with RNC.js (see Fig. 11). Our RNC demonstration video
with three RNC encoded file servers can be watched at
http://rnc01.asusa.net and the original video (no RNC) can bewatched at http://rnc01.asusa.net/videos.
7. BENCHMARK RESULTS
To assure our system’s performance, we measured the elapsed
times for uploading and downloading a directory containing
5,533 sub-directories and 80,919 files and its 63GB tarballfile with Hadoop, GlusterFS and RNCDDS (rncdds andrncfsd). Each measurement was repeated ten times and wasaveraged. The following is the hardware specification of ourhost machines:

8. CONCLUSION
In this paper, we have illustrated the architecture of RNCDDS
and have shown its robustness, storage efficiency, superb performance and high affinity with multimedia streaming. We
believe RNCDDS will not only play an important role in the
future cloud multimedia streaming but will also contribute to
the innovation in the distributed storage technology. However, the optimization of RNC.js and research on the optimal
allocation of RNC encoded files to servers in terms of loadand storage size balance remain as our future work.

CPU Intel Xeon E3-1225v5
RAM DDR4-2133 ECC Non-buffered 64GB
NIC Intel X550 10GBase-T (1Gbps was used in benchmark
due to the capacity of our switch)
HDD 2TB 64MB Cache 7200RPM SATA3  2 as RAID1
for main storage, 1TB 64MB Cache 7200RPM SATA3
for rncfsd’s write cache
SSD 128GB SATA3 for rncfsd’s read cache

9. REFERENCES
Four servers were used as data storage, that is, there werefour slave nodes in Hadoop and four regular servers in GlusterFS and RNCDDS, and one client sent/received data to/fromthem. As for the the redundancy, we used R = 1, i.e., two
replications for Hadoop and GlusterFS and four encoded files
for rncdds and rncfsd. All the hosts were operated with
CentOS 7. To upload/download a file/directory, we used
% hadoop fs -copyFromLocal/-copyToLocal
command for Hadoop and% rncdds put/get
command for rncdds. As GlusterFS and rncfsd handle
data through filesystems,[1] “Hadoop,” http://hadoop.apache.org/.
[2] “Glusterfs,” https://www.gluster.org/.
[3] “Openafs,” https://www.openafs.org/.
[4] Sage A. Weil, Scott A. Brandt, Ethan L. Miller, Darrell
D. E. Long, and Carlos Maltzahn, “Ceph: A scalable,
high-performance distributed file system,” in Proceedings of the 7th Symposium on Operating Systems Design
and Implementation, Berkeley, CA, USA, 2006, OSDI
’06, pp. 307–320, USENIX Association.
6[5] “Moosefs,” https://moosefs.org/.

delivery services in lte/lte-advanced,” IEEE Transactions on Multimedia, vol. 16, no. 1, pp. 277–282, Jan
2014.

[6] Michael Ovsiannikov, Silvius Rus, Damian Reeves,
Paul Sutter, Sriram Rao, and Jim Kelly, “The quantcast file system,” Proc. VLDB Endow., vol. 6, no. 11,
pp. 1092–1101, Aug. 2013.

[17] Z. Liu, C. Wu, B. Li, and S. Zhao, “Uusee: Large-scale
operational on-demand streaming with random network
coding,” in 2010 Proceedings IEEE INFOCOM, March
2010, pp. 1–9.

[7] Cheng Huang, Minghua Chen, and Jin Li, “Pyramid
codes: Flexible schemes to trade space for access efficiency in reliable data storage systems,” Trans. Storage,
vol. 9, no. 1, pp. 3:1–3:28, Mar. 2013.

[18] James S. Plank, Kevin M. Greenan, and Ethan L. Miller,“Screaming fast galois field arithmetic using intel simd
instructions,” in 11th USENIX Conference on File andStorage Technologies (FAST 13), San Jose, CA, Feb.
2013, pp. 298–306, USENIX Association.

[8] Kien Nguyen, Thinh Nguyen, Yevgeniy Kovchegov, andViet Le, “Distributed data replenishment,” IEEE Trans.
Parallel Distrib. Syst., vol. 24, no. 2, pp. 275–287, Feb.
2013.

[19] James S. Plank and et al., “Gf-complete: A comprehensive open source library for galois field arithmetic, version 1.0,” http://web.eecs.utk.edu/
˜plank/plank/papers/CS-13-716.html.

[9] B. Li and D. Niu, “Random network coding in peer-topeer networks: From theory to practice,” Proceedingsof the IEEE, vol. 99, no. 3, pp. 513–523, March 2011.

[20] Hiroshi Nishida, “gf-nishida-16 web site,” https://github.com/scopedog/gf-nishida-16/.

[10] Alexandros G. Dimakis, P. Brighten Godfrey, Yunnan
Wu, Martin J. Wainwright, and Kannan Ramchandran,“Network coding for distributed storage systems,” IEEE
Trans. Inf. Theor., vol. 56, no. 9, pp. 4539–4551, Sept.
2010.

[21] Hiroshi Nishida, “gf-nishida-16: Simple and efficient gf (216 ) library,” https://github.com/
scopedog/gf-nishida-16/blob/master/
gf-nishida-16.pdf.

[11] Ádám Visegrádi and Péter Kacsuk, Efficient Random
Network Coding for Distributed Storage Systems, pp.
385–394, Springer Berlin Heidelberg, Berlin, Heidelberg, 2014.

[22] “Basic library for calculation on finite field,” http://
www.codeforge.com/article/242688/.
[23] James S. Plank., “Fast galois field arithmetic library in
c/c++,” http://web.eecs.utk.edu/˜plank/
plank/papers/CS-07-593/.

[12] Kien Nguyen, Thinh Nguyen, and Sen-Ching Cheung,“Video streaming with network coding,” J. Signal Process. Syst., vol. 59, no. 3, pp. 319–333, June 2010.

[24] Antonio Bellezza,“Binary finite field library,”
http://www.beautylabs.net/software/
finitefields.html.

[13] Anh Tuan Nguyen, Baochun Li, and Frank Eliassen,“Chameleon: Adaptive peer-to-peer streaming with network coding,” in Proceedings of the 29th Conferenceon Information Communications, Piscataway, NJ, USA,2010, INFOCOM’10, pp. 2088–2096, IEEE Press.

[25] David Karger, Eric Lehman, Tom Leighton, Rina Panigrahy, Matthew Levine, and Daniel Lewin, “Consistenthashing and random trees: distributed caching protocols
for relieving hot spots on the world wide web,” in Proceedings of the twenty-ninth annual ACM symposium on
Theory of computing, New York, NY, USA, 1997, STOC
’97, pp. 654–663, ACM.

[14] B. Barekatain, D. Khezrimotlagh, M. Aizaini Maarof,
H. R. Ghaeini, S. Salleh, A. A. Quintana, B. Akbari, andA. T. Cabrera, “MATIN: A Random Network Coding
Based Framework for High Quality Peer-to-Peer Live
Video Streaming,” PLoS ONE, vol. 8, pp. e69844, Aug.
2013.

[26] “Fuse (filesystem in userspace),” https://github.
com/libfuse/.
[27] “Dealing with hadoop’s small files problem,”
http://snowplowanalytics.
com/blog/2013/05/30/
dealing-with-hadoops-small-files-problem/.

[15] Luı́sa Lima, Steluta Gheorghiu, João Barros, MurielMédard, and Alberto Lopez Toledo, “Secure network
coding for multi-resolution wireless video streaming,”
IEEE J.Sel. A. Commun., vol. 28, no. 3, pp. 377–388,
Apr. 2010.

[28] “The
small
files
problem,”
http://
blog.cloudera.com/blog/2009/02/
the-small-files-problem/.

[16] D. Vukobratovi, C. Khirallah, V. Stankovi, and J. S.
Thompson, “Random network coding for multimedia
7