"Push-pull" is one way for two actors (objects, functions, whatever) to communicate with each other in a system. It is best understood in comparison with the simple "push" model.

Imagine two actors in a system: Alice generates data from some unspecified hardware, and Bob uses that data to do some unspecified processing.

Push

A simple model, called the "push" model, is one in which Alice simply sends all the data to Bob every time she has something new. The ease with which this model can be implemented (indeed, many programmers use it without even recognizing it in their designs) is its greatest strength. But it's not without its faults.

Imagine that Alice's data is huge. The push model requires that whenever Alice has new data ready, Bob has to drop whatever he's doing and be ready to accept it as soon as Alice calls. If the data is huge, Bob has to ensure that he has enough memory available at the moment to manage whatever Alice is sending. Worse, he doesn't know when Alice is going to call, so he has to be ready for it anytime.

Pull

Another model, almost as simple as the push model, is the "pull" model. In this model, we reverse "who calls who". While the data itself still moves from Alice to Bob, as our system requires, it's Bob who calls Alice to get the data. Bob, sensibly, would wait until he's ready to accept the new data before calling Alice, so he only calls when it's convenient. Alice, on the other hand, does have some of the same problems Bob has in the push model: she has to be ready for Bob to call anytime. However, because she'd have to generate and hold the data in either model long enough to get it to Bob, it's generally easier for Alice to shoulder the burden in the pull model than it is for Bob.

Unfortunately, the pull model has one extra disadvantage over the push model. How does Bob know when Alice has new data available? He doesn't, so instead he keeps calling Alice over and over (this is often called "polling") until she has something useful for him. Every time Bob polls Alice, she has to drop what she's doing and answer him, then go back to generating more data. This is wasteful, and if your communication system is already pretty busy, this just makes it worse. Additionally, what if Bob doesn't always need all of Alice's data? Isn't it wasteful to always send tons of data that aren't used?

Push/Pull

A combination of the push and pull models can make a lot of these problems go away, at the expense of adding complexity. A push/pull model is one in which Alice pushes a short note to Bob indicating she has data available for him; after getting the note, Bob then calls Alice back when its convenient to him to pull the data over.

This solves the silly polling problem ("Are you ready yet? Are you ready yet?" "Are you ready yet?"...) yet still lets Bob decide when he has to deal with the data Alice has available for him.

It's also easy to further refine this protocol such that Bob can control which parts of the data he receives. Imagine, for example, that Bob uses Alice's data in a long chain of multiplications. Clearly, if Bob detects a large number of zeroes in Alice's data early on, he can recognize that he doesn't need the rest of the data. If Alice's data is huge, Bob can save a good deal of effort by never asking for the rest of the data. This turns out to be one of the common applications of push/pull: to let actors negotiate data transfers between them without putting stressful assumptions on either side.

-- BobKrzaczek - 13 Jun 2004