[ts-gen] cross session orders, client ids

[R P Herrold]

On Mon, 8 Dec 2008, Nils Gebhardt wrote:

>> ...  The kill.rb script runs with the "once" option, to 
>> ensure that both connections to the tws run with a 
>> predictable clientid, here the starting value of 8.

> ok - 'once' confines shim to id 8? Probably it is fine in 
> most cases to work with id 8, just for completeness: is it 
> possible to specify the client id before tws handshake in a 
> more general way?

'once' confines the shim to the value, if any, stated in the
 	.shimrc

The use of '8' by us for risk mode connections was just a 
local convention; 'once' will 'nail' a connection attempt to 
the value stated by the variable on the ~/.shimrc :

 	ClientId         8

The thinking behind the convention was to reserve the seven 
digits from 1 through 7 for data mode connections, and to 
avoid the use of the super-potent '0' client ID.  '8' just 
happens to be the next available digit ;)

> There seem to be problems [with version shim-081121] with 
> client id 8: after submitting an order, using id 8, I get 
> the following strange behavior:

> [20:47:47][~/T/TEST/shim-081121]
> n at gb07:$ ./shim --data

>          The trading shim has connected to the database server
>          and loaded 51649 products; connected to the IB tws as
>          client id  1; and queried for the account code, which
>          seems to be DU33186.  Program initialization has been
>          completed.

[you must have ended a session here, I cannot see how long, 
if any, a pause was used before attempting reconnection -- 
this may well be something unusual about the IB servers to 
which your local TWS connects being slower to release than 
ours ... puzzling]

> [20:48:05][~/T/TEST/shim-081121]
> n at gb07:$ ./shim --risk
>
>          The trading shim has connected to the database server
>          and loaded 51649 products; connected to the IB tws as
>          client id  8;
> Problem: 524 could not obtain IB account info at startup
> Exiting

I do not know that the version from 081121 varies materially 
from that of shim-081126.tgz but ruling out differences is one 
the first techniques I know of for debugging.  The database is 
unchanged between the 21st and the 26th versions and so in 
advance of Bill coming in, you may wish to try that.

> I don't see any need for concurrent order processing. If 
> consecutive access works, that is great.

We agree with you -- there is not a compelling 'general case' 
which we can devise for having more than one 'risk' connection 
(because if one has more than one, simply adding a 
super-client to arbitrate and remove possible conflicting 
strategy transaction elements is probably in order (and avoids 
race conditions and other negative synchronization problems.

Perhaps for 'failover', but in a local area network, ...

As you point out 'consecutive' is probably enough, given the 
ability to retrieve and reconcile open order status (which we 
attained in the recent releases)

Again. thank you for your feedback  -- it is really helpful 
for us.

- Russ herrold