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 am a hedge fund manager here. It’s funny, I have a Bloomberg terminal and a Bridge feed, but I still like having my DTN feed!" - Comment from Feras
"I've been using Neoticker RT with IQFeed for two months, and I'm very happy with both of the products (I've had IQFeed for two years with very few complaints). The service from both companies is exceptional." - Comment from Public Forum
"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
"I ran your IQFeed DDE vs. my broker vs. a level II window for some slow-moving options. I would see the level II quote change, then your feed update instantaneously. My broker's DDE, however, would take as much as 30 seconds to update. I am not chasing milliseconds, but half a minute is unacceptable." - Comment from Rob
"You have an excellent feed. Very few spikes for Spot Forex." - Comment from Public Forum Post
"There is no doubt that IQFeed is the best data provider. I am very satisfied with your services. And IQFeed is the only one that I would recommend to my friends. Now, most of them are using your product in China." - Comment from Zhezhe
"My broker in Davenport suggested I give you a try as he uses your service and says its the best." - Comment from Bill via RT Chat
"I have to tell you though that using the IQFeed API is about the easiest and cleanest I have seen for some time." - Comment from Jim
"IQ feed is brilliant. The support is mind-bending. What service!" - Comment from Public Forum Post
"I use IQ Feed, Great stuff as far as data analysis information, storage and retrieval is concerned." - 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 21120 total posts (0.14%) in 6,484 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: Thu December 7, 2023 11:49 AM CFBB v1.2.0 18 ms.
© AderSoftware 2002-2003