WhoPinchedMyName wrote:Q: who knows even less than who?
They have a term definition problem. And both failed to recognize that.
Definition of a TCP Push.
1. There are two actors: server and client. These do NOT define implementation but rather how each behaves.
2. A 'server' is waiting for a connection.
3. A 'client' opens a TCP connection. This is exact step defines the push. The one that opens it is the only one that can be defined as doing the push.
4. The 'client' sends a message to the 'server'.
What if the 'server' sends a message to the 'client'. Doesn't matter. It can't do that until the 'client' opens the connection.
A browser, in general, uses HTTP which is built on TCP. So HTTP in any discussion is irrelevant.
A browser, as used by the vast majority of the public, does not have a public IP.
A browser, the common ones do not act as server because of that (at least for this discussion.) It would be pointless because without a public IP nothing on the 'internet' could do step #3 in the above list.
Web designers use API/libraries which use terminology that uses the term 'push' which has nothing to do with the above.
That sort of push does require that the browser acts as a client (see list above).
Terminology does not change that the 'client' (browser) must first open the connection.
An easy example of this is when a user asks for a report that takes a long time to run. They might sit there refreshing the page waiting seconds, minutes or hours for it to show up. Or the web designer might make the page refresh on its own. Thus at some point the user knows that the report is ready.
But if the browser is closed there is no way for the report service to 'push' a notification that the report is done to the browser.