I’ve added C2 signal entry code to an autotrading program and have a question or two about how to handle WebRequest timeouts.
It’s clear that C2’s responses are going to be slower during high volume times like the open and close, so the server response times will stretch out. Do you have any guidelines for what timeout value to use at the high-traffic times. I found some transactions going beyond 10 seconds response time this morning.
Then, if a buy/sell signal times out, what is the correct recovery logic. Can I “assume” that signal was dropped, or do I then have to investigate all signals to see if it was posted and just not replied in a timely fashion? I read through the Signal Entry document and it doesn’t discuss this topic.
Thanks,
Andy
I see exactly the same problem. I ping the server every 7 seconds or more, as instructed by the appropiate XML node.
At least 5-10 times a day one of my web requests dies (times out, server not reachable). What I do… I wait for 7 seconds, retry again. If not, wait for 72. If not, wait for 72*2, retry again, etc.
I do this to avoid hyperconnecting to the server when is clearly down (weekends), and it recovers eventually when it comes back.
If this happens during the trading day (e.g. the server is unavailable for a short period of time) this is my understanding of what happens:
by the time the server is back, if the order was a market order and it has been less than 10 minutes, it should still be there (if it came back)
However, if the order was a stop/limit and it was filled during the downtime… I am afraid your client will never receive the order (again, based on what I can experience)
That would indicate that you better reconnect as soon as possible (again, without spamming the server I’d think), and hope it doesn’t go down for extended periods of time during trading hours
Matthew could probably give you additional insights
Angelo,
Thanks for for comments. Yes, I use TradeBullet and see the ATI polling timeout several times a day. My problem/question is a little different in that it is about the signal entry protocol. Signal entry is not “connected”, there is no session between my software and theirs. Instead, signal entry says to send a POST message and then wait for a confirmation in their reply.
The C2 servers are acting like they are overloaded and are unable to handle the load when the markets get busy. I understand. I just need to know the correct logic flow to recover from one of these timeouts.
Just waiting for Matthew’s input.
Hi, Guys -
As Andy points out, there are two different cases we need to discuss: the first is an API request that posts a new signal into C2 (let’s call that the “Signal API”, which by the way, can be found here: http://www.collective2.com/content/automation.htm ). Then there’s the the C2 AutoTrade Interface (C2ATI) which is used to poll for new signals, cancels, or fills from trading systems that the user is subscribed to. (Found here: http://www.collective2.com/static/C2ATIcover.htm )
The first inputs data into C2; the second takes data out.
It is true that there can be request timeouts. Let me caveat this entire post by saying that, while I am discussing how to “handle” timeouts, that doesn’t mean I’m delighted there are any. Indeed, we spend a lot of resources (in both the design of the software behind the scenes, and the money spent on the hardware where it runs) to try to minimize circumstances where API requests are not answered in a timely fashion (or at all).
Now, that said, let’s talk about how to handle these time-outs. Regarding a timeout during signal entry, the problem in theory is eminently solvable, because whenever you input a signal into C2, you should almost immediately receive a confirmation back. A typical response to a signal entry looks something like this:
<collective2>
<ack>Signal Received</ack>
<status>OK</status>
<signalid>53275462</signalid>
<comments>Signal 53275462 accepted for immediate processing.</comments>
<oca></oca>
<delay></delay>
</collective2>
The implication here is that if your request actually times out, or returns some valid XML that is not an OK status, then you know your program should try again. You might want to wait a bit, since what’s likely happening is a server going down briefly and then being brought back up.
Regarding the C2ATI, the case is different. Since you’re polling for new information, as opposed to inserting your own information, what you want to be assured is that you do not “miss” anything important.
Here, the protocol and behavior was designed to minimize this possibility. Specifically, new signal information will be repeated by the C2 server until you specifically acknowledge it, or until it no longer becomes “actionable.” What this concretely means is that limit and stop orders (that is, orders that are designed to be “working” in the market for some time) will continue to be repeated until they are executed or they cancel/expire. Market orders are repeated for approximately 10 minutes. The idea here is that, while you want to be reasonably sure that you don’t miss an order, you surely don’t want to act on a market order that is more than a few minutes old.
But of course, under the scenario above, it is possible to miss a signal. That is why a really robust C2ATI client software package will supplement fill and signal information with position “syncing” (see the “sync layer” protocol in the C2ATI doc) or even by requesting more complete signal and trade history using the signalstatus command or the C2 Data Services API.
I can’t pretend that the protocol design is perfect and completely robust. Frankly – like all things that grow up over time, developed in response to real-world use – it’s a bit of a mess: functionality scattered across various APIs, some glaring holes. But by and large, it’s possible to piece together a fairly robust piece of software by combining the signal polling and the position polling.
Regarding request timeouts: Particularly when we discuss the C2ATI, request timeouts should be infrequent. If you find this is not the case, please let me know so that I can look into trying to improve the situation, either through beefing up the software or hardware that’s handling the APIs.
If there is a more specific question to which you are still seeking the answer, please let me know.
Matthew
