Given the latency of requesting historical data on a per-port basis, it is necessary to spread requests over a number of ports and aggregate the results as highlighted in the post:

http://forums.iqfeed.net/index.cfm?page=topic&topicID=3193

When doing so, i am encountering an error response of "Too many simultaneous history requests.". The post referenced above indicated that there were no specific limits in place at that time. Clearly this has since changed, but I am unable to find out where this has been documented.

It's not clear from testing what specifically is triggering the response (e.g. rate limit on request submission, limit on outstanding number of requests, etc.) but it seems only loosely related to the number of connections. For example, it is triggered (sporadically) by simply requesting 100 day bars for 100 symbols using 10 connections.

Please provide details of the exact restrictions in place so that we may manage our requests to ensure they work.

Hello,

You can only have up to 15 simultaneous requests being processed on any one connection at any one time. You can either limit the number of requests that are sent at any one time, or on this kind of error, re-request the data again.

Tim

Hi Tim,

That doesn't concur with the results that I was seeing. Sending 100 requests over 20 connections in round-robin fashion (i.e 5 requests per connection) was triggering this error response.

Conversely, sending the same 100 requests over 5 connections (i.e. 20 requests per connection) does not trigger the error.

In both cases, the requests are all sent upfront before the first results come in.

I am unable to check again at the moment as the feed is currently in use, but I shall try to replicate over the weekend and revert. FWIW, I have a log of the 5 connection test, so I am certain of that result.

Cheers.
Edited by dk_brad on May 16, 2014 at 07:38 AM

I'll check with the server team, I may remember incorrectly, it could be 15 in total, not per connection, and let you know.

Tim

Sorry, it is 15 just connections and it should take care of this. I'll look into updating the documentation as well to cover this.

Tim
Edited by DTN_Tim Walter on May 16, 2014 at 08:13 AM

I still need some additional clarification here.

As I understand it, each IQConnect connection buffers requests locally and only sends a single to the server at a time (per connection). Since each connection processes requests in a serial fashion, is it safe to assume that there only ever be one outstanding request per connection under this definition? (I am assuming the restriction is on the server side, not the client side)

Looking at my prior example, sending 20 requests each to 5 connections doesn't trigger an error. I presume that IQConnect is only effectively processing 5 requests simultaneously.

If this is the case, then limiting the code to a maximum of 15 connections processing history requests at any one time would seem to be the solution.

EDIT:
This post doesn't make much sense post your edit. I see you've removed the 1 req/connection text so I'm guessing that it's just 15 connections and IQConnect will take care of buffering multiple requests per connection
Edited by dk_brad on May 16, 2014 at 08:20 AM
Edited by dk_brad on May 16, 2014 at 08:21 AM

Correct, my apologies.

Great, thanks.

I'd also be very keen to see possible error returns added to the documentation. It's a bit of a trial and error process at the moment, where new undocumented error returns are discovered and added to the list of possible received messages (e.g. this one, valid protocol already set, invalid # of params etc.)