Join the 80,000 other DTN customers who enjoy the fastest, most reliable data available. There is no better value than DTN!

(Move your cursor to this area to pause scrolling)

"I'm satisfied with IQFeed. It's the most reliable and fastest quote feed I have ever used. Although I'm a resident in China, it's still very fast!" - Comment from Xiaofei
"Previously I was using *******. IQFeed is WAY more economical, and for my charting needs is just as good, if not better." - Comment from Public Forum Post
"Version has been working well for me and I appreciate that it is now a much tighter client to work with. I feel I can go to press with my own application and rely on a stable platform" - Comment from David in IA.
"With HUGE volume on AAPL and RIMM for 2 days, everyone in a trading room was whining about freezes, crashes and lag with *******, RealTick, TS and Cyber. InvestorRT with IQFeed was rock solid. I mean SOLID!" - Comment from Public IRC Chat
"I like you guys better than *******...much more stable and a whole lot fewer issues." - Comment from Philip
"I have to tell you though that using the IQFeed API is about the easiest and cleanest I have seen for some time." - Comment from Jim
"Just a thank you for the very helpful and prompt assistance and services. You provided me with noticeably superior service in my setup compared to a couple of other options I had looked at." - Comment from John
"I ran your IQFeed DDE vs. my broker vs. a level II window for some slow-moving options. I would see the level II quote change, then your feed update instantaneously. My broker's DDE, however, would take as much as 30 seconds to update. I am not chasing milliseconds, but half a minute is unacceptable." - Comment from Rob
"You are much better than lawyers or the phone company because you answer the phone when I call! I just love your customer service." - Comment from Isreal
"Boy, probably spent a thousand hours trying to get ******* API to work right. And now two hours to have something running with IQFeed. Hmmm, guess I was pretty stupid to fight rather than switch all this time. And have gotten more customer service from you guys already than total from them… in five years." - Comment from Jim
Home  Search  Register  Login  Blogs Recent Posts

Information on Various DTN Products:
DTN IQFeed | DTN ProphetX | DTN Ag | NxCore
Follow DTN_IQFeed on Twitter
DTN.IQ/IQFeed on Twitter
DTN News and Analysis on Twitter
»Forums Index »Product Support »DTN.IQ Client Software Support »Beta not connecting after issuing the CONNECT command
Author Topic: Beta not connecting after issuing the CONNECT command (10 messages, Page 1 of 1)

-Interested User-
Posts: 8
Joined: Apr 25, 2015

Posted: Jan 28, 2016 04:20 PM          Msg. 1 of 10
I've run some tests with the beta and it does not connect after issuing:


It simply does nothing, if I click the connect button it connects OK.

Under the version it works as expected, I issue AUTOCONNECT OFF and then CONNECT and it works, no problem.

The beta seems to reconnect when I issue CONNECT after a network loss.
It is only the first time after launching the client that CONNECT does not work???

I'm requesting the 5.1 protocol by the way. Here is the the input from the client:

S,STATS,,,0,0,1,1,0,0,,,Not Connected,,xxxx,0,0,,0.15,0.0,,\n
S,STATS,,,0,0,1,2,0,0,,,Not Connected,,xxxx,0,0,,0.22,0.22,,\n
S,STATS,,,500,0,1,0,0,0,,,Not Connected,,xxxx,0,0,,0.28,0.14,,\n

Issuing multiple CONNECT and never connects.

Using wine under Linux:


Edited by jrodrigo on Jan 28, 2016 at 04:40 PM

DTN_Tim Walter
-DTN Guru-
Posts: 1130
Joined: Apr 25, 2006

Posted: Jan 29, 2016 08:45 AM          Msg. 2 of 10
Thanks for the report. We will take a look at it.


-Interested User-
Posts: 8
Joined: Apr 25, 2015

Posted: Jan 31, 2016 01:33 PM          Msg. 3 of 10
Thanks Tim...

I continue to run the beta version and I can confirm that the the connection dialog pops up some times
and we are back to the 'procedural CONNECT impossibility' bug, human action is required (ie: click on the connect button).

I've run some more tests with the Diagnostics tool.
First of all, running the full test suite the application crashes.
I've read on the forum that this is due to the COM interfacing that is going to be removed.

There is some strange behaviour when launching the Diagnostic's traceroute.
I have activated the raw sockets capability for wine, so the Diagnostic's ping test works ok.
But the traceroute test reports Error:11010 (+very long timeout) for all the intermediate hops,
only the last hop returns the timing info.

Tracerouting the same boxes with the native Linux traceroute tool yields a lot more information,
the native tool manages to get timing info for some of the first hops (and some times the last one).

If this tracerouting capability is used by the iqconnect.exe application itself this behaviour could be bad.

In addition I would like to know if you are planning any more beta releases (maybe fixing the CONNECT issue),
because this beta seems to work better under wine.

The random crashes on iqconnect.exe start and shutdown under wine seem to have disappeared.
I knew that those crashes were related to the wine - iqconnect.exe interaction and it is nice that they are gone.

I would like to continue using the beta on a daily basis but the CONNECT problem impedes me to do so.
I have to install different iqconnect versions back and forth.

Thanks again Tim.

DTN_Tim Walter
-DTN Guru-
Posts: 1130
Joined: Apr 25, 2006

