xtquant_big_convert: an RPC bridge that lets external Python drive Big QMT through MiniQMT method names

The gap xtquant_big_convert fills between Big QMT and outside code

Big QMT keeps its market data, trading and position APIs inside its own embedded Python. Getting another process to call them normally means XtQuantServer permissions. This project takes the opposite route: it runs a bridge inside the Big QMT environment and turns those calls into a remote service, then adds a compatibility layer that answers to MiniQMT method names so existing MiniQMT code can be pointed at it.

The audience is narrow and specific. You need a licensed Big QMT terminal, a Windows machine that can write into QMT's python directory, and a strategy or dashboard process that lives somewhere else. The README points at bigqmt-dashboard as an example of a full application built on the bridge, which is a multi-account position monitor and order panel. If your code already runs inside QMT's own Python, the bridge adds a network hop and buys you nothing.

Five transports, one whitelist, and a client that speaks two dialects

The mechanism is a method whitelist reached over a pluggable transport. The README lists 137 read-only methods plus three order methods (submit_order, submit_orders_batch, cancel_order) plus MiniQMT-style aliases. Transport is redis, zmq, named pipe, MySQL or shared memory, and the README states that switching is a single config field.

The client side is split by intent. Market and reference data are wrapped on a compatibility class called BigQmtXtData under the same names as the RPC table, so xtdata.get_open_date("600519.SH") works directly. Account, order and trade calls go through xt_trader using MiniQMT names instead: get_asset maps to query_stock_asset(account), get_positions to query_stock_positions, submit_order to order_stock. Methods without a same-name wrapper, such as get_ETF_list, ping or sync_positions, go through a generic entry point: xtdata.call_method("get_ETF_list") or xt_trader.client.call("<method>", {...}).

The design choice worth noticing is how the project handles methods that answer with junk. get_stock_type returns 0 on the tested terminal and get_turn_over_rate returns None for five codes across three formats. Rather than pass those values through, the wrappers raise NotImplementedError and describe the observed result and an alternative calculation. get_contract_multiplier works the other way: it errors only when the answer equals the int32 sentinel 2147483647, and the README admits there was no futures data on that terminal, so the passing case is untested. That is an honest boundary, and it is also a warning that a whitelist entry does not guarantee a usable answer.

Installing the client and running the config wizard

The package is on PyPI and the client side is a single install. The README gives this as the one-line client install:

pip install xtquant-big-convert

Deployment is described in docs/DEPLOY_QUICKSTART.md, and the wizard is step 2 of that flow. It replaces hand-copying two .example.py files. Run it on the machine that can write to QMT's python directory:

bigqmt-init

If the console script is not on PATH, or you are working from a source checkout, the README gives the equivalent module invocation:

python -m bigqmt_signal_trader.init_config

The wizard is interactive only. It cannot be fed through a pipe because the password prompt uses getpass to read the terminal. It asks for the fund account, account type, transport (redis or zmq), address and port, Redis username and password, whether remote ordering is allowed, the deployment mode, and two directories. From that one set of answers it writes both sides of the connection so the parameters cannot drift apart. The server config file is bigqmt_signal_trader_local_config.py, written into QMT's python directory. The client file is bigqmt_signal_trader_client_config.py, written to the directory you specify. A third file, BIGQMT_*_ALL_IN_ONE.py, is generated only if you choose single-file deployment, with the config already baked in.

The question people get wrong is the prompt for QMT's python directory. Pressing Enter writes to your current directory, and the server will not find its config at startup. The other trap is scope: in the default package deployment the wizard writes config only and copies no packages. The printed instruction to sync the packages under src/ applies to a source checkout; a pip install has no src/, so you follow step 3 of the quick start to locate the package and copy the four items. Single-file mode is already in place after the wizard runs. Existing files are not overwritten silently; the wizard asks first, and --force skips the question.

Order methods are off, and the wizard says so plainly

rpc_allow_order_methods defaults to False. The README states that before it is enabled the wizard warns explicitly that any program able to connect to the channel can submit orders. That is the correct default for a bridge whose transport may be a Redis instance reachable from more than one host, and it also means the project is not a drop-in replacement for a MiniQMT trading script until you change that setting deliberately.

