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

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

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

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

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

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

Unfortunately, the "Could not connect to History socket" is still with us.

---

Eric

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.

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