1

I want to build an application which will automatically broadcast notification(s) to a user when data on server is changed. So far, I just know one method of doing this i.e. using JQuery setInterval. Using this function, every client requests data through ajax to server, asking if something changed.

The weakness of this method is every client must send a packet every specific time interval, so my server receives huge data packet. It's so frustrating to manage the server. Are there any alternatives for this besides Jquery setInterval?

Ozair Kafray
  • 13,351
  • 8
  • 59
  • 84
AdrianUsagi
  • 39
  • 1
  • 5

1 Answers1

2

If Websockets is not an option for you, you could use one ajax request to the server. Than server side go into a infinite loop. Use the sleep function to not overload the memory. Than check each time if there is something changed. If so, break out the loop and return the data. On the client side send immediately the next request.

After a bit of research it's called "Ajax long-polling requests".
Here is a explanation.

The PHP code would look something like this:

$prevHash = $_GET['hash'];

while(true){
   $currHash = GetHashFromTable('myTable');
   if ($prevHash != $currRowCount) break;
   sleep(3);
}

$response[0] = GetDataFromTable('myTable');
$response[1] = GetHashFromTable('myTable');

echo json_encode($response);

Update

Long polling is not the best option. Better to use web-sockets. If you want to compare the differences, see this answer: https://stackoverflow.com/a/10029326/3269816

Community
  • 1
  • 1
Andreas Furster
  • 1,558
  • 1
  • 12
  • 28
  • Why not? This is just an alternative to websockets and client side intervals. And i understand the problem of the author, so i have nothing to ask him... – Andreas Furster Oct 28 '14 at 09:50
  • Let me explain. Your answer has been flagged by a person or robot and placed in a low quality review queue. Volunteers then pour over these posts. Although I may have been hasty, when I see a phrase like 'I just got an idea, I don't know if it will work.' it sounds like more of a comment than an answer. Now that I've taken a little more time, your answer sounds somewhat like [server push](http://en.wikipedia.org/wiki/Push_technology). With a bit more (maybe a bit of code, or excerpts from a link) it would not seem low quality. As I write this others are voting on answers' quality... – Paul Oct 28 '14 at 09:58
  • Ok, i understand. But i have read a while ago in the FAQ that it's ok to post answers that your not sure of. And i don't know if it's the same as server push. I tried my idea in ASP Web api, and it works great! – Andreas Furster Oct 28 '14 at 10:11
  • I'm glad you got something working. It would probably help the other person if you posted some code. As far as posting answers you are unsure of, apparently you were right. [Try This: blah blah blah](http://meta.stackexchange.com/questions/118582/what-is-an-acceptable-answer) is apparently an acceptable answer according to the linked FAQ and has been discussed similarly [here](http://meta.stackoverflow.com/questions/256359/flag-try-this-code-answers-as-very-low-quality). So you are correct in that people shouldn't be voting to delete... quality is always the best way to avoid the issue. – Paul Oct 28 '14 at 10:25
  • I wonder if the author of the question even want to see code. I think he just wants an idea of a solution. But thanks for clarifying. – Andreas Furster Oct 28 '14 at 10:33
  • Google indexes the SO questions fairly well, so if you can think of a way to rephrase the title of the question (which is allowed and even encouraged) and also post relevant code, it might be noticed by and help many people. Or not. It is up to you how much effort to put in. – Paul Oct 28 '14 at 10:38
  • The OP is already doing long polling and he even mentions using JS's `setInterval` to query the server periodically. I don't see the point of repeating the same honestly. Serverside push is done by Websockets. Everything else is emulating that push. – N.B. Oct 28 '14 at 10:48
  • "The weakness of this method is every client must send a packet every specific time interval," sounds like standard (short?) polling. From what I read of long polling, it sounded like a request is sent that is not replied to until there is actually some data. That's different from sending back "no data" over and over and the browser side asking over and over. – Paul Oct 28 '14 at 11:04
  • @Paul - whether you keep a connection open indefinitely or immediately return the data, you're creating overhead. Anything short of Websockets is a simple emulation of server-push. A case where you keep the connection open for extended period of time uses up the server's thread for that connection. The option where you query based on intervals produces lots of bandwith and cpu waste. Therefore, if not websockets = emulating the push, with a different tradeoff. Hence, this answer and what OP uses are, for all that matters, the one and the same approach. – N.B. Oct 28 '14 at 12:01
  • Howver, you are correct with the definition of long and short polling, I'll leave the comment in so that it's clear what you were referring to. Anyway, I'd suggest an edit to this post to include more information so it can be considered as a proper answer. – N.B. Oct 28 '14 at 12:03