Add working, template docker setup for `ib-gw`
Based on the now defunct project @ https://github.com/waytrade/ib-gateway-docker Adds a `docker-compose.yml` and necessary gateway and `IBC` config files to make it possible to spin up a local gateway on localhost:4002 and connect to it without issue using `ib_insync`. Next up, we'll want to, - automated the equivalent docker-compose steps using our `.data._ahab` supervisor system - probably simplify and roll our own container (likely alpine or nixos based) which drops uneeded deps (`socat`, vnc) and adds `xdotool`. - allow for API socket mapping to just be pulled direct from a user's `brokers.toml` and we'll just pass that direct to `IBC`'s config.dockerize_ib_gw
parent
9f47515f59
commit
a79a99fc71
|
@ -0,0 +1,51 @@
|
|||
# rework from the original @
|
||||
# https://github.com/waytrade/ib-gateway-docker/blob/master/docker-compose.yml
|
||||
version: "3.5"
|
||||
|
||||
services:
|
||||
ib-gateway:
|
||||
# other image tags available:
|
||||
# https://github.com/waytrade/ib-gateway-docker#supported-tags
|
||||
image: waytrade/ib-gateway:981.3j
|
||||
restart: always
|
||||
network_mode: 'host'
|
||||
|
||||
volumes:
|
||||
- type: bind
|
||||
source: ./jts.ini
|
||||
target: /root/Jts/jts.ini
|
||||
# don't let IBC clobber this file for
|
||||
# the main reason of not having a stupid
|
||||
# timezone set..
|
||||
read_only: true
|
||||
|
||||
# force our own IBC config
|
||||
- type: bind
|
||||
source: ./ibc.ini
|
||||
target: /root/ibc/config.ini
|
||||
|
||||
# force our noop script - socat isn't needed in host mode.
|
||||
- type: bind
|
||||
source: ./fork_ports_delayed.sh
|
||||
target: /root/scripts/fork_ports_delayed.sh
|
||||
|
||||
environment:
|
||||
TWS_USERID: ${TWS_USERID}
|
||||
TWS_PASSWORD: ${TWS_PASSWORD}
|
||||
TRADING_MODE: ${TRADING_MODE:-paper}
|
||||
VNC_SERVER_PASSWORD: ${VNC_SERVER_PASSWORD:-}
|
||||
|
||||
ports:
|
||||
- target: 4002
|
||||
host_ip: 127.0.0.1
|
||||
published: 4002
|
||||
protocol: tcp
|
||||
|
||||
# original mappings for use in non-host-mode
|
||||
# which we won't really need going forward since
|
||||
# ideally we just pick the port to have ib-gw listen
|
||||
# on **when** we spawn the container - i.e. everything
|
||||
# will be driven by a ``brokers.toml`` def.
|
||||
# - "127.0.0.1:4001:4001"
|
||||
# - "127.0.0.1:4002:4002"
|
||||
# - "127.0.0.1:5900:5900"
|
|
@ -0,0 +1,6 @@
|
|||
#!/bin/sh
|
||||
|
||||
# we now just set this is to a noop script
|
||||
# since we can just run the container in
|
||||
# `network_mode: 'host'` and get literally
|
||||
# the exact same behaviour XD
|
|
@ -0,0 +1,711 @@
|
|||
# Note that in the comments in this file, TWS refers to both the Trader
|
||||
# Workstation and the IB Gateway, unless explicitly stated otherwise.
|
||||
#
|
||||
# When referred to below, the default value for a setting is the value
|
||||
# assumed if either the setting is included but no value is specified, or
|
||||
# the setting is not included at all.
|
||||
#
|
||||
# IBC may also be used to start the FIX CTCI Gateway. All settings
|
||||
# relating to this have names prefixed with FIX.
|
||||
#
|
||||
# The IB API Gateway and the FIX CTCI Gateway share the same code. Which
|
||||
# gateway actually runs is governed by an option on the initial gateway
|
||||
# login screen. The FIX setting described under IBC Startup
|
||||
# Settings below controls this.
|
||||
|
||||
|
||||
|
||||
# =============================================================================
|
||||
# 1. IBC Startup Settings
|
||||
# =============================================================================
|
||||
|
||||
|
||||
# IBC may be used to start the IB Gateway for the FIX CTCI. This
|
||||
# setting must be set to 'yes' if you want to run the FIX CTCI gateway. The
|
||||
# default is 'no'.
|
||||
|
||||
FIX=no
|
||||
|
||||
|
||||
|
||||
# =============================================================================
|
||||
# 2. Authentication Settings
|
||||
# =============================================================================
|
||||
|
||||
# TWS and the IB API gateway require a single username and password.
|
||||
# You may specify the username and password using the following settings:
|
||||
#
|
||||
# IbLoginId
|
||||
# IbPassword
|
||||
#
|
||||
# Alternatively, you can specify the username and password in the command
|
||||
# files used to start TWS or the Gateway, but this is not recommended for
|
||||
# security reasons.
|
||||
#
|
||||
# If you don't specify them, you will be prompted for them in the usual
|
||||
# login dialog when TWS starts (but whatever you have specified will be
|
||||
# included in the dialog automatically: for example you may specify the
|
||||
# username but not the password, and then you will be prompted for the
|
||||
# password via the login dialog). Note that if you specify either
|
||||
# the username or the password (or both) in the command file, then
|
||||
# IbLoginId and IbPassword settings defined in this file are ignored.
|
||||
#
|
||||
#
|
||||
# The FIX CTCI gateway requires one username and password for FIX order
|
||||
# routing, and optionally a separate username and password for market
|
||||
# data connections. You may specify the usernames and passwords using
|
||||
# the following settings:
|
||||
#
|
||||
# FIXLoginId
|
||||
# FIXPassword
|
||||
# IbLoginId (optional - for market data connections)
|
||||
# IbPassword (optional - for market data connections)
|
||||
#
|
||||
# Alternatively you can specify the FIX username and password in the
|
||||
# command file used to start the FIX CTCI Gateway, but this is not
|
||||
# recommended for security reasons.
|
||||
#
|
||||
# If you don't specify them, you will be prompted for them in the usual
|
||||
# login dialog when FIX CTCI gateway starts (but whatever you have
|
||||
# specified will be included in the dialog automatically: for example
|
||||
# you may specify the usernames but not the passwords, and then you will
|
||||
# be prompted for the passwords via the login dialog). Note that if you
|
||||
# specify either the FIX username or the FIX password (or both) on the
|
||||
# command line, then FIXLoginId and FIXPassword settings defined in this
|
||||
# file are ignored; he same applies to the market data username and
|
||||
# password.
|
||||
|
||||
# IB API Authentication Settings
|
||||
# ------------------------------
|
||||
|
||||
# Your TWS username:
|
||||
|
||||
IbLoginId=
|
||||
|
||||
|
||||
# Your TWS password:
|
||||
|
||||
IbPassword=
|
||||
|
||||
|
||||
# FIX CTCI Authentication Settings
|
||||
# --------------------------------
|
||||
|
||||
# Your FIX CTCI username:
|
||||
|
||||
FIXLoginId=
|
||||
|
||||
|
||||
# Your FIX CTCI password:
|
||||
|
||||
FIXPassword=
|
||||
|
||||
|
||||
# Second Factor Authentication Settings
|
||||
# -------------------------------------
|
||||
|
||||
# If you have enabled more than one second factor authentication
|
||||
# device, TWS presents a list from which you must select the device
|
||||
# you want to use for this login. You can use this setting to
|
||||
# instruct IBC to select a particular item in the list on your
|
||||
# behalf. Note that you must spell this value exactly as it appears
|
||||
# in the list. If no value is set, you must manually select the
|
||||
# relevant list entry.
|
||||
|
||||
SecondFactorDevice=
|
||||
|
||||
|
||||
# If you use the IBKR Mobile app for second factor authentication,
|
||||
# and you fail to complete the process before the time limit imposed
|
||||
# by IBKR, you can use this setting to tell IBC to exit: arrangements
|
||||
# can then be made to automatically restart IBC in order to initiate
|
||||
# the login sequence afresh. Otherwise, manual intervention at TWS's
|
||||
# Second Factor Authentication dialog is needed to complete the
|
||||
# login.
|
||||
#
|
||||
# Permitted values are 'yes' and 'no'. The default is 'no'.
|
||||
#
|
||||
# Note that the scripts provided with the IBC zips for Windows and
|
||||
# Linux provide options to automatically restart in these
|
||||
# circumstances, but only if this setting is also set to 'yes'.
|
||||
|
||||
ExitAfterSecondFactorAuthenticationTimeout=no
|
||||
|
||||
|
||||
# This setting is only relevant if
|
||||
# ExitAfterSecondFactorAuthenticationTimeout is set to 'yes'.
|
||||
#
|
||||
# It controls how long (in seconds) IBC waits for login to complete
|
||||
# after the user acknowledges the second factor authentication
|
||||
# alert at the IBKR Mobile app. If login has not completed after
|
||||
# this time, IBC terminates.
|
||||
# The default value is 40.
|
||||
|
||||
SecondFactorAuthenticationExitInterval=
|
||||
|
||||
|
||||
# Trading Mode
|
||||
# ------------
|
||||
#
|
||||
# TWS 955 introduced a new Trading Mode combo box on its login
|
||||
# dialog. This indicates whether the live account or the paper
|
||||
# trading account corresponding to the supplied credentials is
|
||||
# to be used. The allowed values are 'live' (the default) and
|
||||
# 'paper'. For earlier versions of TWS this setting has no
|
||||
# effect.
|
||||
|
||||
TradingMode=
|
||||
|
||||
|
||||
# Paper-trading Account Warning
|
||||
# -----------------------------
|
||||
#
|
||||
# Logging in to a paper-trading account results in TWS displaying
|
||||
# a dialog asking the user to confirm that they are aware that this
|
||||
# is not a brokerage account. Until this dialog has been accepted,
|
||||
# TWS will not allow API connections to succeed. Setting this
|
||||
# to 'yes' (the default) will cause IBC to automatically
|
||||
# confirm acceptance. Setting it to 'no' will leave the dialog
|
||||
# on display, and the user will have to deal with it manually.
|
||||
|
||||
AcceptNonBrokerageAccountWarning=yes
|
||||
|
||||
|
||||
# Login Dialog Display Timeout
|
||||
#-----------------------------
|
||||
#
|
||||
# In some circumstances, starting TWS may result in failure to display
|
||||
# the login dialog. Restarting TWS may help to resolve this situation,
|
||||
# and IBC does this automatically.
|
||||
#
|
||||
# This setting controls how long (in seconds) IBC waits for the login
|
||||
# dialog to appear before restarting TWS.
|
||||
#
|
||||
# Note that in normal circumstances with a reasonably specified
|
||||
# computer the time to displaying the login dialog is typically less
|
||||
# than 20 seconds, and frequently much less. However many factors can
|
||||
# influence this, and it is unwise to set this value too low.
|
||||
#
|
||||
# The default value is 60.
|
||||
|
||||
LoginDialogDisplayTimeout = 60
|
||||
|
||||
|
||||
|
||||
# =============================================================================
|
||||
# 3. TWS Startup Settings
|
||||
# =============================================================================
|
||||
|
||||
# Path to settings store
|
||||
# ----------------------
|
||||
#
|
||||
# Path to the directory where TWS should store its settings. This is
|
||||
# normally the folder in which TWS is installed. However you may set
|
||||
# it to some other location if you wish (for example if you want to
|
||||
# run multiple instances of TWS with different settings).
|
||||
#
|
||||
# It is recommended for clarity that you use an absolute path. The
|
||||
# effect of using a relative path is undefined.
|
||||
#
|
||||
# Linux and macOS users should use the appropriate path syntax.
|
||||
#
|
||||
# Note that, for Windows users, you MUST use double separator
|
||||
# characters to separate the elements of the folder path: for
|
||||
# example, IbDir=C:\\IBLiveSettings is valid, but
|
||||
# IbDir=C:\IBLiveSettings is NOT valid and will give unexpected
|
||||
# results. Linux and macOS users need not use double separators,
|
||||
# but they are acceptable.
|
||||
#
|
||||
# The default is the current working directory when IBC is
|
||||
# started.
|
||||
|
||||
IbDir=/root/Jts
|
||||
|
||||
|
||||
# Store settings on server
|
||||
# ------------------------
|
||||
#
|
||||
# If you wish to store a copy of your TWS settings on IB's
|
||||
# servers as well as locally on your computer, set this to
|
||||
# 'yes': this enables you to run TWS on different computers
|
||||
# with the same configuration, market data lines, etc. If set
|
||||
# to 'no', running TWS on different computers will not share the
|
||||
# same settings. If no value is specified, TWS will obtain its
|
||||
# settings from the same place as the last time this user logged
|
||||
# in (whether manually or using IBC).
|
||||
|
||||
StoreSettingsOnServer=
|
||||
|
||||
|
||||
# Minimize TWS on startup
|
||||
# -----------------------
|
||||
#
|
||||
# Set to 'yes' to minimize TWS when it starts:
|
||||
|
||||
MinimizeMainWindow=no
|
||||
|
||||
|
||||
# Existing Session Detected Action
|
||||
# --------------------------------
|
||||
#
|
||||
# When a user logs on to an IBKR account for trading purposes by any means, the
|
||||
# IBKR account server checks to see whether the account is already logged in
|
||||
# elsewhere. If so, a dialog is displayed to both the users that enables them
|
||||
# to determine what happens next. The 'ExistingSessionDetectedAction' setting
|
||||
# instructs TWS how to proceed when it displays this dialog:
|
||||
#
|
||||
# * If the new TWS session is set to 'secondary', the existing session continues
|
||||
# and the new session terminates. Thus a secondary TWS session can never
|
||||
# override any other session.
|
||||
#
|
||||
# * If the existing TWS session is set to 'primary', the existing session
|
||||
# continues and the new session terminates (even if the new session is also
|
||||
# set to primary). Thus a primary TWS session can never be overridden by
|
||||
# any new session).
|
||||
#
|
||||
# * If both the existing and the new TWS sessions are set to 'primaryoverride',
|
||||
# the existing session terminates and the new session proceeds.
|
||||
#
|
||||
# * If the existing TWS session is set to 'manual', the user must handle the
|
||||
# dialog.
|
||||
#
|
||||
# The difference between 'primary' and 'primaryoverride' is that a
|
||||
# 'primaryoverride' session can be overriden over by a new 'primary' session,
|
||||
# but a 'primary' session cannot be overriden by any other session.
|
||||
#
|
||||
# When set to 'primary', if another TWS session is started and manually told to
|
||||
# end the 'primary' session, the 'primary' session is automatically reconnected.
|
||||
#
|
||||
# The default is 'manual'.
|
||||
|
||||
ExistingSessionDetectedAction=primary
|
||||
|
||||
|
||||
# Override TWS API Port Number
|
||||
# ----------------------------
|
||||
#
|
||||
# If OverrideTwsApiPort is set to an integer, IBC changes the
|
||||
# 'Socket port' in TWS's API configuration to that number shortly
|
||||
# after startup. Leaving the setting blank will make no change to
|
||||
# the current setting. This setting is only intended for use in
|
||||
# certain specialized situations where the port number needs to
|
||||
# be set dynamically at run-time: most users will never need it,
|
||||
# so don't use it unless you know you need it.
|
||||
|
||||
OverrideTwsApiPort=4002
|
||||
|
||||
|
||||
# Read-only Login
|
||||
# ---------------
|
||||
#
|
||||
# If ReadOnlyLogin is set to 'yes', and the user is enrolled in IB's
|
||||
# account security programme, the user will not be asked to perform
|
||||
# the second factor authentication action, and login to TWS will
|
||||
# occur automatically in read-only mode: in this mode, placing or
|
||||
# managing orders is not allowed. If set to 'no', and the user is
|
||||
# enrolled in IB's account security programme, the user must perform
|
||||
# the relevant second factor authentication action to complete the
|
||||
# login.
|
||||
|
||||
# If the user is not enrolled in IB's account security programme,
|
||||
# this setting is ignored. The default is 'no'.
|
||||
|
||||
ReadOnlyLogin=no
|
||||
|
||||
|
||||
# Read-only API
|
||||
# -------------
|
||||
#
|
||||
# If ReadOnlyApi is set to 'yes', API programs cannot submit, modify
|
||||
# or cancel orders. If set to 'no', API programs can do these things.
|
||||
# If not set, the existing TWS/Gateway configuration is unchanged.
|
||||
# NB: this setting is really only supplied for the benefit of new TWS
|
||||
# or Gateway instances that are being automatically installed and
|
||||
# started without user intervention (eg Docker containers). Where
|
||||
# a user is involved, they should use the Global Configuration to
|
||||
# set the relevant checkbox (this only needs to be done once) and
|
||||
# not provide a value for this setting.
|
||||
|
||||
ReadOnlyApi=no
|
||||
|
||||
|
||||
# Market data size for US stocks - lots or shares
|
||||
# -----------------------------------------------
|
||||
#
|
||||
# Since IB introduced the option of market data for US stocks showing
|
||||
# bid, ask and last sizes in shares rather than lots, TWS and Gateway
|
||||
# display a dialog immediately after login notifying the user about
|
||||
# this and requiring user input before allowing market data to be
|
||||
# accessed. The user can request that the dialog not be shown again.
|
||||
#
|
||||
# It is recommended that the user should handle this dialog manually
|
||||
# rather than using these settings, which are provided for situations
|
||||
# where the user interface is not easily accessible, or where user
|
||||
# settings are not preserved between sessions (eg some Docker images).
|
||||
#
|
||||
# - If this setting is set to 'accept', the dialog will be handled
|
||||
# automatically and the option to not show it again will be
|
||||
# selected.
|
||||
#
|
||||
# Note that in this case, the only way to allow the dialog to be
|
||||
# displayed again is to manually enable the 'Bid, Ask and Last
|
||||
# Size Display Update' message in the 'Messages' section of the TWS
|
||||
# configuration dialog. So you should only use 'Accept' if you are
|
||||
# sure you really don't want the dialog to be displayed again, or
|
||||
# you have easy access to the user interface.
|
||||
#
|
||||
# - If set to 'defer', the dialog will be handled automatically (so
|
||||
# that market data will start), but the option to not show it again
|
||||
# will not be selected, and it will be shown again after the next
|
||||
# login.
|
||||
#
|
||||
# - If set to 'ignore', the user has to deal with the dialog manually.
|
||||
#
|
||||
# The default value is 'ignore'.
|
||||
#
|
||||
# Note if set to 'accept' or 'defer', TWS also automatically sets
|
||||
# the API settings checkbox labelled 'Send market data in lots for
|
||||
# US stocks for dual-mode API clients'. IBC cannot prevent this.
|
||||
# However you can change this immmediately by setting
|
||||
# SendMarketDataInLotsForUSstocks (see below) to 'no' .
|
||||
|
||||
AcceptBidAskLastSizeDisplayUpdateNotification=accept
|
||||
|
||||
|
||||
# This setting determines whether the API settings checkbox labelled
|
||||
# 'Send market data in lots for US stocks for dual-mode API clients'
|
||||
# is set or cleared. If set to 'yes', the checkbox is set. If set to
|
||||
# 'no' the checkbox is cleared. If defaulted, the checkbox is
|
||||
# unchanged.
|
||||
|
||||
SendMarketDataInLotsForUSstocks=
|
||||
|
||||
|
||||
|
||||
# =============================================================================
|
||||
# 4. TWS Auto-Closedown
|
||||
# =============================================================================
|
||||
#
|
||||
# IMPORTANT NOTE: Starting with TWS 974, this setting no longer
|
||||
# works properly, because IB have changed the way TWS handles its
|
||||
# autologoff mechanism.
|
||||
#
|
||||
# You should now configure the TWS autologoff time to something
|
||||
# convenient for you, and restart IBC each day.
|
||||
#
|
||||
# Alternatively, discontinue use of IBC and use the auto-relogin
|
||||
# mechanism within TWS 974 and later versions (note that the
|
||||
# auto-relogin mechanism provided by IB is not available if you
|
||||
# use IBC).
|
||||
|
||||
# Set to yes or no (lower case).
|
||||
#
|
||||
# yes means allow TWS to shut down automatically at its
|
||||
# specified shutdown time, which is set via the TWS
|
||||
# configuration menu.
|
||||
#
|
||||
# no means TWS never shuts down automatically.
|
||||
#
|
||||
# NB: IB recommends that you do not keep TWS running
|
||||
# continuously. If you set this setting to 'no', you may
|
||||
# experience incorrect TWS operation.
|
||||
#
|
||||
# NB: the default for this setting is 'no'. Since this will
|
||||
# only work properly with TWS versions earlier than 974, you
|
||||
# should explicitly set this to 'yes' for version 974 and later.
|
||||
|
||||
IbAutoClosedown=yes
|
||||
|
||||
|
||||
|
||||
# =============================================================================
|
||||
# 5. TWS Tidy Closedown Time
|
||||
# =============================================================================
|
||||
#
|
||||
# NB: starting with TWS 974 this is no longer a useful option
|
||||
# because both TWS and Gateway now have the same auto-logoff
|
||||
# mechanism, and IBC can no longer avoid this.
|
||||
#
|
||||
# Note that giving this setting a value does not change TWS's
|
||||
# auto-logoff in any way: any setting will be additional to the
|
||||
# TWS auto-logoff.
|
||||
#
|
||||
# To tell IBC to tidily close TWS at a specified time every
|
||||
# day, set this value to <hh:mm>, for example:
|
||||
# ClosedownAt=22:00
|
||||
#
|
||||
# To tell IBC to tidily close TWS at a specified day and time
|
||||
# each week, set this value to <dayOfWeek hh:mm>, for example:
|
||||
# ClosedownAt=Friday 22:00
|
||||
#
|
||||
# Note that the day of the week must be specified using your
|
||||
# default locale. Also note that Java will only accept
|
||||
# characters encoded to ISO 8859-1 (Latin-1). This means that
|
||||
# if the day name in your default locale uses any non-Latin-1
|
||||
# characters you need to encode them using Unicode escapes
|
||||
# (see http://java.sun.com/docs/books/jls/third_edition/html/lexical.html#3.3
|
||||
# for details). For example, to tidily close TWS at 12:00 on
|
||||
# Saturday where the default locale is Simplified Chinese,
|
||||
# use the following:
|
||||
# #ClosedownAt=\u661F\u671F\u516D 12:00
|
||||
|
||||
ClosedownAt=
|
||||
|
||||
|
||||
|
||||
# =============================================================================
|
||||
# 6. Other TWS Settings
|
||||
# =============================================================================
|
||||
|
||||
# Accept Incoming Connection
|
||||
# --------------------------
|
||||
#
|
||||
# If set to 'accept', IBC automatically accepts incoming
|
||||
# API connection dialogs. If set to 'reject', IBC
|
||||
# automatically rejects incoming API connection dialogs. If
|
||||
# set to 'manual', the user must decide whether to accept or reject
|
||||
# incoming API connection dialogs. The default is 'manual'.
|
||||
# NB: it is recommended to set this to 'reject', and to explicitly
|
||||
# configure which IP addresses can connect to the API in TWS's API
|
||||
# configuration page, as this is much more secure (in this case, no
|
||||
# incoming API connection dialogs will occur for those IP addresses).
|
||||
|
||||
AcceptIncomingConnectionAction=reject
|
||||
|
||||
|
||||
# Allow Blind Trading
|
||||
# -------------------
|
||||
#
|
||||
# If you attempt to place an order for a contract for which
|
||||
# you have no market data subscription, TWS displays a dialog
|
||||
# to warn you against such blind trading.
|
||||
#
|
||||
# yes means the dialog is dismissed as though the user had
|
||||
# clicked the 'Ok' button: this means that you accept
|
||||
# the risk and want the order to be submitted.
|
||||
#
|
||||
# no means the dialog remains on display and must be
|
||||
# handled by the user.
|
||||
|
||||
AllowBlindTrading=yes
|
||||
|
||||
|
||||
# Save Settings on a Schedule
|
||||
# ---------------------------
|
||||
#
|
||||
# You can tell TWS to automatically save its settings on a schedule
|
||||
# of your choosing. You can specify one or more specific times,
|
||||
# like this:
|
||||
#
|
||||
# SaveTwsSettingsAt=HH:MM [ HH:MM]...
|
||||
#
|
||||
# for example:
|
||||
# SaveTwsSettingsAt=08:00 12:30 17:30
|
||||
#
|
||||
# Or you can specify an interval at which settings are to be saved,
|
||||
# optionally starting at a specific time and continuing until another
|
||||
# time, like this:
|
||||
#
|
||||
#SaveTwsSettingsAt=Every n [{mins | hours}] [hh:mm] [hh:mm]
|
||||
#
|
||||
# where the first hh:mm is the start time and the second is the end
|
||||
# time. If you don't specify the end time, settings are saved regularly
|
||||
# from the start time till midnight. If you don't specify the start time.
|
||||
# settings are saved regularly all day, beginning at 00:00. Note that
|
||||
# settings will always be saved at the end time, even if that is not
|
||||
# exactly one interval later than the previous time. If neither 'mins'
|
||||
# nor 'hours' is specified, 'mins' is assumed. Examples:
|
||||
#
|
||||
# To save every 30 minutes all day starting at 00:00
|
||||
#SaveTwsSettingsAt=Every 30
|
||||
#SaveTwsSettingsAt=Every 30 mins
|
||||
#
|
||||
# To save every hour starting at 08:00 and ending at midnight
|
||||
#SaveTwsSettingsAt=Every 1 hours 08:00
|
||||
#SaveTwsSettingsAt=Every 1 hours 08:00 00:00
|
||||
#
|
||||
# To save every 90 minutes starting at 08:00 up to and including 17:43
|
||||
#SaveTwsSettingsAt=Every 90 08:00 17:43
|
||||
|
||||
SaveTwsSettingsAt=
|
||||
|
||||
|
||||
|
||||
# =============================================================================
|
||||
# 7. Settings Specific to Indian Versions of TWS
|
||||
# =============================================================================
|
||||
|
||||
# Indian versions of TWS may display a password expiry
|
||||
# notification dialog and a NSE Compliance dialog. These can be
|
||||
# dismissed by setting the following to yes. By default the
|
||||
# password expiry notice is not dismissed, but the NSE Compliance
|
||||
# notice is dismissed.
|
||||
|
||||
# Warning: setting DismissPasswordExpiryWarning=yes will mean
|
||||
# you will not be notified when your password is about to expire.
|
||||
# You must then take other measures to ensure that your password
|
||||
# is changed within the expiry period, otherwise IBC will
|
||||
# not be able to login successfully.
|
||||
|
||||
DismissPasswordExpiryWarning=no
|
||||
DismissNSEComplianceNotice=yes
|
||||
|
||||
|
||||
|
||||
# =============================================================================
|
||||
# 8. IBC Command Server Settings
|
||||
# =============================================================================
|
||||
|
||||
# Do NOT CHANGE THE FOLLOWING SETTINGS unless you
|
||||
# intend to issue commands to IBC (for example
|
||||
# using telnet). Note that these settings have nothing to
|
||||
# do with running programs that use the TWS API.
|
||||
|
||||
# Command Server Port Number
|
||||
# --------------------------
|
||||
#
|
||||
# The port number that IBC listens on for commands
|
||||
# such as "STOP". DO NOT set this to the port number
|
||||
# used for TWS API connections. There is no good reason
|
||||
# to change this setting unless the port is used by
|
||||
# some other application (typically another instance of
|
||||
# IBC). The default value is 0, which tells IBC not to
|
||||
# start the command server
|
||||
|
||||
#CommandServerPort=7462
|
||||
|
||||
|
||||
# Permitted Command Sources
|
||||
# -------------------------
|
||||
#
|
||||
# A comma separated list of IP addresses, or host names,
|
||||
# which are allowed addresses for sending commands to
|
||||
# IBC. Commands can always be sent from the
|
||||
# same host as IBC is running on.
|
||||
|
||||
ControlFrom=
|
||||
|
||||
|
||||
# Address for Receiving Commands
|
||||
# ------------------------------
|
||||
#
|
||||
# Specifies the IP address on which the Command Server
|
||||
# is so listen. For a multi-homed host, this can be used
|
||||
# to specify that connection requests are only to be
|
||||
# accepted on the specified address. The default is to
|
||||
# accept connection requests on all local addresses.
|
||||
|
||||
BindAddress=
|
||||
|
||||
|
||||
# Command Prompt
|
||||
# --------------
|
||||
#
|
||||
# The specified string is output by the server when
|
||||
# the connection is first opened and after the completion
|
||||
# of each command. This can be useful if sending commands
|
||||
# using an interactive program such as telnet. The default
|
||||
# is that no prompt is output.
|
||||
# For example:
|
||||
#
|
||||
# CommandPrompt=>
|
||||
|
||||
CommandPrompt=
|
||||
|
||||
|
||||
# Suppress Command Server Info Messages
|
||||
# -------------------------------------
|
||||
#
|
||||
# Some commands can return intermediate information about
|
||||
# their progress. This setting controls whether such
|
||||
# information is sent. The default is that such information
|
||||
# is not sent.
|
||||
|
||||
SuppressInfoMessages=no
|
||||
|
||||
|
||||
|
||||
# =============================================================================
|
||||
# 9. Diagnostic Settings
|
||||
# =============================================================================
|
||||
#
|
||||
# IBC can log information about the structure of windows
|
||||
# displayed by TWS. This information is useful when adding
|
||||
# new features to IBC or when behaviour is not as expected.
|
||||
#
|
||||
# The logged information shows the hierarchical organisation
|
||||
# of all the components of the window, and includes the
|
||||
# current values of text boxes and labels.
|
||||
#
|
||||
# Note that this structure logging has a small performance
|
||||
# impact, and depending on the settings can cause the logfile
|
||||
# size to be significantly increased. It is therefore
|
||||
# recommended that the LogStructureWhen setting be set to
|
||||
# 'never' (the default) unless there is a specific reason
|
||||
# that this information is needed.
|
||||
|
||||
|
||||
# Scope of Structure Logging
|
||||
# --------------------------
|
||||
#
|
||||
# The LogStructureScope setting indicates which windows are
|
||||
# eligible for structure logging:
|
||||
#
|
||||
# - if set to 'known', only windows that IBC recognizes
|
||||
# are eligible - these are windows that IBC has some
|
||||
# interest in monitoring, usually to take some action
|
||||
# on the user's behalf;
|
||||
#
|
||||
# - if set to 'unknown', only windows that IBC does not
|
||||
# recognize are eligible. Most windows displayed by
|
||||
# TWS fall into this category;
|
||||
#
|
||||
# - if set to 'untitled', only windows that IBC does not
|
||||
# recognize and that have no title are eligible. These
|
||||
# are usually message boxes or similar small windows,
|
||||
#
|
||||
# - if set to 'all', then every window displayed by TWS
|
||||
# is eligible.
|
||||
#
|
||||
# The default value is 'known'.
|
||||
|
||||
LogStructureScope=all
|
||||
|
||||
|
||||
# When to Log Window Structure
|
||||
# ----------------------------
|
||||
#
|
||||
# The LogStructureWhen setting specifies the circumstances
|
||||
# when eligible TWS windows have their structure logged:
|
||||
#
|
||||
# - if set to 'open' or 'yes' or 'true', IBC logs the
|
||||
# structure of an eligible window the first time it
|
||||
# is encountered;
|
||||
#
|
||||
# - if set to 'activate', the structure is logged every
|
||||
# time an eligible window is made active;
|
||||
#
|
||||
# - if set to 'never' or 'no' or 'false', structure
|
||||
# information is never logged.
|
||||
#
|
||||
# The default value is 'never'.
|
||||
|
||||
LogStructureWhen=never
|
||||
|
||||
|
||||
# DEPRECATED SETTING
|
||||
# ------------------
|
||||
#
|
||||
# LogComponents - THIS SETTING WILL BE REMOVED IN A FUTURE
|
||||
# RELEASE
|
||||
#
|
||||
# If LogComponents is set to any value, this is equivalent
|
||||
# to setting LogStructureWhen to that same value and
|
||||
# LogStructureScope to 'all': the actual values of those
|
||||
# settings are ignored. The default is that the values
|
||||
# of LogStructureScope and LogStructureWhen are honoured.
|
||||
|
||||
#LogComponents=
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,33 @@
|
|||
[IBGateway]
|
||||
ApiOnly=true
|
||||
LocalServerPort=4002
|
||||
# NOTE: must be set if using IBC's "reject" mode
|
||||
TrustedIPs=127.0.0.1
|
||||
; RemoteHostOrderRouting=ndc1.ibllc.com
|
||||
; WriteDebug=true
|
||||
; RemotePortOrderRouting=4001
|
||||
; useRemoteSettings=false
|
||||
; tradingMode=p
|
||||
; Steps=8
|
||||
; colorPalletName=dark
|
||||
|
||||
# window geo, this may be useful for sending `xdotool` commands?
|
||||
; MainWindow.Width=1986
|
||||
; screenHeight=3960
|
||||
|
||||
|
||||
[Logon]
|
||||
Locale=en
|
||||
# most markets are oriented around this zone
|
||||
# so might as well hard code it.
|
||||
TimeZone=America/Toronto
|
||||
UseSSL=true
|
||||
displayedproxymsg=1
|
||||
os_titlebar=true
|
||||
s3store=true
|
||||
useRemoteSettings=false
|
||||
|
||||
[Communication]
|
||||
ctciAutoEncrypt=true
|
||||
Region=usr
|
||||
; Peer=cdc1.ibllc.com:4001
|
Loading…
Reference in New Issue