Now that a network has been constructed we need to think about how to operate it. Even more important (and not always done) is to think about how it SHOULD be operated before it is built. It is important to think “will be operated” intead of "will operate. Even an automated system is operated, just not by explicit personnel, and the design process helps assure that is so.
The language is called ACAC (or CACA), and the letters remind us of the basic tasks of Creating and Absorbing information.
When in PEPE we talk about push and pull very obvious questions arise. There is information and there are components, and the terms relate to both. Of course PEPE shows the component the information is coming from or going to, but what about the information itself?
Two new concepts enter our thought: a Source is something information comes from, and a Sink something it goes to. Both sound perhaps like a storage unit (PEPE says Pipe or e) and that is a proper passive view.
A passive Source has been pushed already, so we can just pull it when we need to, perhaps many times and from many places, even indirectly through Pulls. We will always get the same information. It may change because the source is replaced, but we have no control.
A passive Sink is similar in reverse. We push a Sink whenever we are supposed to, and the information is potentially gone forever. If retrieval were ever to be desired a Pipe would have been used in the design.
My personal model for passive Source and Sink has always been the one used when benchmarking networks for speed. You want to consider only communications time, not processing, so a Sink just throws the data away, never even writing it into memory or storage, and a Source just gives out predetermined data that may even be constant, so that part will be constant when the benchmark is repeated.
When it comes to active Sources and Sinks, a whole new question emerges. Do we need to tell comonents to act, or do we just assume it occurs? For example on output we may want an acknowledgment that a buffer has been pulled before we push new data, and on input we may want to know that new data has been pushed and should now be pulled.` Environmental measurements are often a good example: you may only need to show the current temperature, not to remark its getting hotter! or to ask did you see how hot it was?.
My favorite classroom experience in the early days of computing (when books on operating systems were rare) was to bring in two early PC’s, one with “polling driven” input and output and the other with “interrupts”, and let the students try to predict in advance how communications would go!
These considerations say that:
A similar set of issues arises with Push and Pull:
or is it expected that the Pull will notify upstream that new data should be pushed.
or does Push politely notify downstream that the old data should be pulled?