CODEWITHSUNDEEP
wcfarchitectureclient-serverwcf-client
mattanja
mattanja

Reputation: 1452

WCF best practice for client/server with notifications

First off: We have got a working solution for the problem I'm about to describe but it just doesn't feel right.

We have an application with one application server and about 30 - 100 clients. Scaling the server is not an issue. Most important are the notifications from the server to the clients, but of course there are also service-methods to be called from the client to the server.

What we do now is that we created a service contract with a callback channel, register the client in the service (i.e. the service contains a list of active callback channels) and send notifications via those callback channels.

Problems we needed to navigate around were:

  1. Timeouts of the connection - the service now contains some KeepAlive method that is pinged by the clients about every minute
  2. Re-connecting the client after server or network failure - which is the main point I'm concerned about. At the moment we have a long-running client object (service reference, inherited from DuplexClientBase) to call the service and the callback object to handle received notifications. On client.Faulted we try to replace the client and the callback object with a newly created client until the server can be reached again. This approach involves quite some weird exception handling...

Question: Would it be better to start a WCF service on each client and register the endpoint of each client on the server? Is there any better solution for the two problems described?

Edit: The point is: Am I missing something? - I believe the described architecture should be quite common and I am looking for the "default", best way to do it. Is there not some sample out there for this sort of setup?

Upvotes: 2

Views: 480

Answers (1)

tom redfern
tom redfern

Reputation: 31760

If your issues are around availability (in this case the availability of both service -> consumer and consumer -> service) then maybe you should consider using some more fault tolerant transport like MSMQ (perhaps using netMsmqBinding).

You could replace the complex WCF callback infrastructure with a simple, durable subscription store.

When you need to send a "callback" simply retrieve the list of consumers from your subscription store and send a message to each.

Connections would never time out because you wouldn't have a stateful connection.

Re-connections from consumers to service after network failures also is solved - in-fact small network outages would not even be noticeable.

Apologies this does not directly answer your original question, and appreciate re-work on this scale may not be within the scope of your requirement.

Upvotes: 3

Related Questions