0

As far as I understand it one of the things servers are very good at is managing large numbers of incoming connections, allocating those connections resources as they become available and then disposing of those resources once they have serviced the incoming requests so that they can service more requests.

By allowing a client to register a callback with a server, the client essentially takes an element of control away from that server because it now allocates itself a proportion of that server's resources for some unspecified amount of time that is, to a certain extent, beyond the control of the server (of course the server can kick the client off at any time to claim those resources back, but that all starts to get kind of complicated).

The more I think about it the more I feel like WCF callbacks are basically an anti-pattern and that polling should be preferred except in exceptional cases.

Is that right and in which case what are those exceptional cases?

satnhak
  • 9,407
  • 5
  • 63
  • 81
  • 1
    "it now allocates itself a proportion of that server's resources" - isn't that fundamentally what happens when the client connects (presumably frequently) in a polling scenario? In general it seems to me that "things servers are very good at" is more a function of the software written on them than anything else. There may be good reasons in a given business case to go one way or the other, but that's based on the requirements, not a fundamental truth about servers. – joelt May 11 '13 at 17:26
  • You've quoted that out of context. The point is that once a callback is registered (i.e. to receive notifications) it now takes a proportion of the server's resources (specifically it takes a thread and a connection) until it stops notifying. After a finite number of clients register the server is full and all it can do is service those clients. Under the polling model the number of clients that can be serviced is not so constrained because although each one might ask often it has to get back in the queue each time it asks. It is fundamentally more scalable. – satnhak May 11 '13 at 19:58
  • If you're still watching this, I found it to be really interesting. I was surprised that the default behavior is what it is-the client call method doesn't complete until the callback fires, and in that case I would say the callback mechanism is pointless at best-but I found that you can call the service in an async manner, and if you farm out the service work to a new thread, you don't get the WCF connection behind held. If you have a cpu-bound service, there's still a thread being consumed, but there's no way around that. I think IO-bound services could get the thread back also if done async – joelt Jun 01 '13 at 00:42

0 Answers0