Best practices?

promagma · Feb 25, 2010

Quote from gigi:

So I will have a second independent little process which will also connect to the same trading account and monitor simple things, like ensuring the total net position does not go over a certain limit, or that there are no more than N orders in 10 minutes for example, or more than M positions open simultaneously.

Good plan, I am an experienced coder but still had an obscure scenario last year where my code flipped a contract 200 times at market costing $10k. Needless to say, I put in place an "N orders in 10 minutes" type filter.

propseeker · Feb 25, 2010

Quote from nitro:

The one thing that I try to do even in this case though, and it costs me a litle bit, is to push state as far as possible into the API. So what I don't do is keep my order state, and the API has it's own idea of order state. I have found that not only violates general principles, it is a great way to get what your position/order state is and what you think it is, out of sync.

what you wrote here is a little mind boggling. are you saying you keep no internal order state relying completely on the api? if so, you sure are putting a lot of faith in that api, and also, something is wrong with these 'general principles' you speak of if they don't allow for one of the pinnacles of failsafe systems: redundancy.

let me give you just one scenario that would destroy you with that setup... you're a market maker, you have a gazillion open limits out, your execution line goes down, market moves 1%, you're stuffed to the gills IN REALITY but have no idea of current state because you're waiting for the api to tell you. i don't know about you, but i'd rather be aware that i'm out of sync and be able to do something about it, than be out of sync and have no idea what's going on.

ScoobyStoo · Feb 25, 2010

Quote from nitro:

Why not post a UML or interface/abstract classes of your proposed designs?

I still think you should post interface/classes in say C# so that design/code can be (re)viewed.

Thanks very much for the offer but I'm not looking for my design or code to be peer reviewed. Just looking to have a broad discussion at the conceptual level. I'd never post any proprietary materials on a public forum anyway. Just for starters it makes anything relating to intellectual property a total nightmare.

nitro · Feb 25, 2010

Quote from ScoobyStoo:

Thanks very much for the offer but I'm not looking for my design or code to be peer reviewed. Just looking to have a broad discussion at the conceptual level. I'd never post any proprietary materials on a public forum anyway. Just for starters it makes anything relating to intellectual property a total nightmare.

I did not realize there was anything proprietary here. I thought this was for your own purposes.

ScoobyStoo · Feb 25, 2010

Quote from promagma:

Good plan, I am an experienced coder but still had an obscure scenario last year where my code flipped a contract 200 times at market costing $10k. Needless to say, I put in place an "N orders in 10 minutes" type filter.

Interesting. Do you use an arbitrary number for N? In running some of the wilder variety of market data through my app I've seen occasions (unscheduled news releases etc) when I could be legitimately flipping a position multiple times per second.

ScoobyStoo · Feb 25, 2010

Quote from nitro:

I did not realize there was anything proprietary here. I thought this was for your own purposes.

It is, but I don't want to shut any doors in the future.

nitro · Feb 25, 2010

Quote from propseeker:

what you wrote here is a little mind boggling. are you saying you keep no internal order state relying completely on the api? if so, you sure are putting a lot of faith in that api, and also, something is wrong with these 'general principles' you speak of if they don't allow for one of the pinnacles of failsafe systems: redundancy.

Well in the order case it is probably wrong to keep only API state. I should have said in the marketdata case. For example, you subscribe to a symbol. Keeping that state twice causes headaches.

Even in the order case, I have seen order state get out of sync with API order state, but I have yet to see intra-day positions as reported by the API get out of sync with what it really is.

let me give you just one scenario that would destroy you with that setup... you're a market maker, you have a gazillion open limits out, your execution line goes down, market moves 1%, you're stuffed to the gills IN REALITY but have no idea of current state because you're waiting for the api to tell you. i don't know about you, but i'd rather be aware that i'm out of sync and be able to do something about it, than be out of sync and have no idea what's going on.

Every API I have ever seen allows you to query for positions/open orders on login. In the case where you do not have that, then naturally you have to keep state in case of a crash. Even in this case, relying on stale state is extremely dangerous. Not only that, exchanges have a short fuse when you try to do things like cancel orders that are not live, or cancel orders that are filled, etc. Once or twice is ok, but do that 10,000 times and you are going to hear it.

In the case of the CBOE and probably all the option exchanges, the quoting engines will auto cancel your quotes if your heartbeat is dolwn for a certain amount of time, something like 15 seconds but I don't recall exactly. I don't know what the ECNs do.

ScoobyStoo · Feb 25, 2010

Quote from nitro:

Well in the order case it is probably wrong to keep only API state. I should have said in the marketdata case. For example, you subscribe to a symbol. Keeping that state twice causes headaches.

Even in the order case, I have seen order state get out of sync, but I have yet to see intraday positions as reported by the API get out of sync.

I'm a bit lost here. So are you saying that if your internal app logic needs to know the state of an order you put a request into the API and wait for a callback each time?

nitro · Feb 25, 2010

Quote from ScoobyStoo:

I'm a bit lost here. So are you saying that if your internal app logic needs to know the state of an order you put a request into the API and wait for a callback each time?

No. I mean if the API has a class that keeps state, I use that. I don't create a new class, and copy the state from that class to my class in the need-for-speed case.

ScoobyStoo · Feb 25, 2010

Quote from nitro:

No. I mean if the API has a class that keeps state, I use that. I don't create a new class, and copy the state from that class to my class in the need-for-speed case.

OK, I can see now why you are prepared to accept the tight coupling and the maintenance overhead that this design approach brings. As you said earlier, it all depends on the required speed of execution and my needs are obviously not as great as yours. I have adopted a decoupled approach throughout with a fundamental principle being that I should be able to port the app to a different API with the minimum of hassle.