Sterling API Developer Thread

Quote from the_whistler:

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).

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.
More...
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.
 
Quote from the_whistler:

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.
More...

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.

Quote from the_whistler:

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.
More...

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.
 
Quote from Euler:

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.
More...

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.
 
Quote from since1997:

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.
More...

lol Except for Sterling who used to offer FIX but no longer does. Nothing like backwards progression...

- mnx
 
Quote from Euler:
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.
More...

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' :(
 
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!
 
Quote from fastpenny:

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!
More...

show us your code and the exact error message
 
You must log in or register to reply here.
Back
Top