Pushing vs. Pulling

12 ביוני 2009

תגיות: , ,
אין תגובות

Few months ago I heard a lecture about "Velocity", in the begging of the lecture the lecturer asked the audience the next question: "Assume that you have a client which needs to communicate with a server, what is the best communication pattern to work with, pushing or pooling?" 99% of the audience voted for the pushing. It was a tricky question with a tricky answer – it depends.

I'll explain these two methods for all of those who aren't familiar with them.

Pushing – in this concept, the responsibility to transfer the data is on the server. Each time the server has some new data to publish to the client the server will connect directly to the client and will send it all the relevant data immediately.

Pros:

  • Using minimum resources to transfer a message (without extra traffic, network overload and etc)
  • The data will be sent and received immediately (without any delay).

Cons:

  • Scalability problem: The server needs to be aware for all clients, and which data should be sent for each client.
  • Availability problem: The client has high dependency on the server. In a case the server fell down, it'll be very difficult to determining it by the client.
  • Reliability and Durability problems: on the other hand, in a case that the client fell down, the server needs to implement a retries mechanism and store the message in some persistence storage, in order to insure the message will be sent successfully and completely to the client.

clip_image002

Pulling – in this method the responsibility for retrieving the data is on the client. The main challenge here is that the client doesn't know when he will need to connect the server in order to retrieve new data from it. In this case the client will need to use some monitoring techniques, every pre-defined interval.

Pros:

  • Independency – The client is fully autonomy. Each client only needs to be aware of its server.
  • Scalability: this method is fully scalable.

Cons:

  • Very "expensive" (using more resources, increase the network traffic, increase the processing time on server and client sides)
  • Delay time: the message won't arrived immediately, it'll be sent with a delay.

clip_image004

One of the solutions for this problem is to use publisher-subscriber pattern (aka "pub-sub"). In this pattern we have a third component which call the "pub-sub". Each client will subscribe to the pub-sub to get only messages which is relevant to him. The server will send all the messages to the pub-sub and will publish it to all subscribers' clients. In this pattern the server only need to send one message to one address without to be aware of all client locations.

 clip_image006

If we'll return to the question for the beginning, next time you will need to decide which one of them to use, just think about the components architecture, analyze the communication requirements and then do the appropriate choose for your specific design.

הוסף תגובה
facebook linkedin twitter email

כתיבת תגובה

האימייל לא יוצג באתר. (*) שדות חובה מסומנים