[RCF::CallbackConnection] When to destroy ClientPtr ?

RCF support and general discussion.
Post Reply
acDev
Posts: 27
Joined: Tue Oct 08, 2013 3:08 pm
Location: Moscow
Contact:

[RCF::CallbackConnection] When to destroy ClientPtr ?

Post by acDev »

Example from tutorial:

Code: Select all

// Server-side - taking control of callback connections.
RCF::Mutex                                      gCallbackClientMapMutex;

typedef RcfClient<I_HelloWorld>                 HelloWorldClient;
typedef boost::shared_ptr<HelloWorldClient>     HelloWorldClientPtr;
std::map<std::string, HelloWorldClientPtr>      gCallbackClientMap;

void onCallbackConnectionCreated(
    RCF::RcfSessionPtr sessionPtr, 
    RCF::ClientTransportAutoPtr clientTransportPtr)
{
    std::string & clientName = sessionPtr->getSessionObject<std::string>();
    
    // Store the callback client transport in a global variable for later use.
    RCF::Lock lock(gCallbackClientMapMutex);
    HelloWorldClientPtr hwClientPtr( new HelloWorldClient(clientTransportPtr) );
    gCallbackClientMap[clientName] = hwClientPtr;
}
When need to destroy object in hwClientPtr ?
Remove item from gCallbackClientMap ?

jarl
Posts: 238
Joined: Mon Oct 03, 2011 4:53 am
Contact:

Re: [RCF::CallbackConnection] When to destroy ClientPtr ?

Post by jarl »

The hwClientPtr controls an individual connection back to the client. When you no longer need it, you can delete it (or equivalently, remove it from gCallbackClientMap), and that will close the connection and any associated resources.
Kind Regards

Jarl Lindrud
Delta V Software
http://www.deltavsoft.com

BigWCharly
Posts: 6
Joined: Sat Aug 30, 2014 8:19 am

Re: [RCF::CallbackConnection] When to destroy ClientPtr ?

Post by BigWCharly »

But what if the client has closed the connection? Is there a way to receive a callback when that happens? Then in the callback method the objects and data associated with it can be cleared => in this case erasing the HelloWorldClientPtr from the map

jarl
Posts: 238
Joined: Mon Oct 03, 2011 4:53 am
Contact:

Re: [RCF::CallbackConnection] When to destroy ClientPtr ?

Post by jarl »

Typically, each client will maintain a connection to the server, which it continues to use for client-to-server calls. When that connection is closed, or when the client e.g. calls a Logout() method, the server would then look up the corresponding server-to-client connection and delete it, along with any other associated resources.

On the server-side, you can use RcfSession::setOnDestroyCallback() to hook up a callback when the client-to-server connection goes down. There is an example here:

http://www.deltavsoft.com/doc/rcf_user_ ... Disconnect
Kind Regards

Jarl Lindrud
Delta V Software
http://www.deltavsoft.com

BigWCharly
Posts: 6
Joined: Sat Aug 30, 2014 8:19 am

Re: [RCF::CallbackConnection] When to destroy ClientPtr ?

Post by BigWCharly »

Excellent, thanks!
Is there a reference manual in which I can find an overview of all namespaces, classes, methods, ...?

Edit:
So I tried the following, but it does not work as expected.

Code: Select all

void OnCallbackConnectionCreated (RCF::RcfSessionPtr i_pSession, RCF::ClientTransportAutoPtr i_pClientTransport)
{
  i_pSession->setOnDestroyCallback (std::bind (_OnCallbackConnectionDestroyed, args::_1));
}
The method OnCallbackConnectionCreated is called by the RCFServer when a new callback connection is created. In this method I set the OnDestroyCallback.
The following happens:
1. A callback connection is initiated by the client
2. OnCallbackConnectionCreated is called
3. The OnDestroyCallback is set
4. !!! => The OnDestroyCallback is called <= !!!
5. !!! => The client does receive callbacks <= !!!

Then later when the client process is terminated, an exception is thrown in the server process when the server tries to send a callback.
[Ok, I could catch this exception and ignore it, but that's merely a hack]

Also I cannot solely rely on the client calling a specific method before disconnecting because this would still mess up the server when the client disconnects unexpectedly.

Thanks again for your help.

Edit 2:

Seen that this concerns callback connections, I think the proposed method cannot not work. Rather there should be some callback clientside when the server disconnects. I.e., the other way around as the proposed method.

Post Reply