The Redis path carries a second failure mode the maintainers document themselves. RPC requests are sent with RPUSH, and RPUSH is not idempotent. The redis-py retry wrapper covers send plus read of the reply, so if the server accepted the request and only the reply was lost, the same RPUSH is re-sent and one order can be dispatched twice (issue #245). The README notes the server has deduplicated by request_id since 0.3.29, and that redis-py 8.x raised the default retry count from 3 to 10 and changed the protocol default. The project pins redis to >=5.0.0,<8.0.0 and states that 5.2.1, 6.4.0 and 7.4.0 all default protocol to 2. Server-side deduplication is the mitigation; the version pin is the belt to that suspenders.

A third constraint is the fallback family marked with an asterisk. On a full Big QMT terminal, get_sector_list, get_holidays, get_markets and get_market_last_trade_date are implemented as fallbacks rather than native data. get_sector_list no longer returns a fallback list silently: it raises when the terminal's real sectors are unavailable, and you must pass allow_fallback=True to get the 13 common sector names. Issue #143 is the reason given, and it is a good one: a fake list shaped exactly like the real one is indistinguishable to the caller, and user-created sectors never appear in it.

Where the bridge is the wrong tool, and what to use instead

If you only need historical bars for research and never touch a live terminal, this project is the wrong layer. You would be standing up a Windows QMT install, a transport and a config wizard to reach data that a plain downloader can fetch without any of it. The bridge exists to reach things that only exist inside a running Big QMT instance: live ticks, five-level order book depth, L2 quotes, positions, assets and order state.

The nearest alternative in the same ecosystem is the official xtquant package that ships with QMT, called directly from the terminal's own Python. The difference in approach is the boundary. Direct xtquant keeps your strategy inside the QMT process, with no serialization, no transport and no whitelist, but it also means your code runs where QMT runs and shares that process's lifecycle. xtquant_big_convert moves the boundary out: your strategy becomes a separate process that talks over redis, zmq, a named pipe, MySQL or shared memory, and pays for that with a whitelist of 137 read-only methods, a config file on each side, and the RPUSH retry caveat above.

The transport choice is not cosmetic. The README states rpc_background_threads must be True for redis and False for zmq or pipe, and that getting it backwards costs a factor of 4 to 37. That number comes from the project's own documentation, and the repository does carry bench_latency.py, bench_transports.py and bench_zmq_spike.py if you want to reproduce it rather than take it on faith.

Licence, upgrade cost and what the release cadence implies

The licence is MIT, declared both in the repository and in pyproject.toml as license = {text = "MIT"}. That is permissive for commercial use, but the practical constraint sits elsewhere: the wizard generates files containing account numbers and credentials, and the README says not to commit them to version control. QMT's login password is deliberately kept out of those files. qmt_launcher reads it from the environment variable BIGQMT_LOGIN_PASSWORD so it does not appear in argv or on disk. The Redis password is treated differently and does get written into the config, without echo at the prompt.

Upgrade cost tracks the release cadence. The last push was on 2026-09-17, and releases v0.3.45, v0.3.46 and v0.3.47 landed on 2026-09-16 and 2026-09-17. Three patch releases in two days is a fast-moving 0.x line, and pyproject.toml classifies the project as Development Status :: 4 - Beta. Treat version pins as meaningful here. The redis extra is pinned below 8.0.0 for a documented reason, and the CHANGELOG.md at the repository root is the place to check what a patch actually changed before you pull it into a live account.

The optional dependency layout is worth reading before you install. redis, mysql and msgpack are extras; only pyzmq is a hard dependency. Python is listed as >=3.8 and the classifiers run through 3.13. Note that msgpack is described as a faster, smaller wire encoding for whole-quote push, and it falls back to json when absent, so leaving it out changes encoding rather than breaking the push.

Editorial conclusion

Adopt it if you already run Big QMT on a Windows terminal and want an outside Python process to read quotes, positions and account data through MiniQMT method names, with redis or zmq as the transport. Do not adopt it if you need a documented remote-order path out of the box: rpc_allow_order_methods defaults to False, and turning it on means any program that can reach the channel can submit orders. Verify three things before writing strategy code: which transport you picked, because rpc_background_threads must be True for redis and False for zmq or pipe; that the generated config files landed in QMT's python directory rather than your current working directory; and which of the whitelisted methods actually answer on your terminal, since get_stock_type and get_turn_over_rate are documented as returning constant values and the wrappers raise NotImplementedError instead.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. litaolemo/xtquant_big_convert on GitHub
4. README
5. Releases