Taylor, [no sleep... ever] Inside your processMessages() I see "sleep for 15 seconds". What does the rest of the code doing during that blocking sleep() call? Right - nothing. Any incoming quotes, order updates, etc. Nothing will be processed, just filling?up buffers (or probably overfilling them, since you will sleep 3 times by 15 seconds) while you decided to sleep in the middle of the busy working day!-)I guess you need to re-think your implementation so that the sleep() is neer used anywhere. Also you don't need to? [tick-by-tick is s stream] You mentioned "no more than 1 tick-by-tick request can be made for the same instrument within 15 seconds". Why do you want to send?reqTickByTickData() request for the same instrument >1 time?? One time is enough to subscribe for stream of updates (which will be delivered to you in form of the documented callbacks) until?you decide to cancelTickByTickData. If you don't cancel - it will keep you "subscribed" for that instrument?stream for the whole day. [outgoing request rate control] You probably want to avoid sending >50 requests to IB in any given second. If you're interested?only in those 3 contracts, no need to worry about outgoing request rate control, just send them all 3 asap (once only). For more serious application where you might have implemented some scanners and potentially tons of contract details requests and subscribing/cancelling other types of IB data, you might want to keep an eye on the rate of the outgoing requests, but even if you see it is getting close to 50 in current second interval, you do not block your program, but merely skipping sending request until it is safe to do so. For this you probably want to implement some "outbox" queue (in form of some container) with your requests objects and then you only allow "shoveler" to process that queue with a limited rate. Even more: for some requests there are special request limits (like for historical data requests), then you probably will need to implement different queue for those and different shoveling rules (own rate) for that queue. Cheers, Dmitry Shevkoplyas On Fri, Feb 5, 2021 at 4:10 PM Nick <news1000@...> wrote:
|