I'm in the middle of a long-overdue protocol upgrade (to 6.2) and I'm seeing some odd behavior that I wonder if anyone else has encountered.

The problem is that long after my app has exited, iqconnect.exe is still running. Diagnostics.exe client stats claims the app is still connected, and still receiving data on the Level 1 port. However, I've confirmed that my app is definitely not running.

ShutdownDelayLastClient is set to a reasonable value (10 seconds), but I doubt it applies, since iqconnect.exe thinks it's still talking to a client. I see that start.exe, conhost.exe, explorer.exe, and iqconnect.exe are all still running, though. Manually stopping the feed closes everything down as expected.

All this is on Fedora 34 Linux using Wine 6.18, so that might be a factor.

Any ideas?

I still have no solution to this, though a few things I've observed suggest the problem might be related to the way I start iqconnect. I've tried several different methods, and they all misbehave, but some in different ways than others. The common behavior for all of them is that iqconnect thinks it's still connected to a client even after the client (a) closes the only socket it has open to iqconnect, or (b) exits entirely.

FWIW, this problem doesn't exist when using protocol 4.9, but does with 6.2.

So, what is the recommended way to start iqconnect under Wine?

There are a lot of different factors to discuss here.

First, the protocol you set in an S,SET PROTOCOL command should make no difference. Do you mean the version number of the iqfeed client software? That could be a factor, because version 6.2 is 64-bit, while prior versions were 32-bit. Detais like Windows registry keys (which are simulated under Wine) work differently behind the scenes, and this could cause problems. Especially if you upgraded from 6.1 to 6.2 as opposed to installing 6.2 freshly.

There is no "recommended" way to start IQ connect under Wine, because I've found that it can differ in different setups. In a Windows environment, it doesn't matter what order you do things in. When attempting to run IQFeed under Wine, sometimes it does matter. This just means that you must start IQFeed first; must launch it manually instead of using your third-party app's "launch my feed" feature to launch it, and so forth. And even this isn't consistent. My best advice is to find which order works best, and always perform tasks in that order each time.

"IQFeed still thinks it's connected to a client" shouldn't be a problem, because IQfeed allows multiple connections at the same time to the same computer. So even if that were happening, IQFeed wouldn't prevent you from doing anything. I would need more information to comment further. An iqconnect log file would help.

Finally, DTN recommends the third-party product CrossOver by Codeweavers, for our customers who want to run or develop IQFeed under Linux or Mac environments. It's inexpensive, easy to work with, doesn't require a lot of technical knowledge, and runs IQFeed successfully. They offer free trials at https://www.codeweavers.com/crossover. And if you decide to purchase it, DTN will even reimburse you for the cost of their software. Depending on the nature of your project, it may be an option for you to consider.

That's everything I can think of to tell you. If you can provide an iqconnect log file via the usual support channels, I may be able to give more specific advice.

---

Sincerely,
Gary Stephen
DTN IQFeed Implementation Support Specialist

Thanks for the reply, Gary.

I've written a toy app that exhibits all the correct (expected) behavior, so I'll try to nail down what's different between that and my real apps. I don't have much time available this week, so my next update here might take a while longer.

Now that I have an example working, it's clear that the problem is unrelated to the protocol and client software upgrades.

For reference, I start iqconnect.exe using fork() and execl(), passing a path to the executable and all the appropriate arguments. I wait a few seconds for it to initialize and then I connect. This has worked well for years. CrossOver has never been necessary.

My concern is that iqconnect is still running, sending data to a socket that it thinks is still connected to a client even though the client process is long gone. This is very likely to cause problems somewhere down the line. At the very least, iqconnect's CPU demands are going to get progressively larger over time as clients connect and disconnect. At the worst, it could block and be unable to accept new connections. Plus, the widget tray fills up with multiple connection manager icons, some of which don't respond to mouse clicks, which is ugly and confusing.