This was highlighted when I was making lots of bets on an in play match – the 5 second delay highlighted the fact that calls were being serialized ie they were backing up. As a result I got timout exceptions which caused me to research and ended up here.. I will implement all these suggestions – these are excellent easy wins for a performace boost coding againt the betfair API.

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.