There are requests from the business to increase the amount of data to be passed through remoting. Due to the know fact that the default binary serializer is very chatty, the amount of data passed through the channel is very large. There is a global solution, which allows to compress the remoting requests and responses thus alleviating the problem of exceeding the remoting maximum request size.
I was looking at the possible design approaches related to the compression of the remoting and found that extendable remoting framework architecture allows the following as depicted on the diagram:
Next we will review the sample code with the custom compression sink, which represents the typical application designed with layered architecture.
This would allow us to configure the compression via config file, or opt out when we need, for example when the already compressed request/response is invoked using the NonComressible attribute like this:
[Serializable]
[NonCompressible]
public class ConcreteTypeRequest : ServiceBase<ConcreteType>
{
private int _userId;
public int UserId
{
get { return _userId; }
set { _userId = value; }
}
public ConcreteTypeRequest()
{}
}
Below is an example of the config files for stackable providers using remoting extendable framework. It provides the compression threshold parameter, which allows to set the threshold in bytes, when the small requests below specified size would not be compressed.
Server configuration:
<configuration>
<system.runtime.remoting>
<application>
<service>
<wellknown type="Business.BusinessManager, Business"
objectUri="BusinessManager.rem"
mode="SingleCall"
/>
</service>
<channels>
<channel ref="tcp" port="5000">
<serverProviders>
<provider type="Util.CompressionServerChannelSinkProvider, Util"
compressionThreshold="500000"
/>
<formatter ref="binary" />
</serverProviders>
</channel>
</channels>
</application>
</system.runtime.remoting>
</configuration>
Client configuration:
<configuration>
<system.runtime.remoting>
<application>
<client>
<wellknown type="Business.BusinessManager, Business"
objectUri="BusinessManager.rem"
url ="tcp://localhost:5000/BusinessManager.rem"
/>
</client>
<channels>
<channel ref="tcp">
<clientProviders>
<formatter ref="binary" />
<provider type="Util.CompressionClientChannelSinkProvider, Util"
compressionThreshold="500000"
/>
</clientProviders>
</channel>
</channels>
</application>
</system.runtime.remoting>
</configuration>
And finally, attached is a sample application, which implements the compression provider. Currently, it has a limitation of forward only compression, i.e. client->server, but it can be extended for backward compression as well. Let me know if you run into any issues.
Click here to download the RemotingCompressionSample.zip
Update. I've updated the remoting compression sample published at http://alexschmidt.net/blog/post/2008/07/25/Remoting-Compression-Sample.aspx with the compression enabled in both ways, namely, response and request. Another feature is added support for ICompressible interface, which allows to override the compression logic and determine when request or response is exempt from the compression based on some business rules, for example, presence of some data or internal flag.
The updated sample code can be downloaded at remotingcompressionsample_v2.zip (44.00 kb)