||May 7, 2004 02:04 PM
||Aug 29, 2004 10:19 PM
||Jan 29, 2005 03:14 PM
tadams has contributed to 18 posts out of 21085 total posts
(0.09%) in 7,083 days (0.00 posts per day).
20 Most recent posts:
The documentation doesn't address the last 10 fields in the summary message. Can the fields be described (and documentation updated)?
Pardon the rant - I became distressed after seeing the comment that DTN knows there's a problem with the split process that is currently in production and is testing a fix. (What's the problem? Can you notify me of the change so I can be prepared to alter my historical data as you transition the change into production?)
I applaud your efforts to fix issues quickly when they're identified. My concern though is that your fixes are generally forward-looking and do not provide me with the information necessary to correct my historical data. The end-users need to know the date and time any new logic takes effect, the details of the old flaw, and the logic behind the new change. Any changes to historical logic greatly impact those of us storing data versus those using realtime data.
You can perform simultaneous requests if you spawn separate threads. Each thread should connect to port 9100 and will only receive data that was asked for within the scope of that thread. I've had as many as 15-20 threads hitting IQConnect with no problems (would advise using TCP). The only caveat: IQConnect does not detect a TCP disconnect properly - if you create threads as needed to request data IQConnect will eventually crash when it reaches ~2000 prior connections. You may be able to paste 10 or so history ActiveX controls into your application and avoid the disconnect issue, but then you lose the benefit of a compartmentalized thread.
Edited by tadams on Jul 20, 2004 at 08:49 AM
Ok, now I'm worried that I have no way to analyze the historical data I've been capturing unless I severely scrutinize each symbol that recently split.
Does IQFeed have a firm position on how splits will be handled? Personally, I vote that you dont touch it and we can use the split fields to do it ourselves.
Given that the repeated requests for a change log have been ignored, I'm becoming very nervous about trusting data. I'd **really** like to know when you guys change a single byte of logic. Believe it or not, there are folks out here who want to be able to use the data we're paying for. Please stop the casual modifications that aren't communicated to us and implement a running change log for each modification that makes it's way into production. That way, we would be able to research these topics ourselves - since the logic isn't documented elsewhere....
How about this:
Is there currently a 'safe' day of the week to receive option fundamentals on? My application periodically verifies that I've captured all symbols and I just noticed that I have the incorrect dates for many symbols in my database. *argh*
If I'm not mistaken this has been highlighted a few times, but phrased as 'Number of connections not decrementing'. After I've connected/disconnected to port 9100 roughly 2000 times, IQFeed crashes, Dr. Watson-style.
Some of the TCP/IP developers (Me) have encapsulated objects that spawn a connection for specific method calls. The local 'server', IQConnect, should really be able to determine when a disconnect happens.
As a workaround, I've had to create a quite nasty middleman that monitors the health of the IQConnect process and doubles as a TCP server. My objects connect to this server to receive IQConnect 'health' messages. When IQConnect crashes (multiple times daily), my objects are broadcast a message indicating that it's down. The middleman forcefully terminates IQConnect then restarts it. When 5009 is alive again, a broadcast is sent out indicating that all is OK again.
This is particularly troubling when I'm grabbing a series of historical data. Since I have to code around UP and DOWN events, lots of extra code is required to remember how far I've gotten. On the other hand the middleman is a lifesaver for realtime watches, as my UP event populates a watch list (if IQFeed crashes, the persistent middleman forces it back up ASAP and data capture resumes with no additional coding).
Users of the ActiveX objects won't have this issue, but also cannot recover from an IQConnect crash.
In summary, this is the most critical issue I've seen as it causes IQConnect to crash in the midst of data capture daily. Hope my marketing of the topic has an effect.....
Edited by tadams on Jul 1, 2004 at 09:46 PM
Thanks. In case an additional sample is needed, try "YHQ JS".
Apologies, that was my error. While I'm here....
I'm experiencing issues with historical data for a few option symbols.
As an example, here's the output for 'ZQN AM' (Amazon JAN 05, Call, 65 Strike):
As you can imagine, I'm having trouble understanding timestamps in the format that they're presented on June 10. Advice?
Note that your history application example displays 221:196:00 as 9:36AM
Edited by tadams on Jun 15, 2004 at 10:47 PM
I may be up past my bedtime, but have the T messages (time, port 5009) gone away in the most recent version? I was using this as a method to help determine things were OK.
Note to developers using TCP/IP:
The history server (9100) seems to not like spaces in symbol names. Given that this is the native IQFeed way to reference option symbols, this is a problem. A round of sniffing packets reveals that DTNHistoryLookup.dll replaces a space with an underscore prior to sending the request on to the history server. This is why I couldn't retrieve option data via TCP.
Moral of the story: even though the rest if IQFeed references option symbols like this:
"MSQ FE", you need to convert it to this "MSQ_FE" if you'd like to see history data.
Can this subtlety please be placed in the documentation?
I'm having a problem retrieving historical data for options via TCP/IP. As a test, I picked 'MSQ FE' (Microsoft June call with nice volume) and issued the following commands:
No matter which of the history commands I issue, the response is always a quick '!ENDMSG!'.
I've tried multiple symbols, etc but can't seem to get historical option data. Interestingly, the sample history applications IQFeed provides will retrieve data just fine (same symbol).
I'd gladly post source code that demonstrates the issue, but a simple telnet to 9100 will show the H commands return nothing. Help!
Previous versions of IQFeed did not decrement the connection count (can't vouch for any internal code/resources) within the IQ Connection Manager once a TCP/IP-based application disconnected from it. There's no real damage done unless ~2000 connections are made. At this point, the IQ Connection Monitor does the equivalent of a Dr Watson.
Unfortunately it looks like this is still hanging around in 2.3.
I've written plenty of code to try to catch IQFeed crashes and react properly. One precaution is to make a new local TCP connection for each distinct request. If the connection fails, something is wrong. I never assume a port opened much earlier is still running and available for use. The result is many connections/disconnections. This shouldn't be an issue for DTN since these connections are all internal to my PC.
Answering my own question:
Using depends.exe, I listed the IQFeed DLL dependencies and manually re-registered each dependent DLL.
After I re-registered ATL.DLL all was fine.
I'm receiving an error dialog at the end of the IQFeed 2.3 developer setup.exe.
Specifically, the dialog says:
The following files did not self-register or unregister:
1. C:\@APPS\IQFeed\IQ_API.DLL (Class not registered)
2. C:\@APPS\IQFeed\IQFeedX.DLL (Class not registered)
I've tried manually registering these (regsvr32) and receive the following message:
DllRegisterServer in iq_api.dll failed. Return code was: 0x80040154.
Same error code results for iqfeedx.dll.
I've uninstalled, reinstalled, rebooted between each uninstall/reinstall, installed to the default location, etc but still receive the same error. I've tried to unregister then reregister
The primary port seems to work, but the history port does not. Telnetting to 127.0.0.1:9100 results in the following:
..Error IQ_API Symbol Lookup COM OBJECT, lookup layer not available
Please help, I'm crippled..
We may be going in separate directions.. Detail follows..
For starters, overall datafeed impact: Presently your customers (including me) invoke a real-time watch on each individual option associated with an equity. Folks that are interested in option data generally use little bandwidth for those symbols as the number of 'ticks' are very low in the grand scheme of things. A tick is generated on bid/ask, OI, and actual trades.
If, for example, I wanted data on Microsoft's options I would have to perform a realtime watch on each option symbol. Needless to say that an IQFeed subscriber will quickly approach my 500 symbol limit.
Consider the number of ticks generated by the MSFT symbol itself. I estimate that is you sum all ticks generated by all child options, you'd land at a number less than a quarter of the parent's ticks.
The summary is that if you're interested in options, you essentially max out around 5 equity symbols (and use 1/50th of the bandwidth a person with maxxed out equity watches consumes).
The nature of options is that very few actual trades happen. With options, the valuable data is in the bid/ask prices. Unfortunately this data will not be available via the history mechanism and I'll have to continue real-time watches.
From a technical implementation viewpoint, it would be nice to submit a single watch request for the chain. This, in itself, is of little value because a properly motivated developer can just request the list of call and put symbols and add them his/herself.
The real value would come in terms of additional value developers could offer clients. Here's what I would really like:
- Start: Nothing watched.
- Watch a single option for MSFT (1/500 used)
- Watch a single option for XOM (2/500 used)
- Watch a second option for MSFT (2/500 used)
- Watch a Nth option for MSFT (2/500 used)
In effect, since volume is negligible the point system used to calculate number of watches doesn't penalize you for multiple watched options within a single equity.
I'd give up the above functionality in a heartbeat though if I could get this data historically.
Edited by tadams on May 7, 2004 at 04:11 PM
Oops.. Looks like I selected the correct avatar.
I understand the volume of data would be a strain on any architecture. Maybe a more reasonable wish is the ability to watch an option chain instead of each symbol.
Nice forum software by the way..
Might as well start off the wish list with this one:
If bid/ask change event data were included in the historical option data, it would eliminate my need for an all-day watch on dozens of symbols.
It has been hinted that this data will be available in the next patch..