COM is slow, I think mainly because of all of the marshalling involved. See my comments in the software reviews....Sterling management is most definitely not interested in spending another dime on the API. And given all of the prop shops using Sterling Pro, it's no wonder there are so few profitable day traders left. In today's markets, I could not see daytrading futures, stocks, options or forex without an automated or at least semi-automated approach. Been there, done that.
If I understand you correctly, that's quite a bit more interesting than what I did, which was to use only the API calls rather than intercepting packets directly. My "Sterling API server" uses sockets just to communicate in both directions with my bots, and receives/sends info to Sterling on the other end. (In fact, yours a better/faster idea -- but I didn't consider it since I've had the same idea fail with previous platforms as they actually encrypted everything. I'll even go so far as to say it's a little disturbing if things aren't really encrypted -- I'll have to ponder this a little further.) Based on what you said, I'm now sniffing the packets between Sterling and its servers, and they do indeed seem to be unencrypted. As an aside, it's an interesting internal format they're using -- it looks sort of "FIX-like" (numberKey=value pairs); but, annoyingly, the key numbers are different from those of FIX. Sorry if I'm missing something here, but I'm using the "Sterling lib" callbacks and they seem to work, even if they're a little quirky and come in out of order sometimes. For me, the frustration was more on the end of having to use the MS development environments -- especially one that's "outdated". But can one really blame Sterling for not scrapping everything every 3 years just to keep up with whatever MS's latest "technology" is? Now that I've got the stuff coded, I don't think I'll need to mess with it again, which is definitely a good thing. Most other platforms seem to be caught in a similar bind, so I don't think it's Sterling-specific. Some of the Java ones have more stable API's, but they're not as comprehensive and/or the platform itself can be horribly slow. It would be a lot better to have pure socket interfaces to the platforms themselves; yet few platform providers seem to have an interest this market. Maybe they're thinking that those who want sockets will go with FIX, even though FIX isn't available from most brokerages to most clients.
I think that you'll see that within the next 5 years most everyone will offer FIX to their clients (like us) who are programming. In my opinion, it's inevitable as the industry is moving in that direction. As soon as a few start to do it they will have a competitive advantage and the others will have to catch up or lose customers.
lol Except for Sterling who used to offer FIX but no longer does. Nothing like backwards progression... - mnx
Just found the notes I made some time ago, maybe they're interesting to you (although it isn't exactly hard to find this out yourself, lol, since Sterling didn't bother to encrypt) -> [numberKey]=[value] 1=000238~ => packet length 2=0006~ => Packet identifier => 6 = order 3=XXXXX~ => account 4=XXXXX~ => Trader's last name 5=192.168.1.37~ => IP address 6=4450~ => Same for each session 7=15053873~ => Session ID, created by client and sent to server in 1st packet with numberkey 33 12=1~ => Seems to be always 1 27=3~ => 3 = buy, 4 = cancel (I think) 54=XXXXX~ => account 58=B~ => order side 60=100~ => order size 145=100~ => visible size 29=MSFT~ => symbol 179=T~ => Lacks for API orders 62=1.44~ => order price 64=5~ => maybe order type ? I haven't investigated further, I don't intend to send orders to Sterling this way (e.g. create your own packet, send it to your socket and then let the platform send it over its own socket to the server). Reason is that if you do this directly, you'll skip all checks (e.g., the submit code that submitorder() returns is created by the platform, you're skipping all these checks, which is, obviously, very dangerous) and that I doubt that it's much faster (well, it most probably IS faster, but the lag is neglectible in comparison to the server order processing bottle neck). Besides, I'm 100% sure that both your firm and Sterling won't like you to skip all these checks, including BP checks So I'd strongly advise anyone who's going to use sockets to only use it to 'read' info, not send, if you want to stay out of trouble Anyway, hopefully Sterling will move to FIX one day (the above indeed very much is FIX-like and like mnx notes, they used to offer FIX), but I doubt they even bother and with all problems they're currently facing, I'm quite sure that API development is on the bottom of their 'to do list'
Hmmm I see I skipped some keys (like 66=D~ => TIF 68=NSDQ~ => route, etc), but whatever, finding out what's what is the easy part, of all this
Anyone know what the field OpportunisticTrade does exactly? Does it just enable/prevent routing out, and is it avail for all execution venues? Thanks!
Did anyone implement Options strategies (eg. Spread, Butterfly, etc.) using Sterling API? These strategies have such price types as limit/credit and limit/debit. I don't really know how these price types can be managed through Sterling API: I can set limit prices only for single orders. And I don't know how to link the strategy price type with an order price type (I'm not even sure if it's possible at all). So, is there any way to implement these price types? Thank you.
hi guys, i can use the VB sample to get quotes, but could not send any order using the order sample project donloaded from Sterling. Always get the error msg: Order Properties Invalid. did i get something wrong? i am using a real Sterling account. many thanks in advance!