To poll or not to poll (in a web services context)

问题:

We can use polling to find out about updates from some source, for example, clients connected to a webserver. WCF provides a nifty feature in the way of Duplex contracts, in which, I can maintain a connection to a client, and make invocations on that connection at will. Some peeps in the office were discussing the merits of both solutions, and I wanted to get feedback on when each strategy is best used.

回答1:

I would use an event-based mechanism instead of polling. In WCF, you can do this easily by following the Publish-Subscribe framework that Juval Lowy provides at his website, IDesign.net.

回答2:

Depends partly on how many users you have.

Say you have 1,000,000 users you will have problems maintaining that many sessions.

But if your system can respond to 1000 poll requests a second then each client can poll every 1000 seconds.

回答3:

I think Shiraz nailed this one, but I wanted to say two more things.

1. I've had trouble with Duplex contracts. You have to have all of your ducks in a row with regards to the callback channel... you have to check it to make sure it's open, etc. The IDesign.net stuff would be a minimum amount of plumbing code you'll have to include.

2. If it makes sense for your solution (this is only appropriate in certain situations), the MSMQ binding allows a client to send data to a service in an async manner (like Duplex), but the service isn't "polling" for messages... it gets notified when one enters the queue through some under-the-covers plumbing.

   This sort of forces you to turn the communication around (client becomes server, server becomes client), but if the majority of the communication is one-way, this would provide a lot of benefits. The other advantage here is obviously the queued communication - the server can be down and not miss any messages... it'll pick 'em up when it comes back online.

Something to think about.