What does AJAX Push have to pay to get web pages more interactive?

(Sorry if the topic isn't titled properly, would appreciate if somebody helps me to make it more related to what I explain below).

Recently I feel very interested in getting to know AJAX push and all its basic ideas. I know AJAX push technique makes the web pages more interactive on the server-side, but behind all the smoothly interactive movements, there are apparently some "hard-work" behind the stage, in both implementation and how it deals with resources.

So in brief, let's forget about the implementation, I need somebody to explain me the way AJAX push works with respect to server connection, how (or how much) resources are used, or some other aspects that should be taken into account when implementing this method.

I haven't done much research so you have any documents related to this, I'm more than happy to read.

I don't really see how "ajax push" is a thing. I know long polling and I think it's the same.

The downside of long polling is that your server can have a lot of unfinished requests open. Not sockets, but actual requests. The idea of long polling:

1. Client makes request to Server
2. Server doesn't respond (doesn't finish the request)
3. Server waits until there's something to tell (to the Client)
4. When the server receives new information (from another Client or somewhere else) it prints that information to all waiting Clients (can be a lot!) and finishes the request
5. Client receives that information and immediately makes another request (with new timestamp and/or hash etc)

The downside: if 500 clients all do step 1 and nothing else, the server has 500 requests open and is just waiting to send some information and end those requests. Most servers don't allow 500 open HTTP requests...

If you have time, you might want to read this PDF. (It's long though.)

PS. The upside is that your server receives less HTTP requests (which means less HTTP overhead) and that information is only sent when there's something to send (which also means less overhead).

edit
Long polling example: http://hotblocks.nl/tests/ajax/poller/ with source http://hotblocks.nl/tests/ajax/poller/callback.php?source

explanation
The upside: less HTTP overhead, because less HTTP requests. Let's say the amount of users is static (it is) and 500.

With long polling: 500 users make 1 request and then wait............ and then something changes and all 500 requests are finished (by the Server) and then 'renewed' (new HTTP request) by the Client.
Upside: less requests (1 per user per new information).
Downside: longer requests (very long idling, which means more open requests).

Without long polling: 500 users make a request, server responds with "nothing new", so 500 users make another request 500ms/1s/5s later and the server responds again with "nothing new" etc etc etc until the server has actual news and then the response contains something. And even then the clients immediately make a new request.
Upside: quick, short requests to the server that can be finished quickly.
Downside: many, many, many of those requests to the server (and every HTTP request => HTTP headers => MUCH overhead).

example explanation
The example is very (much too) easy:

1. You (Client) make a request to Server to fetch current info
2. Server gives you that info and a timestamp
3. Client receives info, uses it (show message) and makes new request with timestamp
4. Server compares Client timestamp with Server timestamp (filemtime of a file in this case)
5. If file change is newer than Client timestamp: print new file contents
6. Client receives that info and the new Server timestamp
7. Step 3 again etc

Time between step 4 and 5 can be very long. In an active chat, it won't be. (New information is added all the time.) In a multiplayer game, it might be (seconds, not minutes).