Delta V Software Forums

Hi Jarl,

we have the following problem :

A RCF client connects to a RCF server via TCP. After connection has been established the first thing that happens is some kind of initialization. The RCF server constructs a session object and stores the necessary information about the client. After that the client periodically sends messages the server has to process.

Now consider a restart of the RCF server. The TCP connection will be reestablished after restart of the RCF server and the client may not even notice that there has been such an event (RCF internals quite do but IMHO 'we' don't). Unfortunately the RCF server lost all the initialization stuff and is no longer able to process the incoming messages.

First idea we came up with was that the RCF server will throw an exception to signal the client side that the initialization has not taken place. The major drawback of this approach is that in case you would like to handle this in some kind of intermediate layer (the top layer maybe doesn't even know that RCF is used as a work horse), you would need to place an exception handling around every single method used to forward the information to the server. Even worse some of the methods are defined as oneway for performance reasons ...

Obviously we are looking for a smarter, more elegant solution.

I'm sure you can help us !

Regards,

Volker

Generally to deal with this you would need a generic retry loop that you can apply to all your remote calls. What we've done in situations like this is to capture the remote call as a boost::function (using boost::bind to bind all the arguments), and then pass that into a generic retry function that executes the remote call, checks for exceptions, and optionally reconnects and retries the call.

There are other possibilities as well.

You can call ClientStub::isConnected() before making a call. If the server has disconnected the client in an orderly way (e.g. server process closed or restarted), then isConnected() will detect that the connection is no longer up. However, for abrupt disconnections (e.g. network cable pulled out), isConnected() will not be able to detect the disconnection, and you'll instead get an exception when you make the call.

You can also try making a preliminary "ping" call before making the remote call. That will cost you an extra round trip, but it's easy to implement and will catch any form of disconnection. You can use ClientStub::ping() to ping the server.

With the one-way calls, you don't know what's happening on the server side, so there really is not much you can do in terms of error handling... You may need to look at other ways of getting a performance boost.

Thanks for your detailed explanations. I will see whether one of your suggestions apply.