openfire 客户端无响应处理方法

无响应对端的处理

当连接某个流的实体在一段时间内没有接收到同样连接到该流的另一对等端发来的任何XMPP信息，那么该对等端可能是无响应的。有几个原因很可能引起这种情况发生：

1. 底层的TCP连接死掉。
2. 尽管当底层的TCP连接仍然是激活的时候，XML流被中断了。
3. 对等端是空闲的，只是没有通过其连接的XML流发送XMPP信息到该实体。

这三个条件最好被分别对待，像下面章节描述的一样。

实现注意:为了处理无响应的对等端，我们把两个单向的TCP连接当作一个在概念上相当的双向的TCP连接（见4.5节（方向性））;然而，实现者要知道在两个单向的TCP连接的情况下，在XMPP应用层对等端对通信的响应将从其第二个TCP连接返回。此外，在每个方向上的多个数据流的使用（大型的XMPP服务提供商间的服务器到服务器之间的连接经常这么部署）使得对XMPP流和底层TCP连接的应用级检查进一步复杂化了，因为任何给定的初始流和任何给定的响应流之间没有必然联系。

死连接

如果底层的TCP连接是死的，流级别的检查（例如：[XEP-0199]和[XEP-0198]）是无效的。因此，不管有没有流错误都没必要关闭流，恰当的做法是直接终止TCP连接。

检查TCP连接的一个通用方法是在XML节之间发送一个空格符（U+0020）,发送空格在XML流中是被允许的，下面第11.7节中将进行描述。发送这样的一个空格被称作“空格保持激活”（词语“whitespace ping”通常被使用，尽管事实上它不是一个ping,因为“pong”是不可能的）。然而，在TLS认证和SASL认证期间，发送空格符是不允许的，下面第5.3.3节和第6.3.5节将会描述。

中断的流

即使底层的TCP连接仍然是激活的，对等端很可能从来不对实体发出的XMPP通信请求作出响应，不管是正常的节还是例如在[XEP-0199]中所定义的应用程序级别ping那样的专门流通信检查，或者在[XEP-0198]中定义的更全面的流管理协议。在这种情况下，对实体来说恰当的做法是发送<connection-timeout/>流错误（第4.9.3.4节）来关闭中断的流。

空闲对端

即使底层的TCP连接仍然激活，并且流没有被中断，对等端很可能在一段时间内都没有发送XML节。在这种情况下，对等端可以（MAY）关闭流（像第4.4节描述的一样），而不是让不再使用的流打开着。如果空闲对等端没有关闭流，那么与该流关联的另一端或者可以（MAY）通过使用第4.4节描述的握手方式来关闭该流，或者发送一个流错误（例如：<resource-constraint/>（第4.9.3.17节），如果实体已经到了打开TCP连接数的限制，或者<policy-violation/>（第4.9.3.14节），如果连接已超出本地超时政策）来关闭该流。然而，层（下面第13.3节指定）的顺序要符合，在得出对等端处于空闲状态的结论前，另一端需要去核实底层TCP连接仍然是激活的并且流没有被中断（前面已描述）。此外，在接受空闲对等端时最好宽容一点，因为经验表明，这样做可以提高在XMPP网络上通信的可靠性，并且保持两个服务器之间的流比积极地去超时一个流通常更有效。