I’ve got a client/server setup that I am implementing using a WCF Service (NetTcpBinding). The setup is such that the client basically sends a few commands and instructions to the server (mostly one-way calls). The server, however, may be in a situation where it needs to send a lot of data back to the client very rapidly. I’ve got this implemented currently using callbacks on the main WCF service (the server makes these callbacks very frequently).
But I’m having a heck of a time getting it to work correctly. It mostly seems to come down to exceptions/hangs (mostly hangs) that are occurring when the client calls to the server while the server is in the process of sending lots of data back to the client. I’ve tried just about everything have seen such as setting up most of my calls as [OperationContract(IsOneWay=true)] and setting ConcurrencyMode=ConcurrencyMode.Multiple on the ServiceBehavior. This has reduced the number of hangs, but not stopped them.
So, since it is most important for me to get a working solution quickly (deadlines approaching), I’m considering refactoring to have two WCF services. The first would be just like all the client-server calls now with the commands. The second would be in the opposite direction and would be setup after the client connected to the server. This service would be used to send the data back to the client.
Are there any drawbacks to this approach? Any problems with having WCF services going in both directions? Any other tips or tricks? Or am I completely off-base for this?
That doesn’t sound like a bad idea to me. The first service can add the commands or whatever to a queue that the second service uses to process in order.
You could even have the second service call back to the first service which would then call back to the clients. That way the clients just talk with one service which really doesn’t do much other than take requests and spit back results. The second service could do its thing in its own time.