我正在研究修复会话层，并且对会话级拒绝有一些困惑。
如果出现乱码或无效（校验和错误，体长，所需标签丢失等等），会话期间收到的消息是什么，这将是正确的恢复措施？我在考虑以下三个：
另一件事是：REJECT总是后跟LOGOUT和DISCONNECTION吗？
提前致谢。
答案 0 :(得分：2)
一般来说，对无效消息的正确响应只是会话级拒绝（消息类型3），其包括它在标记＃45（RefSeqNum）中引用的消息的序列号。其余的是可选的。包括尽可能多的信息通常会帮助那些处理该问题的人。缺少这些信息可能会使诊断问题变得更加困难，并导致大量客户请求和电话呼叫。
忽略消息绝不是一个好主意。只是发送注销也不是一个好主意 - 不清楚为什么反对方连接请求会话结束。
是否在拒绝后发送退出完全取决于您。有些系统会这样做，有些则没有。这并不重要，因为退出永远不会有帮助。
你知道，如果出现导致错误的事情，例如消息中没有关键字段，或者生成了无效的校验和，那么应用程序可能无法正确编写，在这种情况下应该立即关闭并修复。另一种可能性是系统故障（即由于电离辐射引起的误差☺），在这种情况下，不可能正常地处理错误。
这些情况在开发和测试（认证）期间很常见，并且在生产中几乎从未见过。在测试/暂存/开发环境中，交换机会简单地拒绝具有尽可能详细信息的消息。这将暗示开发人员会出现什么问题，他们会更正代码并重试。
在生产中，有这样的事情发生是不可接受的，支持部门需要参与其中。如果偶发错误，交换只会发送拒绝。但是你可以想象，一个有故障的客户端可能会开始发送数百万（或更多）格式错误的消息。这很容易减慢连接到它的所有客户端的FIX网关，甚至导致拒绝服务。这是不可接受的，交换采用不同的技术来防止它。有些人会不断监控情况并禁止坏客户（例如使用防火墙），如果他们检测到错误的高错误率，那么他们会打电话给客户通知他们情况。其他交换将拒绝一些消息，然后如果客户端没有修复错误则发送注销，最后 - 自动阻止访问。在极端情况下，客户可能会被拒绝进一步访问，直到再次通过认证，并因不便而罚款。但是，这当然超出了FIX协议的范围。
此外，我现在已经写了大约十年的财务申请，我现在所在的公司在美国所有交易所以及世界各地的许多主要交易所都有。幸运的是，其中许多人不使用FIX。但是从使用FIX的那些列表中，我从未见过符合FIX协议的单个列表。决不。因此，您最好的选择是遵循您要连接的交换规则（并且他们永远不会向您发送错误消息，或者如果他们这样做 - 您将不得不打电话给他们，向他们发送拒绝将毫无意义），或者如果你正在编写服务器部分 - 做你客户期望的最合乎逻辑的事情。
希望它有所帮助。祝你好运！