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 use IQ Feed, Great stuff as far as data analysis information, storage and retrieval is concerned." - Comment from Public Forum
"DTN feed was the only feed that consistently matched Bloomberg feed for BID/ASK data verification work these past years......DTN feed is a must for my supply & demand based trading using Cumulative Delta" - Comment from Public Forum Post
"I've been using Neoticker RT with IQFeed for two months, and I'm very happy with both of the products (I've had IQFeed for two years with very few complaints). The service from both companies is exceptional." - Comment from Public Forum
"Very impressed with the quality of your feed - ******* is a real donkey in comparison." - Comment from A.C. via Email
"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
"This is an excellent value, the system is generous (allowing for 500 stocks) and stable (and really is tick-by-tick), and the support is fantastic." - Comment from Shirin via Email
"I was on the phone with a friend who uses CQG and right after the Fed announcement, CQG was as much as 30 seconds behind DTN.IQ. Some quotes were off by as much as 15-18 cents. Your feed never missed a beat." - Comment from Roger
"I'm very glad I switched to IQFeed. It's working perfectly with no lag, even during fast market conditions." - Comment from Andy via Email
"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
"You are either overstaffed or people just don't have problems with your feed because customer support always answers the phone quickly." - Comment from Jay via Email
Home  Search  Register  Login  Recent Posts

Information on DTN's Industries:
DTN Oil & Gas | DTN Trading | DTN Agriculture | DTN Weather
Follow DTNMarkets on Twitter
DTN.IQ/IQFeed on Twitter
DTN News and Analysis on Twitter
»Forums Index »IQFeed Developer »IQFeed Developer Support »Could not connect to History socket.
Author Topic: Could not connect to History socket. (9 messages, Page 1 of 1)

ericm
-DTN Evangelist-
Posts: 145
Joined: Mar 31, 2008


Posted: Dec 18, 2014 09:15 AM          Msg. 1 of 9
In my software, on startup, I go through the list of contracts I watch, and request missing history at various levels (day, minute, tick). Occasionally I get the message, "E,Could not connect to History socket." It appears sporadically amidst a succession of successful lookup requests/responses. It is hardly ever for the same contract or period.

Why do I get this message, and what can I do about it?

Eric

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


Posted: Dec 18, 2014 09:39 AM          Msg. 2 of 9
Hello Eric,

Could you send me a log that illustrates the issue? I will try and re-create what you are seeing here locally and see what I can come up with. But, all you could probably do, unto yourself, is re-request the data in this circumstance. At least, with what I know so far that is what I can offer.

Any info you could add about the request types, frequency, etc would be helpful, but I can get all that from the log as well if that would save you typing.

Tim

jimc
-Interested User-
Posts: 34
Joined: Jan 22, 2008


Posted: Dec 18, 2014 10:16 AM          Msg. 3 of 9
I was getting that error last evening, too. A few cycles of ensuring that IQConnect.exe was closed, then re-running my program did not fix it. I had the same problem with a short LinqPad script I use for testing as well. After running IQConnect.exe manually before starting my program, instead of letting the program start it, I was able to connect. The problem isn't happening at all for me this morning.

Jim

ericm
-DTN Evangelist-
Posts: 145
Joined: Mar 31, 2008


Posted: Dec 18, 2014 10:29 AM          Msg. 4 of 9
Tim,

Since I had never seen this error before, I don't have any code to log it to disk. I'll put something in today, but it may be tomorrow before I can get you results.

It happened again a few minutes ago on another startup. It occurred to me that it might be a connection problem, but IQFeed didn't report a disconnect, and the Connection Manager showed no Reconnections or Attempted Reconnections.

Thanks for the quick response.

Eric

ericm
-DTN Evangelist-
Posts: 145
Joined: Mar 31, 2008


Posted: Dec 18, 2014 06:06 PM          Msg. 5 of 9
Tim,

I added code to track my requests and IQFeed responses, but for a while I thought it was going to be a variant of the Heisenberg principle: observation changes the behavior. But on a restart this afternoon I got several examples (attached). One is an expired or expiring contract, but two are high-volume contracts. I'll appreciate hearing if there's something I am doing wrong. As I mentioned earlier, however, the majority of the requests succeed without this error. (Note that I have added a horizontal rule to separate the contracts, and in the successful responses an ellipsis [. . .] to shorten the file.)

Eric

ericm
-DTN Evangelist-
Posts: 145
Joined: Mar 31, 2008


Posted: Dec 19, 2014 10:12 AM          Msg. 6 of 9
Tim,

Put this one on hold for a bit; I may have found the source of the problem.

When I ran my software on a faster computer this morning, it appeared that some of the lookup data were getting processed out of order. Since I put all data in a queue as soon as it comes in, this seemed impossible. I have since traced the problem to a too-small lookup buffer; data were being truncated, not rearranged. Because we have upgraded our LAN and Internet speed lately, data are coming in and filling the buffer more quickly. I doubled the size of the buffer, and the problem disappeared. My suspicion is that this was also causing the problem connecting to the history socket, although it may take a day or so to make sure it too has gone away.

Eric

ericm
-DTN Evangelist-
Posts: 145
Joined: Mar 31, 2008


Posted: Dec 19, 2014 12:22 PM          Msg. 7 of 9
Unfortunately, the "Could not connect to History socket" is still with us.

Eric

DTN_Steve_S
-DTN Guru-
Posts: 2084
Joined: Nov 21, 2005


Posted: Dec 19, 2014 05:10 PM          Msg. 8 of 9
Eric, thanks for the update. I don't believe that there is going to be anything we can do to identify a cause of these errors since there is so much completely out of your or our control here.

The error message is returned anytime the socket connection to our servers fails the Connect call. History requests are not made on a persistent connection to our servers and we use TCP sockets for all connections to the server so it is entirely possible that you can get the error while the level 1 is still connected and receiving data. A brief failure somewhere between your machine and our servers could be masked in the persistent TCP connection for level1 while causing the connection failure in history at the same time.

The error certainly indicates something faulty (or overloaded) along the lines somewhere between your machine and our servers but unless we can track it down to a specific event that correlates to the errors, I highly doubt that we will figure out what is causing it. Of course there is a chance you would find the smoking gun, but with these types of errors, you could put literally hundreds of hours into tracking it down and still never find whats causing it.

As Tim mentioned, the best course of action at this time would be to handle the error and re-issue your request to the feed. You can even simply put in a retry loop to do it immediately until it succeeds. Since the request isn't making it to our servers when it fails, there is no chance for harm on our side with this sort of logic. My guess is that it would succeed on the very next request in almost all circumstances. Along with this, you may want to also track the errors to see if you can find a pattern and/or if they start increasing in frequency, you can decide when it becomes worth your time to dig deeper.

ericm
-DTN Evangelist-
Posts: 145
Joined: Mar 31, 2008


Posted: Dec 22, 2014 07:48 AM          Msg. 9 of 9
Steve,

Thanks for taking the time to explain the cause of this message. Understanding what's going on in the code behind sometimes-cryptic error messages is an immense help.

Best to you and Tim this holiday season.

Eric
 

 

Time: Sat August 15, 2020 2:47 PM CFBB v1.2.0 31 ms.
© AderSoftware 2002-2003