views:

179

answers:

3

We are currently developing a server whereby a client requests interest in changes to specific data elements and when that data changes the server pushes the data back to the client. There has vigorous debate at work about whether or not it would be better for the client to poll for this data.

What is considered to be the ideal method, in terms of performance, scalability and network load, of data transfer in a near real time environment?

Update: Here's a Link that gives some food for thought with regards to UI updates.

+1  A: 

As long as the client initiates the connection (to get passed firewall and NAT problems) either way is fine.

If there are several different type of data you need to send, you might want to have the client specify which type he wants, but this is only needed once per connection. Then you can have the server continue to send updates as it has them.

It would be less network traffic to have the server send updates without the client continually asking for updates.

Brian R. Bondy
A: 

What do you have on the client's side? Many firewalls allow outgoing requests but block incoming requests. In other words, pull may be your only option if you are crossing the Internet unless you are sending out e-mails.

eed3si9n
We have our own client side software and at this stage we're not operating over the internet.
Darren
+3  A: 

There's probably no ideal method for every situation, but push is usually better and used more often. It allows to optimize server caching and data transfers, which helps performance and scalability, and cuts network traffic a bit by avoiding client requests and empty responses. It can be important advantage for a server to operate in it's own pace and supply clients with data when it is ready.

Industry standarts - such as OPC, GID - support both. Server pushes updates to subscribed clients, but client can pull some rarely used data out without bothering with subscription.

ima