The Configuration Key-Value Pairs

The configuration keys known to the shim are listed as the second column of Figure 3.4. Each key has the default value hard-coded into the source code of the shim, and may also appear in a configuration file, in which case the default is overridden. The linkage parameters are also overridden via the dbms and feed commands if you use the init option.

Figure 3.4: Key-value names and defaults
\begin{figure}\begin{tabular}{\vert l\vert l\vert r\vert c\vert} \hline
Category...
... 20 & number \\
& {\tt FeedTime} & 3 & '' \\ \hline
\end{tabular}
\end{figure}

The DbmsName and FeedName values are currently limited to the default values, fixed as mysql and tws, respectively, can't be changed, and so may be ignored. They exist mainly as placeholders within the two link commands dbms and feed, so that the format of the commands allows for additional types of dbms and upstream market feed in the future.

The DbmsHost and FeedHost values are critical, since without a waiting database server and IB tws program at the indicated machine locations, the shim will quit. You may use either domain names or ip addresses, and if you have mysql and the IB tws running on the local machine, the default value of localhost is what you want.

The TableSet value determines which database you are asking the dbms server to give you access to, and if you have run the database setup script of § 3.3.2 as is, the possible values are testing and trading. The UserName chooses the account name within that database, and again, shim is an account name provided by the dbms setup script. You need not have a password for your database account unless you so choose -- the setup script does not select one -- and the default value of zero stands for no password.

The log file names are with respect to the current directory, and will be discussed furthur in § 3.4.3. Of the timeouts, the value of InitTime determines how long you are given to enter the dbms and feed commands if you use the init option to provide the link parameters, about which more in the next section, while the FeedTime timeout is considered as part of troubleshooting in § 3.6.

In Figure 3.4, the fourth column, labelled ``type'', indicates what kind of values may be provided; strings are sequences of non-blank but otherwise arbitrary characters, while the numbers used for timeouts must be non-empty digit strings with neither sign nor decimal point.

For those curious about the use of the string type for the IB tws port number, it is also possible to use a service name, an entry from /etc/services, as the value for the FeedPort key. If the entry name you choose is not already used in that file, and you have added an new entry at the end of the file, e.g., the line in Figure 3.5, then you could use the service name, here tws, for the FeedPort value.

Figure 3.5: A possible service entry for the IB tws in /etc/services
\begin{figure}\small
\begin{verbatim}...

Though possible, this is definitely not desirable for the individual user for reasons of security; why would you want to publicize access to your private IB account? It's conceivable that such a service-based approach might be of use on a corporate lan, with individual servers providing paper accounts as a published service, and the ports for real accounts being less well known. The administrators for such a system must understand the security issues involved in publicizing the IB tws port, and such configuration is not supported.

Bill Pippin 2009-01-02