With the agreement of XAL (Andrés Villanueva) here it is.
Custom Remoting DataPortal with compression for CSLA.NET 3.5.0
Copyright © Andrés Villanueva, 2007
The source code included in this project is licensed under WTFPL. See the attached License.txt file and http://sam.zoy.org/wtfpl/ for more details.
i - History
2007-04-03 - First version - Andrés Villanueva,
2007-04-23 - Sequel version - Andrés Villanueva
2009-12-01 - Ported to C# and adapted to CSLA.NET 3.5.0 and later versions - Tiago Freitas Leal
ii - Reading
For some reading about this project, refer to "Custom Remoting DataPortal with compression sequel"
http://www.softwarethinking.com/blogs/xal/archive/2007/04/23/3.aspx
and posts in http://forums.lhotka.net
iii - Building
Open a CSLA.NET 3.5.0 or later version and add this project. You must use a C# version as CompressionManager.SetContext uses reflection to get to the "_globalContext" field. This field is named "mGlobalContext" in the VB version of CSLA.
This project is targeting .NET Framework 2.0 (CSLA.NET 3.7.1-N2). In order to use it with regular CSLA.NET versions, you must retarget it for .NET Framework 3.5.
Note the dependency on "ICSharpCode.SharpZipLib.dll" that was supposed to be included in the "References" folder. In fact it isn't as the forum doesn't allow uploads bigger than 64 KBytes. Please do:
a) download it from http://sourceforge.net/projects/sharpdevelop/files/SharpZipLib/0.85.5/SharpZipLib_0855_Bin.zip/download
b) unzip it
c) open the "net-20" folder
d) copy "ICSharpCode.SharpZipLib.dll" to this projetc's "References" folder
iv - Tests
This version was tested on a WindowsForms project build under CSLA.NET 3.7.1-N2. On a 100 Mbits/sec network the results were:
- plain remoting transferred 3.760 packets
- compressed remoting transferred just 735 packets
This means the data was compressed to less than 20% of the original size (in packets). This test was done with a +22.000 rows query. As this is a very big chunk of data, it takes a while to compress and to decompress. My guess is compression/decompression must wait for the data stream to be closed. Tests with a smaller table (1000 rows) also show some duration increase:
- 0.6 sec for plain remoting
- 0.8 sec for compressed remoting
The conclusion is not that obvious. Compression should always be used in small bandwidth situations (anything below 100 Mbits/sec). On faster networks, you have to balance the arguments:
PRO
- less usage of network bandwidth (a very big pro in a heavy traffic network)
CON
- more CPU usage on the application server and on the remoting client
- takes longer to show up the updated screen to the user
After all this is just a classic case of speed versus scalability.
Note you can have both compressed and uncompressed portals installed on the same application server and config the compressed one just on off site workstations.
V - Samples
Sample config files are included in the "Sample config files" folder:
app.config - for the remoting client side
Web.config - for the application server side (remoting Web site)
I used the same application and same query with +22.000 rows.
On the remoting client side the internet access was one of these USB devices provided by a cell phone company that is supposed to deliver 2 Mbps downstream.
On the remoting server side the internet access was a cable connection that is supposed to deliver 1 Mbps upstream. So this is the limiting factor of the data transfer.
Test results may vary according to external temporary conditions like the local traffic on the phone cell and on the neighbourhood. Anyway the results are in line with what I was expecting.
Direct internet connection:
- 03:24 sec for plain remoting
- 00:48 sec for compressed remoting
That means the compressed data transfer took only 23,5% of the time of the uncompressed one.
Considering remoting has no security at all, I decided to test a more realistic situation, using a secure line.
VPN connection:
- 03:37 sec for plain remoting
- 00:54 sec for compressed remoting
That means the compressed data transfer took less than 25% of the time of the uncompressed one.
There is only one possible conclusion: use compressed remoting for off site workstations.
Copyright (c) Marimer LLC