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:
- Client makes request to Server
- Server doesn't respond (doesn't finish the request)
- Server waits until there's something to tell (to the Client)
- 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
- 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:
- You (Client) make a request to Server to fetch current info
- Server gives you that info and a timestamp
- Client receives info, uses it (show message) and makes new request with timestamp
- Server compares Client timestamp with Server timestamp (
filemtime
of a file in this case)
- If file change is newer than Client timestamp: print new file contents
- Client receives that info and the new Server timestamp
- 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).