我学习修复会话层和具有约会话级拒绝一些混乱。FIX会话级拒绝
在乱码或无效的情况下（校验，bodylength错误，需要标签失踪...等）会议将是什么正确的恢复措施期间收到的消息？我正在考虑以下三项：
另一件事是：拒绝始终跟着LOGOUT和DISCONNECTION？
在此先感谢。
一般来说，一个无效的消息的正确响应仅仅是会话级拒绝（消息类型3），其包括它指的是在标签＃45（RefSeqNum）的消息的序列号。其余是可选的。包括尽可能多的信息通常会帮助那些处理这个问题的人。没有这些信息可能会使诊断问题更困难，并导致大量客户请求和电话。
忽视的消息是不是一个好主意。发送注销并不是一个好主意 - 它不清楚为什么对方连接要求会话结束。
是否发送以下内容的拒绝是完全取决于你注销。有些系统是这样做的，有些则没有。这并不重要，因为注销是无用的。
您会发现，如果发生导致错误（如消息中没有键字段）或正在生成无效校验和的错误 - 可能会导致应用程序写入不正确，在这种情况下应该降低立即修复。另一种可能性是系统故障（即由于电离辐射造成的误差），在这种情况下，错误的处理是不可能的。
这些情况时的开发和测试（认证）时期是常见的，几乎从来没有在生产中看到。在测试/分期/开发环境中，交流只会尽可能详细地拒绝信息。这会暗示开发者有什么不对，他们会纠正代码并再次尝试。
在生产中，发生这样的事情是不可接受的，如果支持部门需要参与，则需要参与。在偶发错误的情况下，交换只会发送拒绝。但是你可以想象一个有故障的客户端可能会开始发送数百万（或更多）畸形的消息。这很容易使连接到它的所有客户端的FIX网关变慢，甚至导致拒绝服务。这是不可接受的，交换采用不同的技术来防止它。有些人会不断监测情况并禁止坏客户（例如使用防火墙），如果他们发现可疑的错误率很高，那么他们会打电话给客户告知他们情况。其他交换会拒绝一些消息，然后在客户端没有修复错误时发送注销，最后 - 自动阻止访问。在极端情况下，客户可能会被拒绝进一步访问，直到再次通过认证，并为不便之处收取费用。但是，这当然超出了FIX协议的范围。
此外，我一直在写金融应用程序已有十年了，现在我在美国的所有交易所都有这个公司，还有很多世界各地的主要交易所。幸运的是，其中许多不使用FIX。但从使用FIX的列表中，我从未见过符合FIX协议的单一列表。决不。所以你最好的选择是遵循你所连接的交换规则（他们绝不会向你发送坏消息，或者如果他们这样做 - 你将不得不打电话给他们，向他们发送拒绝将是毫无意义的），或者如果你正在编写服务器部分 - 做你的客户期望从你的最合理的事情。
希望它有帮助。祝你好运！