Data access by Client Pull or by Server Push

This is a design consideration between client - server interaction, i.e. whether client should call the server and pull the data from the server as and when required. Or the server should push the data to the client whenever there is some new data for the client.

Out of these two approaches, the first approach i.e. Client Pull is the most common approach where client opens a connection with the server (using any client/server protocol) and ask the server for the data. Here client pull the required data from the server as and when required.

Second approach is, where the server keep track of all its clients. Whenever server find any data which should be sent to the client, it pushes the data to the client. In this approach, there should be some provision using which server can interact to the client, like client should have some server socket open with it or client request should be hold on server for pending response for a long time. Now server keep track of all its clients. If we are working with server socket at the client, then it should be opened for all the time, so that server can connect to it anytime for pushing the data to client.

Sometime we find a need where server need to update the client for any latest data, like share trading software or weather information software. Here server keep getting updated data from multiple sources and now same data should be updated to all client terminals of the server. Now above mentioned both approaches can be used here as mentioned below:

• Client pull - It is the common approach. Here the client keep polling the server for the data after a fixed duration, duration used to be very small and decided based on the frequency of data update and performance factors. 
• Pros - Here everything is good
• Cons - However if frequency of data update at server is not fixed, then a continuous polling from client can be a overhead without any data update on most of the interactions. 
• When to use 
• When the data updates are frequent and almost regular after a fixed duration
• Like in share trading or weather information systems
• Server Push - There are different methods for Server push like
• A Server at Client - Client has a server socket open with it for all the time, so that server can open a connection with it as and when required. This way, server can open a connection with client also and send the data as and when it gets the updates. Here the limitation is that every client can not have the server socket open with it due to security reasons, like in web applications. However this can be done in desktop applications. It also consumes the resources at client side. This approach is useful if data updates are not regular, but are very very critical and hence should reach to the client as soon as these happen. 
• HTTP Server Push - Client sends the request to server. Server return the required data as response, however does not close the response connection and keep it safe with it for returning the next data. Whenever server gets the data updates, it writes the data to response connection with some small java script code which can help the client to understand the data. This major drawback of this approach is that, server does not have any control over the client. Hence any timeout at client can break the whole communication.
• Long Polling - Client sends the request to server for data. If server have the data, it respond to the respond, and if not it will put the request thread in wait till it gets the data. This way client keeps connected with server for a longer duration. As soon as, server get the data or in case of time out, it returns response to client. Immediately client sends another request to server for next data slot. So virtually client is connected all the time to the server, and server has a connection with client all the time to send the data. 

In brief, Client pull is common methodology however server push is used only for some special requirements considering the performance, frequency of data updates and security attributes as described above.