||May 7, 2004 01:04 PM
||Nov 17, 2018 01:11 AM
||Jun 10, 2019 11:24 AM
taa_dtn has contributed to 120 posts out of 19126 total posts
(0.63%) in 5,527 days (0.02 posts per day).
20 Most recent posts:
My 64-bit app just executes a 32-bit stub that starts IQConnect. Yes, it's stone age.
Thanks for the clarification!
Hopefully Tim or Steve will correct me if I'm wrong, but my understanding is that it's not possible to run IQFeed completely headless. You can configure things so that the username and password are provided automatically, without creating a dialog window. (That's the way my setup works.) However, as you noticed, there will still be an applet in the tray for the duration of the run.
The MIT-SHM extension is used by GUI toolkits to speed up the transfer of images from the application or toolkit to the X server. I've forgotten which toolkit IQConnect uses (maybe it's Qt?), but apparently it attempts to initialize or use the extension.
You can see from the xdpyinfo output after the line "number of extensions: 23" that MIT-SHM is not among the extensions provided by Xming.
I forgot to mention that you should export the environment variables after setting them. Did you do that anyway?
You're correct that there is no Linux executable for IQConnect; we have to use Wine.
You should be able to traceroute from your Linux box to your Windows box even though the Windows box isn't directly accessible from the Internet. It should still be directly accessible from your Linux box. If it's not (for example, because a firewall setting prevents it), that could account for the ICMP failure.
I haven't looked into this in any level of detail, but it appears there are a couple of problems.
First, running remotely (over ssh?) means that the MIT-SHM extension won't be usable. It's a shared-memory image transfer extension for improved local performance, and that doesn't work over the net. I suppose it's also possible that Xming doesn't support it; try the
xdpyinfo command to see if MIT-SHM is one of the supported extensions.
A quick Google suggests that setting environment variables to disable use of the extension might help. Before running IQConnect, try this:
The ping failure is something different, but at the moment I'm not sure what. Firewall issue? If you
traceroute from your Debian machine to your Windows machine, what happens?
Not able to reproduce here. The shutdown procedure for my app must differ from yours.
I haven't captured the Wine log file in a while, so at the moment I can't check for that. I've enabled logging to see if it crops up when my app exits later today.
That said, I expect Steve is right and this is just a consequence of the normal shutdown procedure when there are no clients.
I run my client with regular user privileges; there's no need to run as root.
Apologies for the late reply; I've been on vacation.
I've been running IQFeed with Wine on Linux for years. Only once (back in 2015) have I had a significant problem, and Tim worked closely with me to solve it.
I don't have any information about the "Ping Failed" line. However, the rest of the log indicates that IQConnect started successfully but no app connected to the administration port (9300). IQConnect eventually shuts down if there are no connections to that port.
Before IQConnect shuts down, can you run one of the other IQFeed apps to see if it works properly? If so, the next place to look is in your app. If not, there are other possibilities; a firewall issue, for example.
One other thing occurs to me. You might be having trouble running IQConnect if Wine is in 64-bit mode. This happened to me in the past, and I worked around it, but I don't know if it's still an issue. To try the workaround, set the environment variable WINEARCH to "win32" before running IQConnect.
Install Wine. Then download the IQFeed client and install it (I used "wine iqfeed_client_5_2_5_0.exe"; just substitute the correct filename for the client that you downloaded).
You can start the IQFeed server (IQConnect) manually, or your application can start it automatically by executing the appropriate command with execl() or system(). The command will be something like "/usr/bin/wine /YOUR_HOME_DIRECTORY/.wine/drive_c/Program Files/DTN/IQFeed/iqconnect.exe -product YOUR_REGISTERED_PRODUCT_NAME -version YOUR_REGISTERED_PRODUCT_VERSION -login YOUR_LOGIN_ID -password YOUR_PASSWORD -autoconnect".
Once IQConnect has started your app can connect to the TCP ports and issue commands as described in the Developer Documentation.
On http://iqfeed.net/symbolguide, the "U. S. STOCKS - ADDITIONS" page seems not to have been updated since April 21st.
Looks like it was nothing major -- just a few indexes.
I'll track down the symbols, then let you know. If they're just holdovers that I'm no longer using, there won't be any need to update the subscription.
I normally run an end-of-day tick history fetch for a few thousand symbols. Monday and today (Wednesday), about 95% of the fetch completed successfully, then it stopped because iqconnect returned "!ERROR! Unauthorized user ID." in response to the history request. Restarting iqconnect and re-running the fetch resolved the problem.
Tuesday there was no problem.
It might be coincidental, but the failure always occurred when fetching from the 148 servers and never when fetching from the 156 servers.
Running IQFeed version 220.127.116.11 under Wine on Linux.
Before I dive into debugging, did anything change on the 148 servers over the weekend that might account for this?
Every day I grab a copy of the additions to the symbol guide from
In today's file, I see a number of symbols that were retired after acquisitions. For example: AFFX, BDBD, CTCT, CYBX, DMND, DYAX (and there are quite a few more).
Assuming these companies haven't all been spun out again, it looks like there's a bug in the code that generates the symbol list.
Some of it's 4.9 and some is 5.1. No changes for 5.2 yet.
Looks like everything ran cleanly today. There were no disconnections, a large history fetch at the end of the day ran to completion, and the tick data appears to be correct.
My app connected without difficulty this morning and so far is running normally.
Looks good so far. We'll see how it does tomorrow when the markets are back in full operation.
Thanks for the fix!
Sounds good. Thanks!
Pardon; I can't tell if the attachment worked. Trying again.