Special

Introducing the “Welcome to Xojo” Bundle!

New to Xojo and looking for guidance? We've put together a terrific bundle to welcome you! Xojo Bundle

This bundle includes six back issues of the magazine -- all of year 21 in printed book and digital formats -- plus a one-year subscription (beginning with 22.1) so you'll be learning all about Xojo for the next year. It's the perfect way to get started programming with Xojo. And you save as much as $35 over the non-bundle price!

This offer is only available for a limited time as supplies are limited, so hurry today and order this special bundle before the offer goes away!

Article Preview


Buy Now

Issue 9.1

FEATURE

Optimizing Client-Server Communications

Using ZIP-archives and AES encryption to improve security and performance

Issue: 9.1 (November/December 2010)
Author: Mattias Sandström
Author Bio: Mattias is the programming CEO of Tangix Design & Development, located in Sweden. Tangix is developing software in REALbasic mainly on the Windows platform.
Article Description: No description available.
Article Length (in bytes): 19,049
Starting Page Number: 19
Article Number: 9106
Resource File(s):

Download Icon 9106project.zip Updated: 2010-11-01 16:57:18

Related Web Link(s):

http://www.einhugur.com/Html/eCrypt/index.html
http://www.mbsplugins.de/
http://www.php.net
http://en.wikipedia.org/wiki/Advanced_Encryption_Standard

Excerpt of article text...

During the course of a long-lasting product, things never evolve along the anticipated lines. What started out as a simple affair with just a couple of kB being transferred between server and client, turned after five years into major bit hauling in the MB range. Clearly something had to be done to manage scaling and this article will outline our solution and explain some of the details from the implementation, both on the client and on the server.

In the fifth year of one of our products we decided to spend some time revisiting the core of the product, in this case a piece of code in a client application that downloads information from a server. In the beginning, the client downloaded text information with an approximate size no larger than 100 kB, but this has since increased to about 8 MB due to all of the features that have been added during the years. From a couple of pictures (about 10) we eventually found ourselves having to be able to manage many pictures (about 50) and then later on adding generic attachments as files and the size of the download inflated rapidly.

To handle this, the initial approach was to request individual resources from the server with pictures being downloaded separately, thus allowing us to thread the download process with four Threads downloading the information in parallel. As clients were being added to the system, the threaded download approach increased the burden on the servers and a new solution was needed.

The client displays text information which is downloaded in three XML files. In addition to this, an arbitrary number of pictures and file attachments can be added and the client requests each of the files one at a time from the server, wasting precious time and server resources. Furthermore, each file is encoded in Base64 before being transmitted to the client which increases the file-size by roughly 30%. Add network latency (see separate sidebar) and it is obvious that this solution does not scale very well with an increased number of pictures and attachments and a new solution is needed.

Recently we got a gap in the schedule and revisited the implementation of the download functionality with the mission to do something about it and improve performance. A low-hanging fruit was to stop using Base64 encoding to reduce the total size of the download by 30% right off the bat. The second thing was to minimize the number of requests and the apparent solution would be to create a ZIP-archive containing the three XML-files, the pictures and attachments required - after the server has created the ZIP-archive, the client would then only have to download one single file from the server! Third on the list was to increase the security of the download. We are already using HTTPS for the download, but using proxy and firewall solutions that allow penetrating the SSL connection by inserting their own certificates makes it possible to read the information from the ZIP-archive and we decided to add encryption to the file before it would be downloaded to the client. Voila, three simple requirements that would increase the performance and security of the download.

Translating the three requirements into pieces of code, we see that four steps are required:

...End of Excerpt. Please purchase the magazine to read the full article.