Client/server model where the server rejects connections from *newer* clients

Question

I'm using a piece of commercial software where the server will reject any attempt to connect to it from a newer client. In other words, you can use version 8 of the client to connect to a v10.0 server, but not version 10.1 of the client.

Obviously, this software is what it is. But why would it be designed that way? Why would clients not be backwards compatible? What benefits (if any) does this arrangement have?

This setup just seems very counter-intuitive to me, and I want to try and understand it.

_{(The software happens to be a database, but I don't think it matters to the question.)}

Answer 1

If the server only responds to requests from the client and new interface versions only add new requests (existing requests and responses are never changed), then disallowing newer clients means that neither client nor server need to explicitly support multiple versions of the protocol.

In that case, if a version 8 client connects to a version 10 server, then all the version 8 functionality is just there and the newer (version 9 and 10) functionality never gets requested.
On the other hand, if a version 10.1 client would successfully connect to a version 10 server, then the client would need to know which functionality was newly introduced in version 10.1 compared to version 10 (and possibly all the way back to version 1). This is quite a burden for the client and it is way easier to just blindly disallow such connections and work on the premise that if the connection succeeds, then the server supports at least all the commands that the client knows about.

Answer 2

It is odd that a 10.1 can't communicate with a 10.0 version (I'd expect at least a major version difference before that happened).

The designer probably didn't want the client app to be weighed down by the compatibility layer needed to connect to the older server, while the server can fall back on the older protocol if needed.