The new .Net 3.5 Add Service wizard (using WCF) seems to have gone out of its way to make this difficult. When I use 3.5, I always create 2.0-style web references. There are two ways to do this:

1) Use wsdl.exe directly (e.g. from the command line or a build script

2) In VS2008, in the Add Service Reference dialog, click Advanced… (bottom left corner), then click Add Web Reference… in the Service Reference Settings dialog that pops up. You should then be able to use EnableDecompression as usual.

I’m actually not sure what’s going on there - the same thing is now happening to me, but I can’t figure out why. I think it’s something at Betfair’s end - if I use the little python lib I cooked up, and switch on detailed tracing, I see this (headers only):

POST /global/v3/BFGlobalService HTTP/1.1
Host: api.betfair.com:443
Content-Length: 960
SOAPAction: urn:getEvents
Content-Type: text/xml
Accept-Encoding: gzip
User-Agent: pybetfair/0.4alpha

HTTP/1.1 200 OK
header: Server: Apache-Coyote/1.1
header: Date: Thu, 11 Sep 2008 16:12:56 GMT
header: Server: TME-GLUE/5.0.2
header: Content-Type: text/xml;charset=UTF-8
header: ntCoent-Length: 19715
header: Cache-Control: private
header: Content-Encoding: gzip
header: Content-Length: 1498

So Betfair’s servers definitely have compression switched on. It looks like it’s doing something weird with the headers (the jumbled ntCoent-Length header contains the uncompressed size of the response), but the data is undoubtedly compressed, and correctly represented in the Content-Length header. Weird. I’ll see if I can find out what’s going on.

BTW, when using gzip, I believe only the response is compressed, not the request.

BFGlobalService service = new BFGlobalService();
service.EnableDecompression = true;

dont work, since there is no EnableDecompression Property anymore.
Im using the VS2008.

What would be the proper way todo this in .NET 3.5

…
BFExchangeService exch = new BFExchangeService();
exch.EnableDecompression = true;
resp = exch.getMarketPrices(req);
…

when I look at the soap request (using fiddler) I see my request went out with ‘Accept-Encoding: gzip’. So that looks ok.
I notice that the response from betfair is not gzip’d (neither is ANY of the text in my outgoing request).

Am I missing something obvious here. Much googeling has told me that all i should need to do is set EnableDecompression = true, and everything should just magically work.
Is the betfair server playing a cruel trick on me?

Any suggestions or comments gratefully received.
Thanks,
Glyn. (request header below: sorry for large post)

POST /global/v3/BFGlobalService HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 2.0.50727.1433)
VsDebuggerCausalityData: uIDPoygYcuRlhZpPmGVpTdLQXRIAAAAAHzazgPIXCkSq/XdQF2OsD2WAJ3aAVWhKl5xe1Kb1tSYACAAA
Content-Type: text/xml; charset=utf-8
SOAPAction: “getEvents”
Host: api.betfair.com
Content-Length: 558
Accept-Encoding: gzip

0tTwbdin7udb8kXdRl/udR76XcMMUhPkkr2aRfS4P9wo=25322943

It should be sufficient simply to add the code to the app.config file - though don’t add it to the applicationSettings node, insert it as a top level XML fragment. You can also set the values directly on the ServicePointManager object in your app code, although this means changing the code and recompiling if you want to change any values.

A very informative, and enjoyable read, and although I understand the articles aims,I cannot figure where to actually put the code that ups the maxconnection, I have tried pasting the following code into an app.config file as per your instructions with no luck. is there anything else i need to do?

Great article btw.

It is an interesting point about the use of web services for such a high performance application. However, I happen to know that XML serialisation/deserialisation is the largest bottleneck in the system from Betfair’s perspective, so I’m not sure XMPP would help much.

For pure performance, a custom binary protocol would be superior, but then you have the additional burden of writing and maintaining the protocol, and can run into all sorts of interesting problems with byte ordering and encoding across different platforms and processor architectures. Interoperability is the trump card here.