开云体育

Now those id's are allocated, and safe to use,
the only issue, is dealing with the problem of multiple allocations
occuring at the same time.

Well, it's probably less painful to set up your own id server. Have one app that requests id's from tws and have your trading software request id's from the id server instead of tws.

Yes, it's another layer of stuff but I suspect it's the only reliable way to get around the problem you are facing.

Well, it's probably less painful to set up your own id server.

Have one

app that requests id's from tws and have your trading software

request id's

from the id server instead of tws.

Yes, it's another layer of stuff but I suspect it's the only

reliable way

to get around the problem you are facing.

That was the first approach we took. It doesn't work, here's why.
Assume you have 10 orders outstanding, each with an id. Disconnect
from tws, and reconnect, the call the open orders request. You get
10 reports, and they have all been assigned NEW id's, starting at the
first id you got from the nextid callback.

I had to take your approach a whole layer farther. I now have 'the
trading application' running on the TWS machine, and it exports a
network accessible api. All of the other machines talk to that
application, not TWS itself. I took one look at the issues of having
multiple programs trying to keep order lists strait, when they have
different id's, and said 'no thanks'.

Well, it's probably less painful to set up your own id server. Have

one > app that requests id's from tws and have your trading software request id's > from the id server instead of tws.

Yes, it's another layer of stuff but I suspect it's the only reliable

way > to get around the problem you are facing.

That was the first approach we took. It doesn't work, here's why.
Assume you have 10 orders outstanding, each with an id. Disconnect
from tws, and reconnect, the call the open orders request. You get
10 reports, and they have all been assigned NEW id's, starting at the
first id you got from the nextid callback.

I had to take your approach a whole layer farther. I now have 'the
trading application' running on the TWS machine, and it exports a
network accessible api. All of the other machines talk to that
application, not TWS itself. I took one look at the issues of having
multiple programs trying to keep order lists strait, when they have
different id's, and said 'no thanks'.

Hmm, not to split hairs, but aren't we talking about the same thing really? The gist of my post was to create a central place where things would get coordinated. It looks like you needed to do more than just hand out unique id's but you did wind up with a central place to keep things together.

Thanks for the info about the re-assignment of id's. I can see this is going to be one of those "10% effort on the real project, 90% effort on spelunking TWS" deals.

- Nick

Hmm, not to split hairs, but aren't we talking about the same thing
really? The gist of my post was to create a central place where

things

would get coordinated. It looks like you needed to do more than

Yah, we settled on the final solution, one program deals totally with
tws, other programs talk to it. An extra layer, but, isolates issues
cleanly.

Thanks for the info about the re-assignment of id's. I can see this

is

going to be one of those "10% effort on the real project, 90%

effort on

spelunking TWS" deals.

Well, it was befuddling intially, we got a lot of issues that
appeared at some times, and not others, and it took a while going
thru detailed execution logs, before we nailed down the exact causes,
but I think we have it now.

Get a methodology for safe order ids in place first. Then firmly
enforce this rule, everywhere. NEVER NEVER NEVER touch an order
between the call to place it, and the callback on order status. Dont
change it, dont cancel it, dont touch it. This is especially
important on something like a trail stop, where the stop condition
can be changing fast. This of course introduces a side effect, what
if the callback never comes ? Add timeouts, and more validation.

I will say this, the demo account is a godsend, and makes this whole
platform 'wonderful' from a programming perspective. It's got
quirks, but we can validate at zero cost. I've done this for another
client, using a different broker, where no test accounts were
available. A test run to validate a specific condition handler, was
a planned item, with an associated cost, because it entailed actually
taking a position in the market, knowing in advance, the goal was to
create a loss, to validate program execution. With IB, we can be
fully validated in advance.