python - 使用python的快速修复，多次心跳后接收器突然看不到我的了？

Question

我正在使用连接到供应商的 Python 快速修复包。我们发送 30 秒的心跳，超过 10 秒的心跳也没有问题。然后，供应商随机看不到我发送的心跳，我也没有收到他们发送的任何响应，然后他们强制我退出 session 。

我们都不知道是什么原因造成的。我们的序列号也同步，如之前成功的心跳所示。以下是我们之间发送的 FIX 消息的示例。当我发送序列号为 34 = 13 的最后一个心跳时，他们就不再看到我的心跳。

有谁知道这里可能出现什么问题吗？不幸的是，他们的支持人员没有提供任何其他信息，除了在我发送序列号 34 = 12 的消息后他们没有收到任何内容。

2017-09-08 13:31:55,312 - fix_connection.FIX_IO - INFO - toAdmin >>>>:
8=FIX.4.2|9=67|35=5|34=23|49=XXXX|52=20170908-17:31:55.285|56=****|141=N|10=115|

2017-09-08 13:31:55,433 - fix_connection.FIX_IO - INFO - toAdmin >>>>:
8=FIX.4.2|9=78|35=A|34=1|49=XXXX |52=20170908-17:31:55.403|56=**** |141=N|98=0|108=30|10=094|

2017-09-08 13:31:55,717 - fix_connection.FIX_IO - INFO - fromAdmin >>>>:
8=FIX.4.2|9=77|35=A|34=1|43=N|49=****|52=20170908-17:31:58.106|56=XXXX|98=0|108=30|10=049|

2017-09-08 13:31:55,789 - fix_connection.FIX_IO - INFO - fromAdmin >>>>:
8=FIX.4.2|9=89|35=1|34=2|43=N|49=****|52=20170908-17:31:58.175|56=XXXX|112=08/09/2017-13:31:58|10=179|

2017-09-08 13:31:55,815 - fix_connection.FIX_IO - INFO - toAdmin >>>>:
8=FIX.4.2|9=90|35=0|34=2|49=XXXX|52=20170908-17:31:55.801|56=****|141=N|112=08/09/2017-13:31:58|10=210|

2017-09-08 13:32:25,401 - fix_connection.FIX_IO - INFO - toAdmin >>>>:
8=FIX.4.2|9=66|35=0|34=3|49=XXXX|52=20170908-17:32:25.386|56=****|141=N|10=059|

2017-09-08 13:32:26,000 - fix_connection.FIX_IO - INFO - fromAdmin >>>>:
8=FIX.4.2|9=65|35=0|34=3|43=N|49=****|52=20170908-17:32:28.387|56=XXXX|10=015|

2017-09-08 13:32:55,420 - fix_connection.FIX_IO - INFO - toAdmin >>>>:
8=FIX.4.2|9=66|35=0|34=4|49=XXXX|52=20170908-17:32:55.406|56=****|141=N|10=056|

2017-09-08 13:33:01,443 - fix_connection.FIX_IO - INFO - toAdmin >>>>:
8=FIX.4.2|9=75|35=1|34=5|49=XXXX|52=20170908-17:33:01.429|56=****|141=N|112=TEST|10=073|

2017-09-08 13:33:05,502 - fix_connection.FIX_IO - INFO - fromAdmin >>>>:
8=FIX.4.2|9=65|35=0|34=4|43=N|49=****|52=20170908-17:32:58.496|56=XXXX|10=020|

2017-09-08 13:33:05,713 - fix_connection.FIX_IO - INFO - fromAdmin >>>>:
8=FIX.4.2|9=89|35=1|34=5|43=N|49=****|52=20170908-17:33:07.942|56=XXXX|112=08/09/2017-13:33:07|10=176|

2017-09-08 13:33:05,739 - fix_connection.FIX_IO - INFO - toAdmin >>>>:
8=FIX.4.2|9=90|35=0|34=6|49=XXXX|52=20170908-17:33:05.722|56=****|141=N|112=08/09/2017-13:33:07|10=209|

2017-09-08 13:33:07,400 - fix_connection.FIX_IO - INFO - fromAdmin >>>>:
8=FIX.4.2|9=74|35=0|34=6|43=N|49=****|52=20170908-17:33:09.791|56=XXXX|112=TEST|10=035|

2017-09-08 13:33:35,470 - fix_connection.FIX_IO - INFO - toAdmin >>>>:
8=FIX.4.2|9=66|35=0|34=7|49=XXXX|52=20170908-17:33:35.449|56=****|141=N|10=065|

