Once you escape the realm of electrical signals and are dealing with software, is there really such a thing as a "push" architecture where there isn't periodic polling?
I can't think of any design where it's not polling at some level. It seems like it's always just a level or two beneath the actual abstraction/API you are dealing with. Sockets at the receiving end of most "push" connections just poll for incoming requests, etc.
I think Windows required applications to poll for IO until NT and Windows 95. Modern general purpose operating systems have pretty much eliminated the need for polling. When your application requests to read from a socket, the read function has to make a call to operating system kernel. The OS puts the calling thread into a suspended state. As network packets come in they trigger a hardware interrupt that is handled by the OS. If the packet is the one your application is looking for, the OS takes the thread out of the suspended state, and the read can proceed. In other words your application is in fact coupled to the realm of the electrical signals via the OS.
websocket architecture is a push architecture, actually so is exchange & outlook. These protocols stay connected to the server at all times and the server sends messages (pushes them) whenever there are messages...
I would also consider sockets that Charles already presented to certainly be "push" design. He walked you all the way from the realm of the electrical signals up, but another topic to consider are "push" designs which are purely application architecture decisions and happen at much higher abstraction layers.
Typical event frameworks would be considered push, since event source will fire events regardless of who is listening for them, or if the event sink is able to keep up with those events.
Another example, which is the area where I work in, is video streaming. We work with RTP (real-time transport protocol). It is UDP/IP based and by nature it is a push protocol. The sender will keep sending video at the rate it chooses without ever caring if the receiver is keeping up with it.
Sure there is. UDP socket applications in Unix, for example, can be pure-push. The best known would be the classic BSD Unix syslogd, which declares its willingness to accept incoming ("pushed") packets and processes them. No reverse communication at the application or protocol level (the "pusher" doesn't even know if the packet was correctly received and processed). At an API level within the receiving application, there may be polling, synchronous, or callback reception mechanisms, the latter two of which are pure-push.
