tags:

views:

150

answers:

1

I have a WCF server that exposed an interface that has a call-back interface it uses to send events to the clients.

I rather not mark all the methods on the call-back interface as “OneWay”, as it make error tracking and logging harder.

The client is written in WinForms, so the call-backs will not be processes until after the call to the server has returned. (This is the behaviour I want)

I make all the call-backs with Asynchronous Eg. BeginMyMethod(...), so the server is not blocked waiting for a client.

However if a call-back is sent to the same client as sent the request to the server, then the TCP channel deadlocks it’s self, as it does not seem to be able to send the response back to the client, before the client has send the call-back response back to the server over the same channel.

Is there a way to do true bidirectional communications over a single TCP connection in WCF?

A: 

You can do this if both the server and the client acks as both a server and a client (if that is understandable)

It would work like this:

  • When the client starts it calls the server and registers itself
  • The server then knows where the client is and can contact the client via the services that the client exposes.

Another, simpler solution would be not to reuse the chanels, thereby avoiding the deadlock.

Shiraz Bhaiji
I am starting to think that it is best just to use a seperate chanel for all events from the server to the client(s) and not try to do events on the same chanel as is used to send commands to the server.
Ian Ringrose
I am accepting the answer, as I don't think there is a better option then "not ot reuse the chanels"
Ian Ringrose