The current exponential back-off retry policy is designed with restarted or crashed servers or lost network connectivity in mind.
In case a protocol connection is established, but the initial protocol handshake fails (e.g. due to incompatible protocol versions), the client will retry very quickly. This retry will be successful so far another handshake will be performed, likely with the same outcome. Repeat.
In the face of errors such as above, the client should immediately go to the max configured retry timeout, to avoid excessive server load. One way to classify errors would be to retry quickly with exponential back-off only in the face XCM connectivity issues, and not in errors on the Pathfinder protocol level (e.g. wrong protocol version, not enough versions, permission issues etc).
The current exponential back-off retry policy is designed with restarted or crashed servers or lost network connectivity in mind.
In case a protocol connection is established, but the initial protocol handshake fails (e.g. due to incompatible protocol versions), the client will retry very quickly. This retry will be successful so far another handshake will be performed, likely with the same outcome. Repeat.
In the face of errors such as above, the client should immediately go to the max configured retry timeout, to avoid excessive server load. One way to classify errors would be to retry quickly with exponential back-off only in the face XCM connectivity issues, and not in errors on the Pathfinder protocol level (e.g. wrong protocol version, not enough versions, permission issues etc).