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)

"IQ feed works very well, does not have all of the normal interruptions I have grown used to on *******" - Comment from Mark
"Thanks for the great product and support. During this week of high volume trading, my QuoteTracker + IQ Feed setup never missed a beat. Also, thanks for your swiftness in responding to data issues. I was on ******* for a few years before I made the switch over early this year, and wish I had done it a long time ago." - Comment from Ken
"Thank God for your Data Feed as the only Zippers I see are on my pants (LOL), and no more 200 pip spikes to mess up charts." - Comment from Spiro 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
"I use IQ Feed, Great stuff as far as data analysis information, storage and retrieval is concerned." - Comment from Public Forum
"I will tell others who want to go into trading that DTN ProphetX is an invaluable tool, I don't think anyone can trade without it..." - Comment from Luther
"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
"If you want customer service that answers the phone, your best bet is IQFeed. I cannot stop praising them or their technical support. They are always there for you, and they are quick. I have used ****** too but the best value is IQFeed." - Comment from Public Forum
"I am very happy I changed. I love the product, but more so I am thrilled with Tech Support. You are knowledgeable, polite, pleasant and professional." - Comment from Pat
"I had always used ******* but for the past 2 weeks have been trying DTN IQFeed. Customer support has been extraordinary. They call just to make sure your problem hasn't recurred." - Comment from Public Forum
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
Viewing User Profile for: EspressoE
About Contact
Joined: Mar 8, 2006 10:38 AM
Last Post: Mar 20, 2009 10:04 PM
Last Visit: Mar 20, 2009 10:04 PM
Location: Colorado, USA
Occupation: Computer Engineer
Yahoo IM: EspressoE
Post Statistics
EspressoE has contributed to 30 posts out of 21159 total posts (0.14%) in 6,564 days (0.00 posts per day).

20 Most recent posts:

Hi Steve,

Did the server team get back to you on when they might be able to get Option Open Interest in the historical messages?

Just out of curiosity, how do you receive the Open Interest? Does that come from the exchange directly on a tick-by-tick basis, or is it computed at the end of the day? Is it possible to reconstruct the open interest from the previous open-interest value and the tick data?

IQFeed Developer Support » Symbol Lookup by TCP/IP Not working tonight Feb 26, 2009 06:46 PM (Total replies: 6)

Excellent, thanks Steve. I can confirm that it's working again on my side.


When will this be fixed?


IQFeed Developer Support » Symbol Lookup by TCP/IP Not working tonight Feb 26, 2009 08:05 AM (Total replies: 6)

I'll ask one last time Steve:

Edited by EspressoE on Feb 26, 2009 at 08:05 AM

Off Topic » Non-IqFeed Data feeds for Options Feb 25, 2009 08:07 AM (Total replies: 0)

I've been using IqFeed for several years to get end-of-day option data along with quotes, dividend info, and split info for optionable stocks. I absolutely need end-of-day data and being able to monitor the market in real-time is desirable, but not required at this point. The reliability of the IqFeed for downloading approximately 300,000 items a day in chunks of 500 (due to the symbol limit) along with the format of the data, and stability of the API leaves a lot to be desired.

Is there a better product available for EOD option data?


IQFeed Developer Support » Symbol Lookup by TCP/IP Not working tonight Feb 24, 2009 02:24 PM (Total replies: 6)


Any update on this / ETA on a fix?



IQFeed Developer Support » Symbol Lookup by TCP/IP Not working tonight Feb 23, 2009 08:52 PM (Total replies: 6)

Out of all of the TCP/IP Symbol lookup commands, only the SSE command seems to be working.

For example, when I make a SES request, I see the following sequence:

Request: 'SES,MSFT;'
Response: '!ERROR! !NONE!\r\n\r\n!ENDMSG!\r\n'

Was there a server update that did this? I don't see that the commands have been deprecated.

Edited by EspressoE on Feb 24, 2009 at 08:36 AM

The Open Interest field in HDX seems to always be zero. When is this going to be available?

For example, the following request should show open

2009-02-20 23:44:22,2.10,1.68,1.68,1.97,308,0,
2009-02-19 23:44:22,2.22,1.94,2.22,1.94,176,0,
2009-02-18 23:44:22,2.36,2.09,2.12,2.09,225,0,
2009-02-17 23:44:22,2.36,2.04,2.04,2.14,298,0,
2009-02-13 23:44:22,3.20,3.10,3.20,3.19,52234,0,

