This post is part of a series of posts about the student research paper CloudRAID. The predecessor can be found in Markus Holtermann’s blog. The successor can be found in Markus Holtermann’s blog, as well.
For a better performance regarding the network usage the RESTful API was implemented to support two different compression standards. Especially for data that is not stored on the file system using compression algorithms (such as JPEG or PNG image files) the amount of data to be transferred can be reduced drastically. Most web servers support the compression algorithms _gzip_29 and _deflate_30. Both algorithms are free of patents and therefore part of the Java standard libraries. The client software can announce whether it supports a compression algorithm. If an HTTP request contains a header field indicating a compression algorithm the request’s body must also be compressed using this algorithm. Since there are different understandings of what the “deflate” keyword means the preferred compression algorithm is the gzip option. This is – although deflate is standardized by the aforementioned RFC – because “deflate” means in HTTP terms that data that was compressed using deflate is sent with additional zlib headers31. But some implementations may expect raw deflate data to be sent32. An erroneous handling of the deflate keyword may therefore lead to problems. This is the reason why the gzip algorithm should be used. The client has four options regarding the compression:
- No header
- Accept-Encoding: gzip
- Accept-Encoding: deflate
- Accept-Encoding: gzip, deflate or Accept-Encoding: deflate, gzip
The first option will result in no compression, the second and third in the regarding compression algorithm. The fourth option will cause the gzip algorithm to be used – independent from which algorithm was listed first. As mentioned above the usage of compression algorithms like gzip can have a positive effect on bandwidth usage and transfer times of data. In a test a tex file with a size of 118 KiB containing plain text could be compressed by 68.6% to 37 KiB. A png file with a size of 17 KiB could only be compressed by 11.7% to 15 KiB. The client software could therefore use compression only when necessary. If needed, the support of other compression algorithms can easily be implemented for the RESTful API. Either the Java interface IRestApiResponse (listing 12 on page 51) is completely implemented or the Java class PlainApiResponse is extended as in listing 13 on page 51.
As described above the client software providing the user interface can have a very simple architecture. Since every relevant action (regarding splitting, merging and meta data handling) is done by the CloudRAID server application the client simply wraps the RESTful API and provides an intuitive user interface. The CloudRAID client software does not base on OSGi but is a conventional Java application.
The CloudRAID client software consists of three components. The first component is the Java code actually wrapping the RESTful API. It provides an abstraction that supports every functionality provided by the RESTful API. HTTP error codes are transferred to Java exceptions containing the error information as found in the tables above. This component is called core.
Figure 17 on page 52 shows the architecture of the core component using an UML class diagram. The ServerConnection class stores the information needed to connect to the CloudRAID server. The ServerConnector class uses such a connection to handle the traffic from and to the server. It stores the session after logging in and validates that client and server use the same API version. It also holds a list of DataPresenters. Every (registered) implementation of this interface gets the current file list as soon as the ServerConnector retrieved a file list from the server. The files stored by CloudRAID are represented by CloudFile objects.
The other two parts are user interfaces using the first component. The specific methods are called on user request and the exceptions are shown in a human readable form. On component is a command line client, the other one a graphical client (see Figure 18). While the CLI is only available in English, the GUI has a multi-language support. Currently there are language files for English and German. Customized language files can be generated easily.