开云体育

FWIW, i've given up completely on all the ib supplied code, and now
have my own stuff deal directly with the sockets. On the c++

I did the same in Delphi and I think to use the sockets directly
without wrapper classes or the ActiveX is the best way.

Order Id: I use GetTickCount.

Read my last posting.

Order Id: I use GetTickCount.

Read my last posting.

That'll only work, if you dont have lots of orders going in on the
same tick. Since this application can literally generate orders by
the hundreds, and they often come in batches at the same time, that
wont work for me.

Maybe in this case the multimedia timer or a high-resolution timer
could help you.

Maybe in this case the multimedia timer or a high-resolution timer
could help you.

The real answer is to understand how to get id's allocated from tws.
Everybody is under the mistaken impression, the NextId callback is
the one to use, it's not. You use the request ids call, to reserve a
block, then the nextid will make a jump from what it was, to the next
one after your block. 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. By going this route, there should be no
chance of hitting duplicates, and if you start getting duplicate id
messages, it's because you are modifying orders before they are
actually 'in and working'. You cannot modify an order between the
time you call placeorder, and you get the callback saying it has been
placed. If you are doing trailing stops, it's easy to 'accidently'
modify a stop during this timeframe, if you dont watch out for the
specific circumstance.

My applicaton allocates a block of 1000 id's when it starts, and due
to the potential time lag from requesting more, to actually getting
them, I request a new block when I've used up 800 of the 1000.

Tonite i've been fiddling with issues during partial fill sequences,
I finally figured out a way to reliably get partials from the demo.
Load up a buy order for 15 nq, then sit and wait for the offer to
show size of 8 or less. Lift that offer with a limit order. If the
offer is 1, you'll get a string of 15 individual fills, scattered
over approximately 2 seconds. If you have logic to throw in stops
and targets on fills, it's an ideal way to test it, because you'll
have the initial order in on the first fill, then you have every
possible bad timing issue repeat for the rest of them, and your code
to update the stops and targets will not go off on every fill,
because you'll have orders in the 'pending callback' state.

I actually added a bit of code onto the tickprice handler, to 'lie in
wait' for the correct time, then let loose the orders to buy/short
with as many as the demo will allow. This is an exercise well worth
doing, because if your code has any accidental timing dependancies in
it, you will find them with this exercise. Once i figured out the
way to reliably get partials, what I thought was going to be a simple
verify that some handlers were working correctly, turned into anohter
session of 'wtf is this thing doing now ??'

Options are going to be even more interesting, because we'll have to
observe the 1 second limitations. To prevent automated trading, the
exchanges mandate the brokers dont accept orders at a rate of higher
then one per second on any given customer account for options. Gonna
be interesting figuring out just how accurate the timers for this are
at ib, and just how much time we will really have to introduce
between options orders. I suspect to be safe, it's going to have to
be on the order of 1.2 seconds or longer. If your application is
going to be doing groups of options orders, it'll need to set up an
order que, and then peel orders off the que at the maximum allowd
rate, to forward them for handling.

Maybe in this case the multimedia timer or a high-resolution

timer

could help you.

The real answer is to understand how to get id's allocated from

tws.

Everybody is under the mistaken impression, the NextId callback is
the one to use, it's not. You use the request ids call, to reserve

a

block, then the nextid will make a jump from what it was, to the

next

one after your block. 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. By going this route, there should be no
chance of hitting duplicates, and if you start getting duplicate id
messages, it's because you are modifying orders before they are
actually 'in and working'. You cannot modify an order between the
time you call placeorder, and you get the callback saying it has

been

placed. If you are doing trailing stops, it's easy to 'accidently'
modify a stop during this timeframe, if you dont watch out for the
specific circumstance.

OK. I never placed more more than one order within a millisecond. But
I can?t imagine that the use of a hi-resolution timer wouldn?t solve
all these id problems.

The GetTickCount function uses the PC Clock. So why don?t you use the
QueryPerformanceCounter? It uses the PC's clock counter but it reads
the current value of the countdown register in the timer chip to gain
more accuracy.

So you can go down to less than 1 microsecond (depending on your
machine speed you can even count the nanoseconds). To place an order
needs a least 5 to 10 microseconds - I guess. So you will never have
duplicate order id?s. At least I can?t believe that.