How to detect client-side if the server disconnects me?
Asked Answered
E

2

16

I have a WCF self-hosted service with a net.tcp DuplexChannel. On the server I run the following to disconnect a client:

((ICommunicationObject)client.CallbackChannel).Close();

This works fine but how do I detect on the client that it has been disconnected?

Ive hooked up to Closed and Faulted-events on both the InstanceContext of the callback and the channel to the server:

InstanceContext callback = new InstanceContext(callbackImp);
callback.Closed += new EventHandler(callback_Closed);

and

((ICommunicationObject)Channel).Closed += new EventHandler(Channel_Closed);

But nothing works. I never get notified. The workaround Im using now is to have a method in the callback that triggers a disconnect from the client-side instead. But I rather not do it this way. I especially dont want to let the server wait for a user to disconnect.

EDIT

I just realized that when disconnecting from client-side I run a method in the service-contract which is marked with IsTerminating = true:

[OperationContract(IsTerminating = true)]
void Disconnect();

I figured it would be the same on the callback-contract then? I tried adding the same method to my callback and it did terminate the callback-channel from the server point of view but I still didnt got notified on the client-side...weird

EDIT

I found out some more info about this:

When the server aborts the callback channel, a fault travels back to the client, the client faults and we get the Faulted event on the client.

When the server closes the callback channel, the session is still open until the client issues the close.

Once the client closes the channel you'll see the Closed event.

According to this statement the Close-event is not triggered mearly by closing the callbackchannel from the server, the client has to close it as well. So I could run Close on the client in the terminating Disconnect-method of the callback. Or I could use the Abort-method on the callback server-side and skip using a Disconnect-method on the callback. I dont know which one I preffer honestly. Hmmmm.

EDIT

I went with the Abort-approach. It seemed like the most logical method and it works really well. The client gets notified with the Faulted-event on the callback-instancecontext. Nice.

Enrage answered 30/11, 2010 at 19:38 Comment(1)
look at this I have same problem #3986847Henna
E
2

I went with the Abort-approach. It seemed like the most logical method and it works really well. The client gets notified with the Faulted-event on the callback-instancecontext.

Enrage answered 22/10, 2013 at 11:24 Comment(0)
I
1

You can simply do a callback just before closing the callback channel telling the client you're closing the channel.

So just before this line of code:

((ICommunicationObject)client.CallbackChannel).Close();
Irritate answered 2/3, 2011 at 17:32 Comment(2)
how about providing some more details about what doesn't work.... I know it works as there is some prod software out there running code using the callbackchannel. Don't recall exact implementation as it was 6 years ago, but imho, just saying it doesn't work and downvoting the answer is a bit childish.Irritate
The edits in the question explain it, closing the callback won't notify the client of it. You have to abort it so that the client receives the faulted event.Periodicity

© 2022 - 2024 — McMap. All rights reserved.