Quote from fbell50:
My experience has been that the 50 message/sec limit applies to api calls made to IB, not to their response. So requesting all open orders would count as one. I often cancel or submit 100+ orders without problem. I ensure that I never submit more than 50 messages in any one second period. Occasionally this delay results in either missed trades or too late to cancels, but for how I trade, it is a minor issue.
You're probably correct...
But it really doesn't matter...
Because this is a GREAT example of why the IB API is klunky.
Requesting ALL orders or ALL executions is periodically necessary...
If you cannot ** absolutely 100% trust ** individual API events (like change in OrderStatus)...
And in my VB6/Excel ATS implementation I cannot...
And every time you have connectivity issues.
Since I average about 400 executions/day...
Sending one (1) request for ALL executions...
Results in IB sending me 400 individual messages at a specific interval...
Which takes roughly 2 seconds...
And "hangs up" the TWS Control for those 2 seconds.
So the fact that I sent only 1 message to IB is irrelevant...
Because IB's slow response creates a huge DELIBERATE bottleneck.
Those same 400 executions could be sent in ** one big message ** in milliseconds...
I mean it's like 40K bytes... big deal.
The point is...
Any well designed system will be constrained at IB's end...
Not at the Customer end by the 50 message/second limit.
But a badly designed system... can overload in countless ways.
That's why firms in the 7 figure capitalization range...
Or anyone that has, say, 2 full time engineers...
Would just scrap TWS and the IB API altogether...
And build something beautiful with the FIX protocol.