Should be:

2009-02-20 23:44:22,2.10,1.68,1.68,1.97,308,495,
2009-02-19 23:44:22,2.22,1.94,2.22,1.94,176,415,
2009-02-18 23:44:22,2.36,2.09,2.12,2.09,225,369,
2009-02-17 23:44:22,2.36,2.04,2.04,2.14,298,215,
2009-02-13 23:44:22,3.20,3.10,3.20,3.19,52234,2332,



I can tighten down the time frame a little. It did work on Sunday at 11:54 AM Eastern and did NOT work starting at 8:06 PM Eastern time through 11:46 PM Eastern time when I patched my software to work around the issue. At least the name seemed to be correct for the fundamental / update messages.

While I was having the problem, I tried disconnecting and reconnecting multiple times with the same results.

Upon looking at the data this morning, I can confirm that it is functioning correctly again.

Was this problem isolated to a single server? If it was an individual server, do you have any suggestions on how I could automatically choose a different server in case it happens again?



Sorry, forgot to list the command that produced the results listed above:


The following command should have worked (and did on Friday):


When doing a search for option tickers, the names are coming back with some sort of DB key instead of the underlying ticker symbol.

For example, issuing a search for MSFT yields no results (because MSFT isn't in the name anymore), but searching by the option root, MQF does return:

MQF VW 59491810 OCT 2007 P 17.5

It should be:

MQF VW MSFT OCT 2007 P 17.5

Data and Content Support » Unable to connect - Easter Sunday - Quotes Apr 16, 2006 12:06 PM (Total replies: 5)

I've been connected for over an hour without a disconnect, so from my viewpoint, the problem has been solved.

Thanks Jay et al!


Data and Content Support » Unable to connect - Easter Sunday - Quotes Apr 16, 2006 11:25 AM (Total replies: 5)

I've been connected for 12 minutes without a disconnect so far, so whatever you are doing is helping.

Data and Content Support » Unable to connect - Easter Sunday - Quotes Apr 16, 2006 10:46 AM (Total replies: 5)

WOW Jay, I didn't expect you guys to work on this today! Let's hope the resolution is quick and easy so you can get back to enjoying your weekend.


Data and Content Support » Unable to connect - Easter Sunday - Quotes Apr 16, 2006 10:26 AM (Total replies: 5)

Hi Matthew,

I also started getting the disconnections around 10 PM Eastern Time on Saturday (April 15). I haven't been able to resolve it as of yet on my end and haven't changed anything on my end.

Background Info
I was hoping it would be working better this morning, but it isn't. I'm using the TCP/IP connection and receive the proper S,KEYOK<LF> response after connecting but after about 30 seconds, I get a disconnection and then the system reconnects. Historical requests seem to normally go through fine, but they sometimes get aborted as well.

So . . . it looks like something has changed on the IQFeed side of things.


IQFeed Developer Support » Closing Historical Port (9100) using TCP/IP Apr 11, 2006 08:53 AM (Total replies: 14)

Sorry, since I'm working with options, I automatically assumed that AAAN was an option symbol

Anyway, as Steve pointed out previously in this post and in several other threads that may be more appropriate for the issue that you are talking about, the double-error message that you are currently seeing will be resolved in the next release. So, when you do a query and there isn't any historical data available, you will currently get:


!ERROR! Invalid symbol.


I believe in the next version, this will become just:



This is nearly the same response that you would like, so it looks like DTN may have already resolved this -- you will just have to wait for the next release of the software.

IQFeed Developer Support » Timeout for Historical Daily Options Data Apr 10, 2006 08:46 AM (Total replies: 4)

Hi Steve,

I finally got that error report list put together for you and have emailed it to the developer's email address.


IQFeed Developer Support » Closing Historical Port (9100) using TCP/IP Apr 10, 2006 08:12 AM (Total replies: 14)

Hi Steve,

In looking over this old post, I was wondering if you were ever able to reproduce this potential bug. I looked at it this morning and am able to reproduce the problem very easily, now. Here's the process to reproduce it:

  • Open a socket connection to 9100

  • Send a request (I used 'HD,MSFT,10;' for this case)

  • Read 0 to N-1 bytes where N is the number of bytes in the response message

  • Close the socket (with data still available to be read)

I also tried doing an orderly shutdown using shutdown(sHistoricalSocket,SD_BOTH) before closing the socket without any luck.

Here's some quick-and-dirty code that will reproduce the potential bug:

// Execute this code after connecting to IQConnect.exe
for(int nIndex=0; nIndex < 10; ++nIndex)

* Connects to the historical quote feed at port 9100.
* @param s Reference to a SOCKET instance used to
* maintain the socket connection.
* @returns True if socket connected, False otherwise
bool ConnectToHistorical(SOCKET& s)
sockaddr_in addr;
bool bConnected = false;

// set the address to localhost:9100
addr.sin_family = AF_INET;
addr.sin_port = htons(9100);
addr.sin_addr.S_un.S_addr = inet_addr("");
memset(&addr.sin_zero, 0, sizeof(addr.sin_zero));

// connect to the server
if (connect(s,(struct sockaddr*)&addr,sizeof(addr))==0)
bConnected = true;

return bConnected;

* Opens a new socket for each history request and doesn't read all of the data
* before closing the socket. This tends to leave sockets open in the
* iqconnect.exe application which shows up as an excessive number of threads
* in the Windows task manager.
void ThreadLeakTest()
const size_t uTEMP_SIZE = 1024*16;
SOCKET sHistoricalSocket;
char achTemp[uTEMP_SIZE];

// Create a socket and attach to the historical data feed
sHistoricalSocket = socket(AF_INET,SOCK_STREAM,0);

if (sHistoricalSocket != INVALID_SOCKET)
if ( !ConnectToHistorical(sHistoricalSocket) )
cerr << "Unable to connect to historical socket" << endl;

// Request data over the historical port
send(sHistoricalSocket, achTemp, strlen(achTemp), 0);

// As of this morning at 2006-04-10 08:28, there will be 652 bytes
// in the response message.

// Wait 1 second for data to come in

// Retrieve up to 100 bytes of the 652-byte response

// Close the history socket

Edited by EspressoE on Apr 10, 2006 at 08:13 AM
Edited by EspressoE on May 3, 2006 at 10:00 AM

IQFeed Developer Support » Closing Historical Port (9100) using TCP/IP Apr 10, 2006 07:09 AM (Total replies: 14)

You have to separate the option root from the expiration and price code.

Try HD,AA_AN,10;


IQFeed Developer Wish List » Echo original request with response Mar 16, 2006 11:58 PM (Total replies: 0)

This may apply to more than the history requests, but that's where I've run into this problem first.

When requesting history data, I will often process a batch of files to back-fill data. To speed up this process, I keep the socket open and go through a lot of request data, read response sequences. If something goofy happens (like getting two !ENDMSG! tokens for one request), it is possible for my software to read the first !ENDMSG! token and think that it's done. The next request would be made and then the second !ENDMSG! would be read and mistakenly matched up with the second request. (Note that the double !ENDMSG! problem is already scheduled to be fixed, but I feel there is still a need for a beginning-of-response token).

There are many ways to solve this, but I feel the most robust way would be to echo the original request back as the start of the requested data. Another possibility would be to add an additional field to the original request that will be passed back at the beginning of the data transmission. That would make it possible to be backwards compatible with the current implementation.

Current Implementation

TX> HD,[Symbol],[Days];
RX> Time Stamp, High, Low, Open, Close, Volume, OpenInterest<CR><LF>
. . .
RX> Time Stamp, High, Low, Open, Close, Volume, OpenInterest<CR><LF>

Proposed Implementation with user-defined request sequence field. If the Request Sequence field is not provided, then the current functionality remains.

TX> HD,MSFT,10,[Request-Sequence];
RX> !BEGIN_MSG! Request Sequence<CR><LF>
RX> Time Stamp, High, Low, Open, Close, Volume, OpenInterest<CR><LF>
. . .
RX> Time Stamp, High, Low, Open, Close, Volume, OpenInterest<CR><LF>

If this isn't clear, let me know and I'll try to explain some more...

P.S. This is similar in concept to the thread

Edited by EspressoE on Mar 17, 2006 at 01:48 PM

Time: Sun February 25, 2024 7:36 PM CFBB v1.2.0 8 ms.
© AderSoftware 2002-2003