I have a situation whereby an incompatible version of a client and server may attempt to communicate. The client calls a function on the server which returns a Struct, but the server and client versions of this struct are different.
This results in stream errors from the RO framework, which is fair enough, but I’m unable to trap the memory leaks that result. I can put an exception handler around the remote call to trap the exception but, due to the stream errors, no struct is ever passed back to my code so there’s nothing for me to free.
Is there any way I can deal with this scenario more cleanly and fix the memory leaks?
Will do when I get a chance. I’ve actually worked around the problem for now by using my own version control between the client and server to ensure incompatible versions can’t talk to each other in the first place
for avoiding such cases, you can implement a new method like GetServerVersion or pass some basic classes, say descendards of TROComplexType as parameters of your methods
also usage of TROSOAPMessage can help to avoid some problems with incompatibility
Just implement a “version” method in your service that returns a value (such as “2.3.1”). That way your client can know if it deals with an incompatible server or not.
I always increment the “major version” if a method has breaking changes, the “minor version” when just new methods are added and the “build number” for everything else.
Clients should refuse a connection to a server with a higher “major version”. If they’re confronted with an older server, they must know the limitations of that protocol version.
I already had a versioning system in place to ensure client/server compatibility, the issue was that the first contact a client had with the server was via a function which returned a struct containing basic server information, including the version number, which the client could then check.
Of course if this structure changes between versions then I’m in a catch-22 situation - the client will fail when calling the function. So I’ve done exactly what you suggested and added a simple function which returns the server version only as a basic integer type and which I’ll never change in future versions, so the client can always rely on that call succeeding regardless of version and will not communicate further if there’s a mismatch.
