Common Features

There is no record separator or terminator for either requests or messages, so that recovering from parse errors is nontrivial. The IB tws depends on a correct parse of the previous request to determine the record boundary, and such requests must therefor be correct in type and number. The shim, in contrast, includes logic to resynchronize the parser by discarding fields one at a time until a successful record match occurs. There is good reason why the tws and shim handle the problem of parse errors so differently, as safety dictates that the tws reject uncertain requests, to avoid malformed or incomplete orders, and that the shim seek to extract every last ounce of information from the event stream, in order to keep the downstream informed.

As a rule, parse errors do not occur with the upstream protocol languages except temporarily, after version updates. Although table driven design has been used to limit the effort required, the shim must sometimes be modified when the IB tws api version changes. In addition, on one occasion a (now obsolete and unavailable) release of tws was observed to garble messages, although a replacement release was available the same day we observed the problem.

Once stable operation has been achieved, however, I never see parse errors for supported request and message types. It is nevertheless the responsibility of the downstream client to watch the message stream and note the various error messages that might indicate that a parse error has occurred. Note that § [*] and § [*] following, in addition to describing the api request and message types, also indicate [*] that subset currently supported by the shim.

Bill Pippin 2010-01-14