Wcf callback net tcp duplex only one way with error

I have my own wcf service using net tcp duplex callback

on the client side, I listen to a failed event on Channel and ChennelFactory. when the channel is faulty, the client will recreate the channel and re-subscribe.

on the server side, I save the callback channel and save the channel link by invoking OperationContext.Current.Channel so that I can listen for the failed and closed event on this channel. If an error occurs, the server will delete this subscriber.

This works most of the time until recently, I observed an unexpected behavior: the callback channel is erroneous on the server, but the channel seems to be on the client side, this leads to the fact that the client does not overwrite while the server is already deleted, the subscriber and the client will not receive any callback.

I thought about duplex communication, if one of them found an error, the duplex channel should be faulty.

A reliable session is enabled, and the timeout is very long (2 hours) (maybe this can lead to the client end not detecting the error quickly enough?)

Can anyone explain why this is happening?

Another question is why is it still a mistake? I have 40 clients, but the server detected a random client that would be malfunctioning at any time.

+6
source share
2 answers

I am not sure of the reason. But I believe that the channel can fail in such a way that the failed event never reaches the client or server. There is also a case where a client crashes.

In any case, in my project, I came to the conclusion that relying on erroneous channel events is not reliable enough. Therefore, I regularly ping all subscribers from the server through the callback channel. If the client does not respond within the timeout, it is removed from the list of subscribers.

On the client side, you can also catch timeout exceptions and recreate the channel if necessary.

+2
source

Long timeouts are not to blame, I'm sure, because I'm in the same situation, and I also ran into a problem with short timeouts.

Dealing with faulty channels on the service side is very simple. You can try / catch a callback call and deal with it only when you really need it.

On the client side, right now, I see no reasonable way to do this. Hope someone offers something here ...

+1
source

Source: https://habr.com/ru/post/906702/


All Articles