Hi,

There are very few posts here about anything Linux related and I haven't seen anything relating specifically to using C++ under Linux to consume the IQFeed APIs.

The sample C++ code that can be downloaded from http://www.iqfeed.net/dev/api.cfm is for Windows (plus I actually had to install MFC support and Windows XP support to my Visual Studio 2017). The page doesn't mention anything about target operating systems but I guess that Windows is silently assumed.

I have seen one other thread where someone mentioned that people use WINE to run the Windows IQFeed binary on Linux. That doesn't seem to be ideal. Does anyone have a better solution?

Thanks

Not sure what other users have done, but yes, the only way I have seen to run our application on Linux is with a Wine solution, but if anyone has another I would be happy to hear it as well.

Tim

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.

Hi @taa_dtn,

I have finally got to play around with IQFeed on my headless Linux box through Wine. I am able to start it, connect to it and get some messages back (like the periodic timestamps). However, I am having the following problem:

After disconnecting my client, I get (within a couple of seconds) an error that says: "err:winediag: IcmpCreateFile Failed to use ICMP (network ping), this requires special permissions." and the IQFeed client terminates. I was thinking about running the process as a superuser (i.e. instead of "wine iqconnect.exe ..." as "sudo wine iqconnect.exe ...") but I have seen people saying that calline wine as a superuser messes up the file permissions so I don't want to do that. Do you remember dealing with this issue?

Thanks
Jaroslav
Edited by Jaro1337 on Nov 12, 2018 at 03:02 AM

This sounds like the intended behavior of the feed. The client app on your machine is designed to disconnect and shut down if it isn't in use and it does an ICMP ping to the servers as part of it's shutdown process. As a result, the ICMP failure error message isn't the cause of the shutdown.

If you want to keep the app running, you have to maintain a connection to it.

Oh, OK, I wasn't aware of that. Thanks for the explanation!
J.

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.

Not able to reproduce here. The shutdown procedure for my app must differ from yours.

Here is a more detailed description of the behavior I am seeing and of the configuration I run.

This is the exact output that I am seeing _without_ ever connecting a client (the difference from having a connecting client is just that the last line appears later along with the termination of the IQFeed client):

 $ IQFEED
Xlib:  extension "MIT-SHM" missing on display "localhost:10.0".
Xlib:  extension "MIT-SHM" missing on display "localhost:10.0".
Xlib:  extension "MIT-SHM" missing on display "localhost:10.0".
Xlib:  extension "MIT-SHM" missing on display "localhost:10.0".
Xlib:  extension "MIT-SHM" missing on display "localhost:10.0".
Xlib:  extension "MIT-SHM" missing on display "localhost:10.0".
err:winediag:IcmpCreateFile Failed to use ICMP (network ping), this requires special permissions. 

These are the versions of my software:

• Remote host OS: Debian GNU/Linux 9 (stretch) (with some security hardening)


• Remote host Wine: wine-1.8.7 (Debian 1.8.7-2)


• Remote host IQFeed: 6.0.0.5


• Local host OS: Windows 8.1


• Local host XServer: Xming 6.9.0.31

Could the problem be caused by the missing "MIT-SHM" extension?
Edited by Jaro1337 on Nov 15, 2018 at 01:58 AM
Edited by Jaro1337 on Nov 15, 2018 at 01:59 AM

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:

QT_X11_NO_MITSHM=1
_X11_NO_MITSHM=1
_MITSHM=0 

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?

I believe I may have caused some confusion as to how I use the whole system. It's like this:

• I run both the IQFeed AND the feed consuming client (my native Linux executable) on my remote Linux box.


• I launch both the IQFeed (under Wine) and my program from an ssh character-based PuTTY console (as my Linux box is headless).


• The Xming X server running on my Windows box is used for entering username/password into the (I believe) "IQConnect" window that shows up in a Windows window when starting IQFeed. IQFeed then also attempts to minimize itself into a tray-icon which is also shown in a separate window on my Windows machine for the duration of the IQFeed run.


• The only reason why I am using Wine on the remote box is that I don't have a Linux executable for IQFeed (and I believe there isn't one available).


• I am not sure how exactly the shared memory extension is supposed to work but if it's to speed up communication between the IQFeed and the feed consuming client, I still believe that it could work provided the IQFeed running under Wine can, in fact, share some memory with my native Linux program.

The traceroute from my Debian machine to my Windows box won't work because my Windows machine is not directly accessible from the Internet. It's me who initiates the connection from Windows to Linux and communication back to the X server running in Windows is through the "Enable X11 Forwarding" that I allow in my putty ssh client.

Please let me know if there is still anything unclear or wrong about my setup.

Also:

I've tried setting the three environment variables that you provided and the effect was that I got only 2 of the "Xlib: extension "MIT-SHM" missing on display "localhost:10.0"." errors (not the 6 as before) but then the rest of the behavior is the same (the ICMP ping problem followed by the IQFeed termination; where I understand the exit is planned even if the ICMP ping was OK).

The xdpyinfo command gave me the attached output (not that I would understand it much).

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.

The closest to headless I run is:

* building an lxc container, installing wine, etc.
* installing LXDE as a gui environment, but not tied to a graphics card [1]
* installing x2go server
* connecting to the session with an x2go client
* allows gui session via remote access

Don't know if this helps at all.

[1] http://blog.raymond.burkholder.net/index.php?/archives/950-Gui-using-Wine,-X2Go,-LXDE-in-a-simple-LXC-container.html

But having said all that, it seems as though more and more users are switching to Linux. And this goes back 'quite a number of years'.

For the DTN support people, what would be preventing the creation of a native linux based client? Or even a client which does not require a GUI login? Is it an exchange licensing problem?

Oh, and one more thing. Is the iqfeed client 64 bit yet? If not, isn't that kinda stone age? My 64 bit apps are unable to start the iqfeed client, and I have to revert to starting it manually with one of the iqfeed supplied sample apps. As far as I recollect, and it was a long time ago, there is only a 32 bit api for auto-starting the iqfeed client. Or have things changed since way back then?

My 64-bit app just executes a 32-bit stub that starts IQConnect. Yes, it's stone age.