开云体育

ctrl + shift + ? for shortcuts
© 2025 开云体育
  1. Twsapi
  2. Topics

Building a real time feed: reqMktData vs reqHistoricalData vs reqRealTimeBars (with keepUpToDate=True)

 

The TWS API provides many ways to request live data and I am confused about the best approach. Below are at least 3 methods I am aware of, with some notes based on my tests and what I've read.
I've implemented reqHistoricalData with keepUpToDate=True but I am experiencing issues with accuracy of data.
?
From your experience and based on my needs, which would you recommend?
?
1) reqMktData (have not spent too much time with this one): constantly fires off a bunch of values ("Tick Types") for a given instrument
Pros: Can access more raw data than other methods - though I am mostly interested in OHLCV. Can get data with minimum delay straight from open.?
Cons: Need to deal with multiple callbacks coming at different times (tickSize for OHLC and tickSize for volume). Need to build logic to construct bars from accumulated ticks and timestamp them. Could lose some information on true highs and lows based on when we received the tick.
? ?
2) reqHistoricalData with keepUpToDate=True (what I have implemented right now)
Pros: Single request to deal with historical and live data load. Easy to handle system restarts, simply re-submit the request to fill all data that was missed until current time.
Cons: I've compared the bars I receive with keepUpTodate during the session with the raw chart in TWS & historical data request generated after end of session, and almost none of the OHLCV values exactly match! Does historicalDataUpdate stream the final confirmed bar before a new one is streamed, or does it just streams unconfirmed bar values at the arbitrary 5 secs delay?
?
3) reqRealTimeBars (have not tested yet): Provides bars for each 5 second period
Pros: should give the actual high/low for the period. Confirmed bar is received shortly after the interval closes.
Cons: need to combine with reqHistoricalData on system startup to build up the historical values prior to start. Only available for 5 sec bars.
?
My needs:
- Needs to support most listed US stocks
- I am fine with 5 mins bars as highest resolution. I resample to lower resolutions (30 mins, 1 day etc...) as needed using real time aggregates in timescaleDB
- Need to stream data for about 50-100 stocks
- I prefer accuracy of data over speed
?
Any pointers much appreciated!
JP
 

Also interested. By the way, I like the case that on one single machine, I can monitor real-time streaming for multiple symbols ( for example, 10 symbols) at the same time.
(a) I understand that one account (for example, paper trading or real account), one can monitor one real-time data.
(b)
?It is possible to have multiple TWS instances running on the same computer if each is configured with a different API socket port number. Also, each TWS session can receive up to?32 different client applications?simultaneously
?
------
seems the only way I can do this is: every time, I disconnect one real-time live stream of one symbol, then go to next symbol.
Best and thanks,
 

I don't completely follow your suggestions, but you may misunderstand the TWS API capabilities.

You are correct in that one TWS/IBGW supports connections from up to 32 client applications simultaneously, but each of these clients can subscribe to as many real-time feeds as your market data subscriptions allow:
  • The basic subscription limit is 100 different instruments, and subscriptions to different data feeds for the same instrument count only once against that limit (say, reqMktData, reqRealTimeBars, reqTickByTikLast, reqTickByTokBidAsk for the same instrument)
  • The limit of simultaneous subscriptions per client application can be increased considerably (beyond 1,000) in case your account has certain value levels, you generate significant commissions, or you purchase booster packs.
  • And you can run multiple TWS/IBGW instances on the same machine (just not with the same user/password), but that is not necessary for real-time market data subscriptions.

For my taste, reqRealTimeBars is the best approach for the requirements @jplem presented. reqHistoricalData with keepUpToDate=True is not a real-time feed, comes from a Historical Market Data farm instead, frequently sends multiple "bars in progress", occasionally sends funny data (as jplem already found out), and does not get automatically reconnected upon network outages throughout the day or nightly resets. reqRealTimeBars, for very liquid instruments, sends bars even for 5 second periods with no activity and can be used as a great no-overhead "are you still alive" monitor.

So you'll need only one client application with one TWS/IBGW connection if you want to create a real-time streaming "ticker-tape" that records all events for 10 instruments in the order they arrive. And as I said before even with so most basic market data subscriptions, that client application can do that for up to 100 instruments.

闯ü谤驳别苍
?
On Sun, Mar 16, 2025 at 02:46 PM, <hellemory612@...> wrote:

Also interested. By the way, I like the case that on one single machine, I can monitor real-time streaming for multiple symbols ( for example, 10 symbols) at the same time.
(a) I understand that one account (for example, paper trading or real account), one can monitor one real-time data.
(b)
?It is possible to have multiple TWS instances running on the same computer if each is configured with a different API socket port number. Also, each TWS session can receive up to?32 different client applications?simultaneously
?
------
seems the only way I can do this is: every time, I disconnect one real-time live stream of one symbol, then go to next symbol.
Best and thanks,

1 - 3 of 3