我们的设计如下所示，我想征询您的意见或协议指南
对于以下错误情况。
Layer1
---------------
| ^ ^
| (1) |(4) |(6)
v | | Remote entity
---------------- ---------------
Layer0-----------------(2)------------------------------->Layer0
Layer0<----------------(3)--------------------------------Layer0
Layer0<----------------(5)--------------------------------Layer0
1. New session request to remote entity.
2. Establish link + data(session request)
3. Link Establishment ongoing
4. Link Establishment pending
5. Link Established + data (session accepted)
6. session accepted.
如果layer1决定在步骤4和6之间不需要远程实体服务，即由于某些错误而接收到事件4，但尚未接收到事件6。
1）是否应等待事件6发生并启动会话释放，或者
2）第1层应指示第0层终止连接建立过程
立即。
哪种方法正确？
（1）的问题是，即使我们知道由于错误而要终止会话，我们也需要在event6进入之前处理其他事件。
最佳答案
我是fail fast设计的粉丝。当您知道无法继续时，应通知另一方并退出。
如果出于某种原因需要验证另一方是否收到了退出消息，则我更愿意使用UNABLE_TO_COMPLY消息来响应请求，或者完全放弃事件。问题在于您可以进入半开状态。
处理已经发送失败消息后，另一端卡在等待其他请求响应的情况的一种方法是使用优先级队列。您可以指示立即处理某些消息，而不管它们何时被接收，而不是按接收顺序处理请求。较高优先级的消息被插入到队列的最前面，因此quit_on_failure事件不会被其他您无法真正处理的请求阻止。
我通常也不喜欢基于时间的看门狗（因为开发人员选择的时间长度在所有情况下都永远都不正确），但是对于这些类型的协议，您通常必须定义最坏的情况，即另一端永远不会响应您的消息。在这些情况下，可配置的超时通常是清理的唯一方法。超时应该永远是万不得已的方法，而不是第一时间。