7

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.

Improve this question
5
  • 1
    On the level of the ethernet or wifi tranceiver, there is no polling going on. Instead, the hardware sits listening for activity and generates an interrupt towards the software if something was received.
    – Bart van Ingen Schenau
    Commented Dec 21, 2015 at 19:22
  • I saw it seems like the first 2-way communication is at OSI layer 5. Isn't it true once you have 2-way, then the other side can send something over to trigger the interrupt. But before there is 2-way, then there should be polling
    – nonopolarity
    Commented Dec 21, 2015 at 23:05
  • Polling means software is actively sampling the status of something. If your macbook's CPU was spending time "constantly asking," it would be too slow to do any work.
    – Fuhrmanator
    Commented Dec 22, 2015 at 4:06
  • What makes you think the layers below 5 aren't 2-way? Actually, they are all two-way, you cannot implement a 2-way communication on top of 1-way communication.
    – Winston Ewert
    Commented Dec 22, 2015 at 6:51
  • I think you're missing the concept of interrupts. At the deepest OS kernel-type software levels (but still excluding the hardware), everything tends to boil down to interrupts or polling. The former tends to be useful for infrequent events, the latter is useful for frequent events. The Linux kernel apparently uses polling when there's a high-frequency flow of incoming packets, but switches out of it and returns to handling interrupts when there aren't a high frequency of incoming packets.
    – user204677
    Commented Dec 22, 2015 at 20:10

4 Answers 4

Reset to default
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.

Improve this answer
12
  • you said "because your computer was talking to dropbox, it doesn't deem the packet suspect, and thus forwards the packets on" but I never configured the firewall to let anything through... and I don't think Dropbox can tell the firewall to open up to let things go through
    – nonopolarity
    Commented Dec 21, 2015 at 23:14
  • Actually, yes Dropbox can tell the firewall to open things up. When the dropbox client talks to the Dropbox server, the firewall automatically opens up the firewall so that the Dropbox server can talk back. Its going to be very restricted, only the exact same dropbox server can talk back, and only to the exact address that started the conversation. But it still does open up the ports that way.
    – Winston Ewert
    Commented Dec 21, 2015 at 23:22
  • You forgot photons, if you really want to go to the physical layer...
    – Sami Kuhmonen
    Commented Dec 22, 2015 at 4:54
  • @SamiKuhmonen, as a computer scientist I'm not really sure that physical layer actually exists.
    – Winston Ewert
    Commented Dec 22, 2015 at 4:55
  • 1
    The automatic firewall port opening depends on the program on your computer sending the first message. Once the first message is sent, then the firewalls opens. If you want another computer to send your computer the message first, then you need to manually open the port.
    – Winston Ewert
    Commented Dec 22, 2015 at 5:54
1

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.

Improve this answer
11
  • oh, I think I should have mentioned Observer Pattern in a network situation... it is true that if I registered function foo() to be invoked when the user clicks something, the code is just "invoked" without polling (it is the machine code running and just "jump" to some different code and run)... so I should say there is polling if it is through network
    – nonopolarity
    Commented Dec 21, 2015 at 23:11
  • @太極者無極而生 I guess that follow-up question would be phrased more or less like "Is it practical to have an IP/TCP connection without any form of polling/heartbeat?" Obviously you can have an IP-like connection with timeouts but no heartbeat poll, though I suspect there's no reason to do so in practice. Perhaps networkengineering.stackexchange.com would be the right place to ask about the practicality/necessity of a network heartbeat.
    – Ixrec
    Commented Dec 21, 2015 at 23:12
  • you said "as low-level as an incoming signal causing hardware interrupts"... so if there is a firewall that doesn't let anything come in, there has got to be some low level code that goes out and poll (in one of the network layers), find something important, and come back and trigger a hardware interrupt on the local machine?
    – nonopolarity
    Commented Dec 21, 2015 at 23:19
  • @太極者無極而生 Nope, the whole point of hardware interrupts is that they don't rely on polling, they actually are "events" at the hardware level. Perhaps the most important use case is that an OS will switch between itself and user apps via hardware timer interrupts. That allows each application to run directly and exclusively on the CPU until its "time slice" is over. You may want to read a book about CPU architectures or operating systems to get a full understanding of this stuff (or join us in chat).
    – Ixrec
    Commented Dec 21, 2015 at 23:31
  • events != Observer pattern
    – Scant Roger
    Commented Dec 22, 2015 at 2:58
0

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.

Improve this answer
0

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.