WhoPinchedMyName wrote:I don't undersatand your definition of client and server
My first response defined those specifically.
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.
Too much detail for this but TCP is a protocol that defines communication and establishing the connection in the first place requires a 'client' and a 'server'. Using specifically and only the definitions above.
Do not confuse those with what you might think of when using a browser and what it connects to (certainly related and it does use the protocol but it definitely uses layers on top of those.)
WhoPinchedMyName wrote:a client is traditionally thought of as the end-user (or their browser), and a server is what sends them pages/data/whatever upon request.
That is either phrased badly or is wrong.
The traditional browser server idiom is that the browser requests (a specific type of message/data) and the server responds (a specific type of message/data) to that request.
In terms of TCP (not HTTP) the server does in fact 'send' the response based on what the client (browser) 'sent' the request.
WhoPinchedMyName wrote:So a so-called "push notification" (from ther server to client) can only happen if the server has had such a "something" establishing (or keeping alive) a connection - that "something" telling it where to push the notification to
I can't even suggest that is phrased incorrectly. It is just wrong.
There is no communication without an open socket. None. Nothing can be sent in any way from any side unless the connection already exists.
There are two parts to the socket/connection
1. Open the socket
2. Use the socket.
Messages and communication from either side only happens with #2.
WhoPinchedMyName wrote:SO how does this differ from the client using a simple AJAX call on a setTimeout to
Now you are confusing how libraries and protocols that live on TOP of TCP work. And perhaps because their documentation is confusing and the documentation is overloading terms for their own reasons.
It does not matter what those 'claim' to do. They must all follow the rules of TCP because otherwise there absolutely no communication no matter what they do or how they claim to do it.
WhoPinchedMyName wrote:that it can run as some kind of background service - well, whooppee
In terms of the entire modern architecture from the browser all the way to the backend servers (multiple ones) and persisted data stores and third party services...yes background servicing is essential (technically threading processing.)
Might not be something you care about now. Might not even matter to you ever depending on where your focus lies.