Join the 80,000 other DTN customers who enjoy the fastest, most reliable data available. There is no better value than DTN!

(Move your cursor to this area to pause scrolling)




"I was on the phone with a friend who uses CQG and right after the Fed announcement, CQG was as much as 30 seconds behind DTN.IQ. Some quotes were off by as much as 15-18 cents. Your feed never missed a beat." - Comment from Roger
"DTN has never given me problems. It is incredibly stable. In fact I've occasionally lost the data feed from Interactive Brokers, but still been able to trade because I'm getting good data from DTN." - Comment from Leighton
"Interactive Brokers tick data was inconsistent, so I have switched to using DTN exclusively. It is great to no longer have to worry about my datafeed all day long." - Comment from Philippe
"IQ feed is brilliant. The support is mind-bending. What service!" - Comment from Public Forum Post
"Just a quick one to say I'm very impressed so far :) The documentation for developers is excellent and I've quickly managed to get an app written to do historical downloads. The system is very robust and pretty quick considering the extent of data that's available. The support guys have been very helpful too, in combination with the forums it's been plain sailing so far!" - Comment from Adam
"Everything is working amazing now. I'm already impressed with the true-tick feed of IQFeed and it's ability to support my 480 symbol layout." - Comment from Tyler via Email
"I just wanted to say how happy I am with your service. I was able to download the API docs last week and I was able to replicate Interactive Brokers historical bar queries and realtime bar queries over the weekend. That was about one of the fastest integrations that I've ever done and it works perfectly!!!!" - Comment from Jason via Email
"Its working FABULOUSLY for me!! Holy cow...there has been so much I've been missing lately, and with this feed and Linnsoft software...I'm in the game now." - Comment from Chris R.
"Thanks for all of your help. Great customer service deserves to be recognized which one the reasons I've been a customer of DTN for over 10 years!" - Comment from Stuart
"DTN feed was the only feed that consistently matched Bloomberg feed for BID/ASK data verification work these past years......DTN feed is a must for my supply & demand based trading using Cumulative Delta" - Comment from Public Forum Post
Home  Search  Register  Login  Recent Posts

Information on DTN's Industries:
DTN Oil & Gas | DTN Trading | DTN Agriculture | DTN Weather
Follow DTNMarkets on Twitter
DTN.IQ/IQFeed on Twitter
DTN News and Analysis on Twitter
»Forums Index »Archive (2017 and earlier) »Data and Content Support »Streaming Interval Bars - Replaced Previous Watch
Author Topic: Streaming Interval Bars - Replaced Previous Watch (4 messages, Page 1 of 1)

jmcstone
-Interested User-
Posts: 5
Joined: Oct 29, 2017


Posted: Oct 29, 2017 09:44 PM          Msg. 1 of 4
I am just starting to use the streaming interval bars. I plan on streaming bars on multiple securities with each security having multiple different intervals (example: 1 min bars, 5 min bars, and 15 min bars - all on the same symbol).

The documentation states that a "S,REPLACED PREVIOUS WATCH,[Symbol],[RequestID]" message may be returned. Under what circumstances will a previous watch be replaced? That is, what fields in the request must match for it to replace a previous request (Symbol, Interval, IntervalType, BeginFilterTime, EndFilterTime, ...)?

Also, the documentation is not clear if the RequestId is the previous RequestId or the new RequestId (it would actually be nice to have both values returned). In fact, the RequestId should be on the SYMBOL LIMIT REACHED and the INVALID PARAMETERS FOR REQUEST messages also - so, that you can accurately associate the message to the request.

One last question - what is the use for Update Interval? Does it delay the sending of a bar - or, does it do something such as updating a 1 min bar every 15 seconds?

Thanks

jmcstone
-Interested User-
Posts: 5
Joined: Oct 29, 2017


Posted: Oct 29, 2017 10:13 PM          Msg. 2 of 4
I apologize - I reposted this question in the "DTN.IQ Client Software Support" section as the questions seem more appropriate for that area of the forum.

DTN_Tim Walter
-DTN Guru-
Posts: 1238
Joined: Apr 25, 2006


Posted: Oct 30, 2017 11:13 AM          Msg. 3 of 4
I'll answer it in both just to be safe for the next person.

Streaming bars can only handle one interval per symbol, so multiple connections to the derivative port will be needed to achieve what you are looking for. That is the reason for the replacement, any BW on a symbol that has already been watched will be a replacement.

With multiple connections, one per interval you can have the different ids that you are looking for. I'll note the request for the error to include the RequestID.

We have no guaranteed way to know a bar has completed, except to receive a trade that is outside of the current interval. That is when a BC bar is sent. But, if there is an hour between trades, then you end up waiting for an update that you may need. So a time based update is the alternative to that.

By setting a interval of x seconds you will always get an update or a complete message within x seconds of the last trade.

What that means to you is that if a BU message is received you can update your app with it, but you should expect to either receive further BU messages or a BC message and you will need to update the interval with each.

Tim

DTN_Tim Walter
-DTN Guru-
Posts: 1238
Joined: Apr 25, 2006


Posted: Oct 30, 2017 11:51 AM          Msg. 4 of 4
I was incorrect regarding the replace. I never use request IDs in my code, so I never realized this, but when you send two watches with empty request IDs, say BW,GOOG,1 and BW,GOOG,5, it replaces the first. hence my answer.

However, it is actually the duplicated requestID that is replaced. So if you sent two watches with two requestIDs
BW,GOOG,15,,,10,,,GOOG15,,,1 and
BW,GOOG,20,,,10,,,GOOG20,,,1
that does work fine. So you can do everything in one socket.

So given that, each requestID should be unique in the system, and is only replaced when duplicated, I think this also takes care of the second question.

Sorry for my confusion.

Tim
 

 

Time: Tue April 23, 2024 2:01 AM CFBB v1.2.0 8 ms.
© AderSoftware 2002-2003