No response to End Processing
-
When the object connecting to a stream does not receive any XMPP information from another peer that is also connected to the stream within a period of time, the peer may be unresponsive. There are several possible causes:
-
- The underlying TCP connection is dead.
- Even if the underlying TCP connection is still activated, the XML Stream is interrupted.
- The peer is idle, but the XMPP information is not sent to the object through the XML Stream connected to it.
-
The three conditions should be treated separately, as described in the following chapter.
-
-
Note: To handle non-responding peer, we treat two one-way TCP connections as a two-way TCP connection in concept (see section 4.5 (directionality). However, the implementer needs to know that when two one-way TCP connections are established, the peer-to-peer communication response at the XMPP application layer will be returned from the second TCP connection. In addition, the use of multiple data streams in each direction (connections between servers and servers of large XMPP service providers are often deployed in this way) the application-level check of the XMPP stream and the underlying TCP connection is further complicated because there is no inevitable connection between any given initial stream and any given response stream.
Dead connection
-
If the underlying TCP connection is dead, flow-level checks (for example, [XEP-0199] and [XEP-0198]) are invalid. Therefore, no matter whether there are any stream errors, you do not need to close the stream. The proper way is to terminate the TCP connection directly.
-
A common method for checking TCP connections is to send a space character (U + 0020) between XML sections, and send spaces in the XML Stream is allowed, as described in section 11.7 below. Sending such a space is called "Space holding activation" (the word "whitespace"
Ping is usually used, although in fact it is not a ping, because "PONG" is impossible ). However, sending space characters is not allowed during TLS authentication and SASL authentication, which will be described in sections 5.3.3 and 6.3.5 below.
Interrupted stream
-
Even if the underlying TCP connection is still active, it is very likely that the Peer never responds to the XMPP Communication Request from the entity, whether it is a normal section or an application defined in [XEP-0199] ProgramSpecialized stream communication checks such as level Ping, or more comprehensive stream management protocols defined in [XEP-0198. In this case, the proper way for an object is to send a <connection-Timeout/> stream error (section 4.9.3.4) to close the interrupted stream.
Idle peer
-
Even if the underlying TCP connection is still activated and the stream is not interrupted, the peer end may not send the XML section for a period of time. In this case, the peer can (May) Close the stream (as described in section 4.4), instead of opening a stream that is no longer in use. If the idle peer does not close the stream, the other end associated with the stream may close the stream by using the handshake described in section 4.4, or send a stream error (for example, <resource-constraint/> (section 4.9.3.17). If the entity has reached the limit on the number of TCP connections enabled, or <policy-violation/> (section 4.9.3.14), if the connection has exceeded the local Timeout Policy) to close the stream. However, the order of the layer (specified in section 13.3 below) must be consistent. Before the conclusion that the peer is idle, the other end needs to verify that the underlying TCP connection is still active and the stream is not interrupted (as described above ). In addition, it is better to be more tolerant when accepting idle peer, because experience shows that this can improve the reliability of communication on the XMPP network, in addition, it is more effective to keep the stream between two servers than to actively time out a flow.