2017-09-08 13:33:37,575 - fix_connection.FIX_IO - INFO - fromAdmin >>>>:
8=FIX.4.2|9=65|35=0|34=7|43=N|49=****|52=20170908-17:33:39.967|56=XXXX|10=026|

2017-09-08 13:34:05,490 - fix_connection.FIX_IO - INFO - toAdmin >>>>:
8=FIX.4.2|9=66|35=0|34=8|49=XXXX|52=20170908-17:34:05.475|56=****|141=N|10=063|

2017-09-08 13:34:07,661 - fix_connection.FIX_IO - INFO - fromAdmin >>>>:
8=FIX.4.2|9=65|35=0|34=8|43=N|49=****|52=20170908-17:34:10.057|56=XXXX|10=007|

2017-09-08 13:34:35,513 - fix_connection.FIX_IO - INFO - toAdmin >>>>:
8=FIX.4.2|9=66|35=0|34=9|49=XXXX|52=20170908-17:34:35.497|56=****|141=N|10=071|

2017-09-08 13:34:37,924 - fix_connection.FIX_IO - INFO - fromAdmin >>>>:
8=FIX.4.2|9=65|35=0|34=9|43=N|49=****|52=20170908-17:34:40.320|56=XXXX|10=004|

2017-09-08 13:35:05,532 - fix_connection.FIX_IO - INFO - toAdmin >>>>:
8=FIX.4.2|9=67|35=0|34=10|49=XXXX|52=20170908-17:35:05.520|56=****|141=N|10=097|

2017-09-08 13:35:08,276 - fix_connection.FIX_IO - INFO - fromAdmin >>>>:
8=FIX.4.2|9=66|35=0|34=10|43=N|49=****|52=20170908-17:35:10.579|56=XXXX|10=059|

2017-09-08 13:35:35,555 - fix_connection.FIX_IO - INFO - toAdmin >>>>:
8=FIX.4.2|9=67|35=0|34=11|49=XXXX|52=20170908-17:35:35.537|56=****|141=N|10=109|

2017-09-08 13:35:38,571 - fix_connection.FIX_IO - INFO - fromAdmin >>>>:
8=FIX.4.2|9=66|35=0|34=11|43=N|49=****|52=20170908-17:35:40.967|56=XXXX|10=064|

2017-09-08 13:36:05,573 - fix_connection.FIX_IO - INFO - toAdmin >>>>:
8=FIX.4.2|9=67|35=0|34=12|49=XXXX|52=20170908-17:36:05.560|56=****|141=N|10=104|

2017-09-08 13:36:10,144 - fix_connection.FIX_IO - INFO - fromAdmin >>>>:
8=FIX.4.2|9=66|35=0|34=12|43=N|49=****|52=20170908-17:36:11.256|56=XXXX|10=055|

2017-09-08 13:36:35,594 - fix_connection.FIX_IO - INFO - toAdmin >>>>:
8=FIX.4.2|9=67|35=0|34=13|49=XXXX|52=20170908-17:36:35.580|56=****|141=N|10=110|

2017-09-08 13:36:46,611 - fix_connection.FIX_IO - INFO - toAdmin >>>>:
8=FIX.4.2|9=76|35=1|34=14|49=XXXX|52=20170908-17:36:46.598|56=****|141=N|112=TEST|10=141|

2017-09-08 13:36:54,493 - fix_connection.FIX_IO - INFO - 

*** Force Logout ****

我的配置文件如下:

[DEFAULT]
ConnectionType=initiator
ReconnectInterval=60
FileStorePath=store
FileLogPath=log
StartTime=07:00:00
EndTime=19:00:00
UseDataDictionary=Y
DataDictionary=spec/FIX42.xml
HttpAcceptPort=9911
ValidateUserDefinedFields=N
ResetOnLogout=N
ResetOnLogon=Y

# standard config elements

[SESSION]
# inherit ConnectionType, ReconnectInterval and SenderCompID from default
BeginString=FIX.4.2
SenderCompID=XXXX
TargetCompID=****
SocketConnectHost=11.111.111.1
SocketConnectPort=11111
HeartBtInt=30

Answer 1

您发送的消息中的时间戳和 52(文本)字段之间的差异约为 5 毫秒。您收到的消息中这些字段之间的差异要大得多，在 1-3 秒之间。在我看来，你们的时钟似乎不同步了。我以前也遇到过这种情况，跟你描述的效果一样。当您一端的消息堆积时，可能会发生这种情况。 CPU 是否已被资源淹没，或者您是否与其他具有大量 I/O 的设备共享端口？您可以尝试将您所在的端口切换到绝对未使用的端口，并在其自己的进程中启动 QuickFix。