并发登录上限

定义

数据和路由提供方是按登录来授权和计量使用的。为了把这件事落实下去，它们的网关会限制一个登录在某项服务上同时能保持多少个会话。当这个上限是一时，第二次登录尝试要么结束第一个会话、要么被拒绝，视提供方而定。

它怎么表现出来

• 一张本来在线的图表，在另一个平台用同一个登录打开的那一刻就冻住了。
• 登录成功了，但没有数据到达，因为另一个会话握着行情权限。
• 两个平台在打架：每一次重连都把另一个顶出去。
• 一个自动重连循环，不停地和用户在别处打开的某个会话相撞。

一个算例

一个交易者用同一个登录同时跑经纪商自己的平台和一个第三方画图应用，而行情会话上限是一个。会话计数：请求 2 个，允许 1 个，于是其中一个失去了数据。关掉其中一个平台，或者在这家公司有售的情况下买一个第二登录，就能让它重新变成一对一。

服务是分开计的

一个期货登录往往不是一个会话，而是好几个：行情、下单、盈亏、历史数据，各自是一条独立的通道，而上限是分别施加在每一条上的。这解释了一种让人困惑的症状：图表活着、报价在动，但下单被拒绝，或者头寸不刷新——因为被占住的是下单那条通道，而不是行情那条。所以在断定是哪一个上限被碰到之前，要先看是哪一项服务沉默了。

在 Senzoukria 里

应用里的 Rithmic 文档写明：Rithmic 对每个登录只允许一个并发行情会话——先关掉 R | Trader Pro 或者另一个平台，或者买这家公司的第二登录附加项。账户数据流一次只镜像一个经纪商连接，因为像 Apex 或 Rithmic 这样的提供方，对每个登录只允许一个并发的下单会话。当连接诊断发现每一步都被接受、却没有任何一个 tick 到达时，「同一个登录上还开着另一个会话」是它始终留在清单上的两个原因之一。而针对沉默的下单与盈亏会话的看守程序只做记录，而不自动重新登录，因为有些自营商系统会拒绝并发登录。

常见错误

• 在连接另一个应用的时候，把经纪商的平台留在后台继续跑着。
• 在两台电脑之间共用一个登录。
• 把一个被顶掉的会话读成平台的 bug。