same question as before. Will conditionalupon send permids?
Background: I am a bit puzzled by the fact that conditionalupon requires the autotrading client to manage stateful handling. The way the autotrade API works seems to allow an autotrade client that just manages the transfer of C2 signals to a broker to be stateless. But conditionalupon seems to be the only exception and blows the stateless concept out of the water.
Any signal received at any time could be, theoretically, conditional upon any earlier signal. So I will need to keep the state of all previously received signals in order to handle conditionalupon.
If you give a signal a permid, then any subsequent orders which are made conditional upon that signal will have the following field in the signalpacket XML:
<conditionaluponpermid>PERMID</conditionaluponpermid>
This is in addition to the <conditionalupon> field, which will also be delivered. The <conditionalupon> field uses Collective2’s signal id numbering scheme.
There are a few points to note.
Most times (but not all), conditional signals will appear in triads, all in one “latestsigs” polling cycle. The reason for this is that system vendors typically enter signals with stop-losses and profit-targets attached. In these cases, you will poll for latestsigs and get three signals, all at once: the entry signal (the “parent” signal), and then the stop-loss, and then the profit-target.
In these cases, you will not have had an opportunity to ack the parent signal, and so will not have had a chance to supply your own permid. So when signals appear in all-at-once triads, then only C2’s signal ids will be available. Depending on how you structure your code, this may or may not require stateful processing. (In the sense that, for at least one latestsigs cycle, you’ll need to keep C2’s numbering scheme in memory – that is, at least between the time you get the parent signal, and the time you process the 2 children signals. But once you ack the signals in question, you can provide permids, and then C2’s signal numbering scheme becomes irrelevant.)
When the C2ATI was developed, we did in fact process conditionals solely on the server side. In this architecture, developers did not need to keep any kind of state information when processing conditionals. Conditionals simply arrived on an as-needed basis.
This had a lot of downside, and a lot of risk. Keep in mind that children signals in conditional pairs are usually stop losses. Do you (or your customers) really want to rely on C2 server availability and timely processing of simulated orders for stop-losses? I sure wouldn’t. The problem is exacerbated by the fact that C2 is a market simulation – not a true market – and so we sometimes find out about fills some time after they have been filled in real life. Even if the lag is only 30 seconds or so, do you really want your customer to be exposed for those 30 seconds without a stop loss?
And so the safest course of action – and the most efficient from a processing point of view – is to let the your client software (or the 3rd-party service you are writing) handle conditionals by submitting them to the broker at the instant that parent fill notifications are received.
Admittedly this does increase programming complexity for C2 developers, but I think it’s warranted. -Matthew
