I agree with Nitro's earlier post that a pure socket interface to Sterling would make life a lot easier. In fact, I essentially implemented that myself -- what I developed to the Sterling API is a multithreaded server whose only job it is is to take orders for Sterling and pass Sterling callback info back info via two sockets, one for each task. It crashes maybe once a day on average (for unknown reasons), but I also wrote another script whose only job it is is to restart the app when it crashes. It's bubble gum and duct tape, but once in place it seems to work pretty well. [/B]
What exactly did you do ? You hooked some API functions in the DLL ? I did something similar, I created a little re-route of the incoming packet data, filter the packets for quote/order confirms etc, open up a socket and use this socket to communicate with my own program (I was also inspired by Nitro's post, lol). So in short, when the Sterling trade pro initializes, I would let Sterling PRO open up a socket and then would forward the incoming packets to the socket, just before the packets are being processed by the sterling platform itself.
However, I ran some test to see how it performs, i used a highperformance timer and was a bit disappointed when I saw that the difference was most of the times something like 0,0000001 second between the data received via COM and the socket. Sometimes the COM was even faster ! So I stopped doing that, since the whole process is far more prone to errors than the COM stuff.
Not sure why I got such disappointing results, I KNOW that COM is damn slow (i've tested it thorougly) and I know it's the most stupid thing STerling could have done (use COM), but that's why I don't really understand the slow performance of the socket ... I think one of the problems was that my socket would sometimes 'group' packets instead of sending them everytime one would arrive. Or, maybe the other side, my bot, would ping the incoming socket for received data on a too big interval (all I know that my bot would receive grouped packets, which weren't received as a grouped packet by the platform). I think it's probably that, since I used a simple Delphi component in my bot, I wouldn't be surprised if it's not made for high speed and that I should code something myself.
I wish that sterling would just use damn callbacks, come on, this isn't 1990 anymore. It's damn frustrating that we, as Sterling users, have to go through all this bullshit to compete with other platforms.
