The short question is: is it true that for Observer Pattern to work, there probably is some polling mechanism underneath? (update: in a network situation)
It was quite amazing that if on my Macbook Pro, I save a file Hello World.txt into the Dropbox folder, then I actually see it appearing on my other Macbook within 1 second or 2.
It is even more amazing that, on the other Macbook, if I do a search on Hello as a name match, and that Hello World.txt showed up there as a search result, and now I go to my Macbook Pro and rename the file as Hello World HiHi.txt, after 1 second or 2, then the new name actually showed up in the search result of the other Macbook. That is, the search results probably observe on any folder changes, and folder observes on the Dropbox state changes remotely on the Dropbox website.
So I am guessing that the Dropbox app probably has a 2-way TCP/IP connection so that, the Dropbox server can initiate a message to my Macbook’s Dropbox background app, saying “Hey, your folder content has changed on the server”, and then the Dropbox background app on my Macbook will do the rename, and my folder object (the model, or the data object) will then notify the search folder object, “Hey, my content has changed”, and the search folder object will then notify the folder view object, saying, “Hey, the search result has changed (and so you probably want to update the view on the screen)”.
So I think this maybe roughly how it worked? But the question is, if there was no TCP/IP two-way connection, then is it true that the Dropbox background app will have to poll the Dropbox server every 1 or 2 seconds to ask “did something changed?” And that will be too busy for the Dropbox server.
However, isn’t it true that even though there is a two-way communication set up, some where down beneath the TCP/IP layers (the 7 OSI layers), there is some kind of polling?
For example, the Dropbox server, at the very low level, cannot push an electron to my router, notifying my Macbook, because what if there is a firewall, then somehow, on my side, there must be some kind of polling at low level, or else the Dropbox server cannot push through my firewall.
Or, if viewed this way: if I am using WiFi on my Macbook, there probably is no mechanism of Dropbox server pushing something to my wireless router, and then use electromagnetic wave to push to my Macbook, to notify me? That is, my Macbook has to constantly ask the wireless router, “any thing new for me?” Because if the Macbook doesn’t ask — if the Macbook crashed or if the Macbook wireless firmware crashed and is not asking, there really is no “pushing of data” from the wireless router to the Macbook. The Macbook really has to “constantly ask”.
Isn’t it similar to the case that, if JavaScript on a browser had no two-way connection (before HTML5), somehow we can still have the web server “notify the browser’s JavaScript code”, but there will be some kind of polling underneath written in JavaScript, to simulate a two-way connection?
Update: I don’t mean polling necessary to the server, but I just mean some kind of mechanism has to constantly look to see if anything new, versus if it is Observer Pattern inside of code in an app, then the CPU will just “jump” to the code to execute the observer’s code, and therefore the observer really has to do nothing. But for Observer pattern over a network, what I mean is, say, if you have your notebook computer using Wifi, and you turn off your Wifi, then the Observer Pattern will not work. Now you turn on the Wifi, but the Wifi firmware or hardware really has to constantly “sense” whether something new has come in, because Wifi signal has no way to “force into the computer”, not like the Intel Processor can just “jump” to a chunk of code. So if either firmware or hardware has to constantly “sense” whether there is something new, that’s what I mean by polling — the Observer cannot be totally waiting; some mechanism has to constantly check for something.
5
Actually, I think you’ve got it backwards. At the low level of the internet, there is no such thing as polling. Everything on the internet actually pushes.
Internet messages are made of packets, which are basically bunches of electrons travelling down wires. From the computer’s perspective, packets simply show up either as electrons coming down a wire or electromagnetic waves being detected by the radio. Nothing ever asks for packets, they receive packets being sent along the communication medium.
When you visit a website, what happens is that you send a bunch of packets to the server, which responds by sending a bunch of packets back. We think of this as polling, because you sent the packets first instantiating the request. But at the low level of the internet, what happened was that you sent messages to the server, and the server just happened to send messages back to you later.
For example, the Dropbox server, at the very low level, cannot push an
electron to my router, notifying my Macbook, because what if there is
a firewall, then somehow, on my side, there must be some kind of
polling at low level, or else the Dropbox server cannot push through
my firewall.
No, the firewall accepts every electron in every packet that gets sent to it. It simply throws away those packets it deems suspect. In the case of dropbox, because your computer was talking to dropbox, it doesn’t deem the packet suspect, and thus forwards the packets on.
That is, my Macbook has to constantly ask the wireless router, “any
thing new for me?”
No, your Macbook doesn’t ever ask if there is anything new. Rather it listens for a wireless signal from the router. The router basically assumes that the Macbook always wants the messages, and sends them out as soon they come in.
Isn’t it similar to the case that, if JavaScript on a browser had no
two-way connection (before HTML5), somehow we can still have the web
server “notify the browser’s JavaScript code”, but there will be some
kind of polling underneath written in JavaScript, to simulate a
two-way connection?
No, javascript was restricted due to a quirk of how it was developed. The underlying internet technology has always fully supported two-way communication.
12
In practice, this is often true, but only because the Observer pattern is often used as an abstraction on top of some existing polling mechanism. There’s nothing stopping you from using Observers on top of non-polling mechanisms.
The typical example of an event/Observer system implemented on top of polling is keyboard/mouse events. The OS handles polling the hardware, and tells each application when it sees an even the application would be interested in.
My typical motivation for using an event/Observer system when no polling is going on is decoupling different parts of a program that shouldn’t know too much about each other. For instance, if your program subscribes to new stack exchange posts, your Subscriber class may fire a NewPost event that all of your UI classes listen to. This way, the Subscriber never has to know what the UI classes are, or what events they care about. This page has some more detailed examples.
What is true at the very lowest level is that there must be some hardware or software active at all times in order to generate events. This may be as low-level as an incoming signal causing hardware interrupts, or as high-level as a “game loop” calling the AI players every frame to generate various events for the UI classes. I would not classify these two examples as “polling”, though I suppose you could if you really wanted to.
11
Sure, if nobody automatically notifies you of a change, then you have to explicitly ask for an update, periodically or whenever you actually need it.
But whether you use TCP, UDP, or whatever as the underlying protocol is not important, the crucial thing is whether the communication is two-way or strictly one-way.
Polling is a software construct and is generally inefficient for low level IO operations.
When you rename a file and the propagation goes to another linked pc, it’s many forms of the observer pattern, from the click of the mouse to start the rename operation, to the changed file in the observed folder on the other pc.
Observer is a variant of publish-subscribe, and applies even at the network or data layer. See https://delog.wordpress.com/2012/09/14/applying-the-observer-pattern-for-protocol-parsing-and-handling/ for the TCP UDP addressing analogy.
Hardware is designed to generate interrupts when things happen. Software subscribing to interrupts is also like the Observer pattern. Inside the hardware you can think of it as “constantly asking” or sensing if something important happened, so the software doesn’t have to.