堡垒。执法问题 - 页 34 1...272829303132333435363738394041...156 新评论 Vladimir Pastushak 2015.09.01 19:21 #331 Михаил:我在2014年12月16日开始了这个主题。现在是2015年9月。 公平地说，应该注意到原始平台概念造成的普遍延误。 很快就得到了修复，但令人无限遗憾的是，开发人员没有认真对待 "浮动单 "的延迟。这在交易中被证明是致命的（因为它在不同的经纪商的模拟和真实账户上进行了测试。很明显，延迟发生在MT5的服务器端）。非常遗憾的是，对这个错误的检测是由用户完成的，而不是由开发人员完成的。虽然雷纳特在2014年12月29日保证，工作将继续进行。"偶尔出现的浮动反应到终端的交付时间还没有得到解决，我们将继续努力。" 迈克尔，也许延迟是设备的错？还是你认为设备总是无故障工作？也许给服务器硬件的开发者写信是有意义的？ Mikhail Filimonov 2015.09.01 19:32 #332 Vladimir Pastushak: 迈克尔，也许延误是由于设备的原因？还是你认为设备总是无故障工作？也许给服务器硬件的开发者写信是有意义的？弗拉基米尔!你应该仔细阅读这些帖子和日志!不同的经纪商有一个相同的效果，无论是在模拟账户还是在真实账户上都是如此 Vladimir Pastushak 2015.09.01 19:52 #333 Михаил:弗拉基米尔!你应该仔细阅读这些帖子和日志!对真实和模拟经纪商有同样的效果，对不同的经纪商有同样的效果!很多时候，一个经纪业务的创建/维护是由一个专门的公司进行的，这反过来又把几乎相同的服务器，即不同的经纪人和设备是一个和相同的...不同经纪公司的服务器站在同一个机架上的情况时有发生... Mikhail Filimonov 2015.09.01 20:10 #334 Vladimir Pastushak:很多时候，经纪业务的创建/服务是由专门的办公室处理的，这又把几乎相同的服务器，即经纪人是不同的，但设备是相同的 ...碰巧的是，不同经纪公司的服务器都在一个机架上。弗拉基米尔!我有个大忙要请你帮忙。请不要编造这些。 Vladimir Pastushak 2015.09.01 20:14 #335 Михаил:弗拉基米尔!我对你有一个很大的请求。请不要幻想了。如果你不知道这门生意是如何运作的，这并不意味着有人在幻想，建立一个经纪公司需要人脉吗？好吧，这很有创意，我是不是可以理解为你正在用这个帖子中的顾问测试服务器https://www.mql5.com/ru/forum/38456/page37#comment_1869077。 ФОРТС. Вопросы по исполнению www.mql5.com С большими проблемами удалось это сделать (начальник отдела по работе с профессиональными клиентами ДЦ Открытие Евгений Сергеевич,. - Страница 37 - Категория: автоматические торговые системы Vladimir Pastushak 2015.09.01 22:50 #336 如果你有兴趣，这是我的日志我想知道MT5服务器每分钟或每秒钟能处理多少个请求... 附加的文件： 20150901.log 758 kb Mikhail Filimonov 2015.09.02 09:08 #337 今天上午（真实）Accsess服务器4。2015.09.02 10:00:18.610 Trades 'xxxxx': sell limit 5.00 MIX-12.15 at 172475 2015.09.02 10:00:18.619 Trades 'xxxxx': sell limit 5.00 MIX-12.15 at 172475 placed for execution in 9 ms 2015.09.02 10:00:18.926 Trades 'xxxxx': cancel order #19725208 sell limit 5.00 MIX-12.15 at 172475 2015.09.02 10:00:18.941 Trades 'xxxxx': cancel order #19725208 sell limit 5.00 MIX-12.15 at 172475 placed for execution in 15 ms 2015.09.02 10:00:20.215 Trades 'xxxxx': buy limit 3.00 TATN-12.15 at 28402 2015.09.02 10:00:29.538 Trades 'xxxxx': buy limit 3.00 TATN-12.15 at 28402 placed for execution in 9324 ms 2015.09.02 10:00:29.608 Trades 'xxxxx': modify order #19725217 buy limit 3.00 TATN-12.15 at 28402 sl: 0 tp: 0 -> 28404, sl: 0 tp: 0 2015.09.02 10:00:31.504 Trades 'xxxxx': cancel order #19725136 sell limit 5.00 UJPY-12.15 at 120.69 2015.09.02 10:00:31.510 Trades 'xxxxx': sell limit 2.00 FEES-12.15 at 6831 2015.09.02 10:00:31.817 Trades 'xxxxx': modify order #19725217 buy limit 3.00 TATN-12.15 at 28402 sl: 0 tp: 0 -> 28523, sl: 0 tp: 0 2015.09.02 10:00:33.713 Trades 'xxxxx': cancel order #19725179 buy limit 1.00 URKA-12.15 at 19590 2015.09.02 10:00:33.733 Trades 'xxxxx': modify order #19725217 buy limit 3.00 TATN-12.15 at 28402 sl: 0 tp: 0 -> 28404, sl: 0 tp: 0 placed for execution in 4125 ms 2015.09.02 10:00:33.751 Trades 'xxxxx': cancel order #19725136 sell limit 5.00 UJPY-12.15 at 120.69 placed for execution in 2248 ms 2015.09.02 10:00:33.752 Trades 'xxxxx': sell limit 2.00 FEES-12.15 at 6831 placed for execution in 2241 ms 2015.09.02 10:00:33.762 Trades 'xxxxx': modify order #19725217 buy limit 3.00 TATN-12.15 at 28404 sl: 0 tp: 0 -> 28523, sl: 0 tp: 0 placed for execution in 1946 ms 2015.09.02 10:00:33.900 Trades 'xxxxx': cancel order #19725217 buy limit 3.00 TATN-12.15 at 28523 2015.09.02 10:00:34.654 Trades 'xxxxx': modify order #19725269 sell limit 2.00 FEES-12.15 at 6831 sl: 0 tp: 0 -> 6829, sl: 0 tp: 0 2015.09.02 10:00:35.603 Trades 'xxxxx': cancel order #19725179 buy limit 1.00 URKA-12.15 at 19590 placed for execution in 1890 ms 2015.09.02 10:00:35.610 Trades 'xxxxx': cancel order #19725217 buy limit 3.00 TATN-12.15 at 28523 placed for execution in 1710 ms 2015.09.02 10:00:35.624 Trades 'xxxxx': modify order #19725269 sell limit 2.00 FEES-12.15 at 6831 sl: 0 tp: 0 -> 6829, sl: 0 tp: 0 placed for execution in 970 ms 2015.09.02 10:00:36.004 Trades 'xxxxx': modify order #19725269 sell limit 2.00 FEES-12.15 at 6829 sl: 0 tp: 0 -> 6808, sl: 0 tp: 0 2015.09.02 10:00:36.014 Trades 'xxxxx': modify order #19725269 sell limit 2.00 FEES-12.15 at 6829 sl: 0 tp: 0 -> 6808, sl: 0 tp: 0 placed for execution in 9 ms 我们可以把这称为 "单一 "延迟吗？因此，（超过了等待时间限制）替代检查（CheckOrders()）功能已被激活。2015.09.02 10:00:21.419 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 1 получить билет Buy ордера... 2015.09.02 10:00:21.529 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 2 получить билет Buy ордера... 2015.09.02 10:00:21.638 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 3 получить билет Buy ордера... 2015.09.02 10:00:21.747 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 4 получить билет Buy ордера... 2015.09.02 10:00:21.856 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 5 получить билет Buy ордера... 2015.09.02 10:00:21.856 Forts_trader (TATN-9.15,H1) CheckOrders: Не получен билет Buy ордера! 2015.09.02 10:00:22.932 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 1 получить билет Buy ордера... 2015.09.02 10:00:23.042 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 2 получить билет Buy ордера... 2015.09.02 10:00:23.151 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 3 получить билет Buy ордера... 2015.09.02 10:00:23.260 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 4 получить билет Buy ордера... 2015.09.02 10:00:23.369 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 5 получить билет Buy ордера... 2015.09.02 10:00:23.369 Forts_trader (TATN-9.15,H1) CheckOrders: Не получен билет Buy ордера! 2015.09.02 10:00:24.461 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 1 получить билет Buy ордера... 2015.09.02 10:00:24.570 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 2 получить билет Buy ордера... 2015.09.02 10:00:24.680 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 3 получить билет Buy ордера... 2015.09.02 10:00:24.789 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 4 получить билет Buy ордера... 2015.09.02 10:00:24.898 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 5 получить билет Buy ордера... 2015.09.02 10:00:24.898 Forts_trader (TATN-9.15,H1) CheckOrders: Не получен билет Buy ордера! 2015.09.02 10:00:25.974 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 1 получить билет Buy ордера... 2015.09.02 10:00:26.084 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 2 получить билет Buy ордера... 2015.09.02 10:00:26.193 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 3 получить билет Buy ордера... 2015.09.02 10:00:26.302 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 4 получить билет Buy ордера... 2015.09.02 10:00:26.411 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 5 получить билет Buy ордера... 2015.09.02 10:00:26.411 Forts_trader (TATN-9.15,H1) CheckOrders: Не получен билет Buy ордера! 2015.09.02 10:00:27.503 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 1 получить билет Buy ордера... 2015.09.02 10:00:27.612 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 2 получить билет Buy ордера... 2015.09.02 10:00:27.721 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 3 получить билет Buy ордера... 2015.09.02 10:00:27.831 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 4 получить билет Buy ордера... 2015.09.02 10:00:27.940 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 5 получить билет Buy ордера... 2015.09.02 10:00:27.940 Forts_trader (TATN-9.15,H1) CheckOrders: Не получен билет Buy ордера! 2015.09.02 10:00:29.021 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 1 получить билет Buy ордера... 2015.09.02 10:00:29.125 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 2 получить билет Buy ордера... 2015.09.02 10:00:29.235 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 3 получить билет Buy ордера... 2015.09.02 10:00:29.344 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 4 получить билет Buy ордера... 2015.09.02 10:00:29.453 Forts_trader (TATN-9.15,H1) CheckOrders: Попытка 5 получить билет Buy ордера... 2015.09.02 10:00:29.453 Forts_trader (TATN-9.15,H1) CheckOrders: Не получен билет Buy ордера! 2015.09.02 10:00:31.060 Forts_trader (TATN-9.15,H1) CheckOrders: Buy ордер модифицирован. Билет = 19725217 2015.09.02 10:00:32.894 Forts_trader (UJPY-9.15,H1) CheckOrders: Sell ордер не удалён! Билет = 19725136 2015.09.02 10:00:32.894 Forts_trader (FEES-9.15,H1) CheckOrders: Попытка 1 получить билет Sell ордера... 2015.09.02 10:00:33.010 Forts_trader (FEES-9.15,H1) CheckOrders: Попытка 2 получить билет Sell ордера... 2015.09.02 10:00:33.088 Forts_trader (TATN-9.15,H1) CheckOrders: Buy ордер модифицирован. Билет = 19725217 2015.09.02 10:00:33.119 Forts_trader (FEES-9.15,H1) CheckOrders: Попытка 3 получить билет Sell ордера... 2015.09.02 10:00:33.228 Forts_trader (FEES-9.15,H1) CheckOrders: Попытка 4 получить билет Sell ордера... 2015.09.02 10:00:33.337 Forts_trader (FEES-9.15,H1) CheckOrders: Попытка 5 получить билет Sell ордера... 2015.09.02 10:00:33.337 Forts_trader (FEES-9.15,H1) CheckOrders: Не получен билет Sell ордера! 2015.09.02 10:00:34.773 Forts_trader (URKA-9.15,H1) CheckOrders: Buy ордер не удалён! Билет = 19725179 2015.09.02 10:00:35.115 Forts_trader (TATN-9.15,H1) CheckOrders: Buy ордер не удалён! Билет = 19725217 Aytugan Khafizov 2015.09.02 16:46 #338 Михаил:今天上午（真实）Accsess服务器4。根据来自Discovery的信息，AS 4最好不要使用。最好使用AS2 Mikhail Filimonov 2015.09.02 23:16 #339 Aytugan Khafizov:迈克尔，我可以通过分析你在Discovery接入点的登录日志告诉你以下情况。1) 当你连接时，数据中心将ping记录到终端，这些ping保持在10ms左右，但也有尖锐到500ms的。Access Server2 2015.08.25 08:48:15.666 ***.***.***.*** '*****': login (Client build 1159, cid: *****************************, ping: 10.89 ms) Access Server3 2015.08.25 00:07:19.069 ***.***.***.*** '*****': login (Client build 1159, cid: *****************************, ping: 500.40 ms) Access Server3 2015.08.25 08:48:28.696 ***.***.***.*** '*****': login (Client build 1159, cid: *****************************, ping: 12.03 ms) Access Server3 2015.08.26 04:10:52.879 ***.***.***.*** '*****': login (Client build 1159, cid: *****************************, ping: 506.13 ms) Access Server3 2015.08.27 01:08:15.820 ***.***.***.*** '*****': login (Client build 1159, cid: *****************************, ping: 8.12 ms) Access Server2 2015.08.27 01:08:18.776 ***.***.***.*** '*****': login (Client build 1159, cid: *****************************, ping: 7.12 ms) Access Server2 2015.08.27 02:32:48.278 ***.***.***.*** '*****': login (Client build 1159, cid: *****************************, ping: 7.07 ms) Access Server2 2015.08.27 09:05:51.324 ***.***.***.*** '*****': login (Client build 1159, cid: *****************************, ping: 11.65 ms) Access Server3 2015.08.27 09:06:04.272 ***.***.***.*** '*****': login (Client build 1159, cid: *****************************, ping: 11.75 ms)这是从接入点到终端的PING。| зона ответственности Биржи || зона ответственности Открытия || интернет || клиент | [биржа (ФОРТС)] <==> [шлюз Plaza2] <===> [шлюз в MOEX] <=> [MT5 торговый сервер] <=> [Точка доступа] <================> [Терминал] 所以你可以看到在MT5终端-MT5接入点的路径上已经出现了问题，没有达到交易。2) 我分析了其他客户的ping，有波动 - 但我没有发现任何稳定的模式（例如，在同一时间大量增加的ping）。该如何处理？ 1) 我们在终端添加了ping记录，该功能将在下一个测试版中提供。当它出来时，我将在这里发布。我们还将在未来的平台中建立组件间的定期ping测量，以寻找（可能的）网络问题。2）我已经要求Discover提供额外的网络信息。让我们看看这是否有助于找到原因。3) 我建议你尝试通过访问服务器4工作一段时间--它通过与访问点（2,3）不同的供应商连接到互联网，并且在发现网络内部以不同方式连接到贸易服务器。出现了一种预感...我想知道，如果终端 记录 说它发送了一个订单（order）怎么办？但它没有发送（延迟），那么它解释了（为什么从终端到MT5服务器的ping太长）。 Aytugan Khafizov 2015.09.03 08:59 #340 Михаил:我想，如果终端 记录 说它发送了一个订单（order），那该怎么办？但实际上并没有发送（延迟），那么这就解释了一切（为什么从终端到MT5服务器的ping值过大）。终端与服务器保持一个TCP连接，与服务器交换日志、图表和交易指令。订单当然是更优先的。进行单一连接的操作，因为建立一个单独的连接来发送交易请求所需的时间非常长--几秒钟。因此，在终端发生了以下事情。终端的交易部分向内部终端连接管理器发送数据连接管理器将数据传递给操作系统操作系统将数据传输到互联网 当数据来自互联网时，操作系统确定它是针对终端的，调用终端连接管理器，后者根据内部协议确定数据属于哪个终端组件连接中的所有TCP数据包是按顺序编号的。对于每一个收到的数据包，操作系统都会发送一个确认收到的信息。操作系统也会观察收到的数据包，如果它发现没有收到这样那样的数据包，它就会向发送者发送一个特殊的消息--重新发送这样那样的数据包。因此，即使一个数据包在 "途中 "丢失，应用程序也不会被告知--双方的操作系统都会弥补丢失的数据包。但重传需要时间，而操作系统在依次收到所有 "旧 "数据包之前不会重传 "新 "数据包。因此，从应用方面来看，操作系统已经恢复的数据包的丢失被视为一种延迟。从 "开放 "一侧，你可以看到，交易服务器在1-2毫秒处记录 "有问题 "的交易的执行情况--与其他交易相同。根据目前从Otkritie收到的信息，在 "交易所"-"网关"、"网关-交易服务器"、"交易服务器-接入点 "部分没有发现问题。我们现在要处理的是接入点和 "接入点-终端 "部分。 1...272829303132333435363738394041...156 新评论 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
我在2014年12月16日开始了这个主题。
现在是2015年9月。
公平地说，应该注意到原始平台概念造成的普遍延误。
很快就得到了修复，但令人无限遗憾的是，开发人员没有认真对待 "浮动单 "的延迟。
这在交易中被证明是致命的（因为它在不同的经纪商的模拟和真实账户上进行了测试。
很明显，延迟发生在MT5的服务器端）。
非常遗憾的是，对这个错误的检测是由用户完成的，而不是由开发人员完成的。
虽然雷纳特在2014年12月29日保证，工作将继续进行。
"偶尔出现的浮动反应到终端的交付时间还没有得到解决，我们将继续努力。"
迈克尔，也许延误是由于设备的原因？还是你认为设备总是无故障工作？也许给服务器硬件的开发者写信是有意义的？
弗拉基米尔!
你应该仔细阅读这些帖子和日志!
不同的经纪商有一个相同的效果，无论是在模拟账户还是在真实账户上都是如此
弗拉基米尔!
你应该仔细阅读这些帖子和日志!
对真实和模拟经纪商有同样的效果，对不同的经纪商有同样的效果!
很多时候，一个经纪业务的创建/维护是由一个专门的公司进行的，这反过来又把几乎相同的服务器，即不同的经纪人和设备是一个和相同的...
不同经纪公司的服务器站在同一个机架上的情况时有发生...
很多时候，经纪业务的创建/服务是由专门的办公室处理的，这又把几乎相同的服务器，即经纪人是不同的，但设备是相同的 ...
碰巧的是，不同经纪公司的服务器都在一个机架上。
弗拉基米尔!
我有个大忙要请你帮忙。
请不要编造这些。
弗拉基米尔!
我对你有一个很大的请求。
请不要幻想了。
如果你不知道这门生意是如何运作的，这并不意味着有人在幻想，建立一个经纪公司需要人脉吗？
好吧，这很有创意，我是不是可以理解为你正在用这个帖子中的顾问测试服务器https://www.mql5.com/ru/forum/38456/page37#comment_1869077。
如果你有兴趣，这是我的日志
我想知道MT5服务器每分钟或每秒钟能处理多少个请求...
今天上午（真实）Accsess服务器4。
我们可以把这称为 "单一 "延迟吗？
因此，（超过了等待时间限制）替代检查（CheckOrders()）功能已被激活。
今天上午（真实）Accsess服务器4。
根据来自Discovery的信息，AS 4最好不要使用。
最好使用AS2
迈克尔，我可以通过分析你在Discovery接入点的登录日志告诉你以下情况。
1) 当你连接时，数据中心将ping记录到终端，这些ping保持在10ms左右，但也有尖锐到500ms的。
Access Server2 2015.08.25 08:48:15.666 ***.***.***.*** '*****': login (Client build 1159, cid: *****************************, ping: 10.89 ms)
Access Server3 2015.08.25 00:07:19.069 ***.***.***.*** '*****': login (Client build 1159, cid: *****************************, ping: 500.40 ms)
Access Server3 2015.08.25 08:48:28.696 ***.***.***.*** '*****': login (Client build 1159, cid: *****************************, ping: 12.03 ms)
Access Server3 2015.08.26 04:10:52.879 ***.***.***.*** '*****': login (Client build 1159, cid: *****************************, ping: 506.13 ms)
Access Server3 2015.08.27 01:08:15.820 ***.***.***.*** '*****': login (Client build 1159, cid: *****************************, ping: 8.12 ms)
Access Server2 2015.08.27 01:08:18.776 ***.***.***.*** '*****': login (Client build 1159, cid: *****************************, ping: 7.12 ms)
Access Server2 2015.08.27 02:32:48.278 ***.***.***.*** '*****': login (Client build 1159, cid: *****************************, ping: 7.07 ms)
Access Server2 2015.08.27 09:05:51.324 ***.***.***.*** '*****': login (Client build 1159, cid: *****************************, ping: 11.65 ms)
Access Server3 2015.08.27 09:06:04.272 ***.***.***.*** '*****': login (Client build 1159, cid: *****************************, ping: 11.75 ms)
这是从接入点到终端的PING。
| зона ответственности Биржи || зона ответственности Открытия || интернет || клиент |
[биржа (ФОРТС)] <==> [шлюз Plaza2] <===> [шлюз в MOEX] <=> [MT5 торговый сервер] <=> [Точка доступа] <================> [Терминал]
所以你可以看到在MT5终端-MT5接入点的路径上已经出现了问题，没有达到交易。
2) 我分析了其他客户的ping，有波动 - 但我没有发现任何稳定的模式（例如，在同一时间大量增加的ping）。
该如何处理？
1) 我们在终端添加了ping记录，该功能将在下一个测试版中提供。当它出来时，我将在这里发布。我们还将在未来的平台中建立组件间的定期ping测量，以寻找（可能的）网络问题。
2）我已经要求Discover提供额外的网络信息。让我们看看这是否有助于找到原因。
3) 我建议你尝试通过访问服务器4工作一段时间--它通过与访问点（2,3）不同的供应商连接到互联网，并且在发现网络内部以不同方式连接到贸易服务器。
出现了一种预感...
我想知道，如果终端 记录 说它发送了一个订单（order）怎么办？
但它没有发送（延迟），那么它解释了（为什么从终端到MT5服务器的ping太长）。
Михаил:
我想，如果终端 记录 说它发送了一个订单（order），那该怎么办？
但实际上并没有发送（延迟），那么这就解释了一切（为什么从终端到MT5服务器的ping值过大）。
终端与服务器保持一个TCP连接，与服务器交换日志、图表和交易指令。订单当然是更优先的。进行单一连接的操作，因为建立一个单独的连接来发送交易请求所需的时间非常长--几秒钟。
因此，在终端发生了以下事情。
- 终端的交易部分向内部终端连接管理器发送数据
- 连接管理器将数据传递给操作系统
- 操作系统将数据传输到互联网
当数据来自互联网时，操作系统确定它是针对终端的，调用终端连接管理器，后者根据内部协议确定数据属于哪个终端组件连接中的所有TCP数据包是按顺序编号的。对于每一个收到的数据包，操作系统都会发送一个确认收到的信息。操作系统也会观察收到的数据包，如果它发现没有收到这样那样的数据包，它就会向发送者发送一个特殊的消息--重新发送这样那样的数据包。因此，即使一个数据包在 "途中 "丢失，应用程序也不会被告知--双方的操作系统都会弥补丢失的数据包。但重传需要时间，而操作系统在依次收到所有 "旧 "数据包之前不会重传 "新 "数据包。因此，从应用方面来看，操作系统已经恢复的数据包的丢失被视为一种延迟。
从 "开放 "一侧，你可以看到，交易服务器在1-2毫秒处记录 "有问题 "的交易的执行情况--与其他交易相同。根据目前从Otkritie收到的信息，在 "交易所"-"网关"、"网关-交易服务器"、"交易服务器-接入点 "部分没有发现问题。我们现在要处理的是接入点和 "接入点-终端 "部分。