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