||May 7, 2004 01:04 PM
||Apr 15, 2020 05:50 PM
||Sep 8, 2020 04:29 PM
taa_dtn has contributed to 122 posts out of 19810 total posts
(0.62%) in 5,992 days (0.02 posts per day).
20 Most recent posts:
@karthikkrishan: I start my monitoring app when my machine boots. That can be done manually, by a command in rc.local, or by a systemd service. (I haven't done the last, though the configuration process looks pretty reasonable.) The monitor runs until the system shuts down, though it can be killed and restarted manually.
The monitor can be commanded to remain active 24/7, which is useful during development, but normally it sleeps while the market is closed and wakes up shortly before the open. It starts up IQConnect by forking and execing
/usr/bin/wine /home/home-dir/.wine/drive_c/Program Files/DTN/IQFeed/iqconnect.exe -product product-name -version version-number -login iqfeed-username -password iqfeed-password -autoconnect Then it opens the streaming port and communicates with the usual protocol.
The monitor has an exponential-fallback procedure to attempt reconnection in case the connection is lost, but I'll skip that for now. It's not clear to me that it's needed to the extent that it used to be.
At the end of the day the monitor automatically forks and execs other apps to collect the day's history and fundamentals. Multiple connections work fine; for example, I usually do history fetch with seven clients running in parallel.
During the day I start my other apps manually for analysis and trading. They just assume IQConnect is running, connect to the appropriate port(s), and go. Obviously you could do something more sophisticated, but I haven't found it necessary, and having a single "master" process to handle error conditions simplified things when I was writing the code years ago.
At the end of the trading day the monitor closes the last connection and after a while iqconnect.exe exits. Just to make sure everything stays sane for the next day, the monitor shoots it down with
killall iqconnect.exe if it's hanging around unexpectedly.
So that's an overview of how it all works. IQFeed is a stronger, more reliable product than it was when I started this long ago, so you can probably get by with a simpler infrastructure nowadays.
I've been using IQFeed under Wine on Fedora successfully for a very long time. My usage pattern is simple, though -- a "monitor" app starts up before the opening session and stays open until the close, while apps performing specialized functions connect as needed during the day. The monitor app is the only one that tracks and manages the status of the service.
I'd certainly like a native API, and in the past have offered to help out with an implementation, but I understand the need to keep the support load under control.
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!