AND



I'm not a programmer, it does not mean however I can't "see" where a problem and or solution may be.

It depends on the type of application you have created, I can't say what to code and what not to code, but I can say if let's say a TAB's server is not accepting a packet of information from your application, then where does the actual problem exist ?
Where did it, ( the packets of data bytes) precisely fall and what are or were the error logs in reply in accordance to your program's error logs?
Hope that makes sense.

If the actual precise point of data breakdown can be established and what caused it, was it from anything to physical phone line damage, in that case neither you or the TAB is at fault... see what I'm trying to get at ?

Ok, if there was no evidence of physical phone line damage, or some other interference beyond the TAB and your program, then where exactly does the problem reside, is it at the "entrance point" of the TAB's server?

Was it too much data at the last minutes before start of race....?

Let's say you have 30 seconds before advertised time of race start, your loaded bets are set to go off at that point in time;
How long does it take to send?
How long does it take for the TAB to respond?
and how long does it take for your program to "tell" you the bet was sent but not accepted?
And then how long does it take for your program to counter-respond?

And has the race by now started ?

Does it happen mostly on the races if it were a successful bet but never made it, it won ?
and if it did get through, it lost?

( law of Murrrfea ? )


If you can eliminate each millisecond of this vital part of the process, your are sure to see where it needs to get fixed, and closer to the "sure fire".
It would be interesting to do a few of these "under the bonnet" things here.
The logs and experiences at this level of the punting game.

Hope these probables help

Puntz