Posted: Feb 1, 2016 07:23 AM          Msg. 4 of 10

Tracerouting is never used within the application. That is more of a tool for when our service team needs to analyze the connectivity to our servers, so if you are only seeing it there I would not worry about it much, but I'll take a look nonetheless.

We will have a new betas and we are looking at the CONNECT command on initial connect not working currently and will reply when we get it resolved.


-Interested User-
Posts: 8
Joined: Apr 25, 2015

Posted: Feb 1, 2016 08:52 AM          Msg. 5 of 10
Thanks Tim...

Well after starting and stopping iqconnect.exe beta for a good number of times during a 12 hour period I have some not so random crashes.

It seems to always follow a similar path through _XlcDestroyLocaleDataBase (some times RtlRaiseException is on the stack too):

=>0 0xffffe430 __kernel_vsyscall+0x10() in [vdso].so (0x0152b7f8)
1 0xf73e7f47 gsignal+0x46() in (0x0152b7f8)
2 0xf73e9616 abort+0x155() in (0x0152b7f8)
3 0xf7425e72 in (+0x6be71) (0x0152b7f8)
4 0xf742ba5a in (+0x71a59) (0x7d9df1e8)
5 0xf742c6a8 in (+0x726a7) (0x7d9df1e8)
6 0x7de700d4 _XlcDestroyLocaleDataBase+0x83() in (0x7d9be9c0)
7 0x7de74cb0 in (+0x4ecaf) (0x7dd10008)
8 0x7de7c4b6 _XCloseLC+0x75() in (0x7dd10008)
9 0x7de7c500 _XlcCurrentLC+0x2f() in (0x7dd10008)
10 0x7de752ed _Xlcmbstowcs+0xdc() in (0x7dd10008)
11 0x7de753d3 _Xmbstowcs+0x32() in (0x7dd10008)
12 0x7de8a86e in (+0x6486d) (0x7dd10008)
13 0x7de889c6 _XimLocalOpenIM+0x3f5() in (0x7da06360)
14 0x7de86e57 _XimOpenIM+0xf6() in (0x7da06360)
15 0x7de6c837 XOpenIM+0x46() in (0x0152dff8)
16 0x7dff0247 in winex11 (+0x50246) (0x0152dff8)
17 0x7dff1461 in winex11 (+0x51460) (0x0152e028)
18 0x7dfed783 in winex11 (+0x4d782) (0x0152e0e8)
19 0x7dfe61e1 X11DRV_WindowPosChanging+0x320() in winex11 (0x0152e178)
20 0x7eb6105f in user32 (+0xa105e) (0x0152e2c8)
21 0x7eb5cab9 in user32 (+0x9cab8) (0x0152e488)
22 0x7eb5642f CreateWindowExA+0x18e() in user32 (0x0152e718)
23 0x1023255c in mfc110 (+0x23255b) (0x0152e784)
24 0x1022d058 in mfc110 (+0x22d057) (0x0152e7f0)
25 0x1021b05a in mfc110 (+0x21b059) (0x0152e848)
26 0x1021b2f8 in mfc110 (+0x21b2f7) (0x0152e860)
27 0x1021a9dc in mfc110 (+0x21a9db) (0x0152e87c)
28 0x0040a8fd in iqconnect (+0xa8fc) (0x004acc34)
29 0x00613c98 (0x00613cc0)
0xffffe430 __kernel_vsyscall+0x10 in [vdso].so: popl %ebp

Could be a wine issue or maybe something going unhandled it is hard to tell. I leave you a log file with multiple occurences.

By the way I'm starting wine in X11 synchronous mode:



File Attached: (downloaded 304 times)

DTN_Tim Walter
-DTN Guru-
Posts: 1130
Joined: Apr 25, 2006

Posted: Feb 1, 2016 09:10 AM          Msg. 6 of 10
Are you getting a dmp or mdmp file created in your Docs\DTN\IQFeed directory by chance?


-Interested User-
Posts: 8
Joined: Apr 25, 2015

Posted: Feb 1, 2016 10:44 AM          Msg. 7 of 10
The only files that I have under Docs are:


Keep in mind that this crash is happening launching and closing iqconnect.exe, it is not a crash on operation. Could be cleanup or initializing issues.

Should I activate something on the iqconnect?
BTW I have totally restricted the wine debugger, so no crash notifier popup comes up nor the debugger kicks in, it justs crashes;
in this way I can get to restart iqconnect daemon style if a crash happens during operation.

DTN_Tim Walter
-DTN Guru-
Posts: 1130
Joined: Apr 25, 2006

Posted: Feb 1, 2016 10:46 AM          Msg. 8 of 10
Ok, I have seen where WINE does not create the crash file before, I was hoping though.

Thanks for checking.


-Interested User-
Posts: 8
Joined: Apr 25, 2015

Posted: Feb 1, 2016 02:02 PM          Msg. 9 of 10
I'm starting to think that this comes from a long running wineserver...
I cannot force the dumps under a fresh wineserver.

I will restart a fresh wineserver with iqconnect each time and monitor this dumps for some hours/days,
we'll see if it is a wineserver issue.


Time: Fri March 23, 2018 9:18 PM CFBB v1.2.0 0 ms.
© AderSoftware 2002-2003