FindComputerStuff

When I chose XML-RPC as my method of serialization, it was because I was learning XML and I needed something to sink my newly acquired fangs into. After attempting to serialize arrays of many-membered objects in tandem, I quickly realised how much overhead the xml tags add to the transport. I found myself almost wishing there was something lighter AND easier. Although JSON produces less data and is easy to use, it is still a bit of a problem for me because I transfer typed data, and support for clients other than web browsers is kind of shaky.

I had always known that the apache web server (God bless their souls) has built-in content compression capabilities, it wont work unless the client reports that it can deal with it - which was just what XML-RPC.NET could not do. Charles Cook has promised gzip http compression support in the next release of his wonderful component but it’s been almost a year now, and nothing’s showing up. So it’s time to roll up my sleeves and get my hands dirty.

Finding the sections of code responsible for parsing responses in the xml-rpc.net source code was not such a breeze as I thought - there must have been millions of classes in there! Okay, maybe not a million, but they were plenty. I had to step through code for a simulated gzip stream and see where parsing exceptions were raised. I did get a measure of success, eventually. What I achieved can only be qualified as a hack (I did it because I needed it badly).

Here is patch for the changes I made to the source code for the 2.1.0.3 version (the latest one, AFAIK) of the XML-RPC.NET component. I only added the parts I need, but I does the job. I achieved about 80% compression rate with the content sent from the server, which is more than good enough for me. See Illustrations below, and compare the content-length in each case.

With compression


Without compression