0

First of all, I am completely new on many stuff, so I will welcome any inputs, including suggestions, existing projects, existing models, etc.

My current problems are:

  1. The background service maintains a queue of tasks. The background service is written in C++ or python.

  2. When a client clicks "Create Task" button in browser, the information will be sent to web server and the web server script (written in PHP) will initiate an RPC call to the background service to append the task to the internal queue.

  3. The client browser will initiate an AJAX request to wait for the completion of the task. The AJAX request will hold until the task is completed (or failed) or the client cancels the request.

Thus, I need an low cost way to get the task progress which is run on a background service process.

I can think of two ways:

  1. The background service can inform the server AJAX script about the progress pro-actively. This is low cost but I actually do not know how to do it. Does any RPC framework provides such asynchronous call back? Currently the RPC framework I decided to use is Thrift because of its multi-languages support.

  2. The AJAX script on server side will make an RPC call to get current progress every a few seconds, and sleep in between. Upon completion, the AJAX script will return, otherwise it will just let the client browser wait by not returning. This is actually simpler but I am not sure about its cost. Note that delay isn't an issue to me here because I suppose that the clients are okay to wait for a few more seconds.

Is there any common way/model to deal with this problem?

Thanks for the help.

user229044
  • 232,980
  • 40
  • 330
  • 338
user534498
  • 3,926
  • 5
  • 27
  • 52
  • Have you looked at WebSockets? http://websocket.org/ or long polling: http://stackoverflow.com/questions/333664/simple-long-polling-example-code – 0x6A75616E Dec 12 '11 at 15:15
  • thanks. just read through both. websocket is too new to be supported by most browsers, so long polling will be the way to go. – user534498 Dec 12 '11 at 16:32

3 Answers3

1

I think, You can use WebSockets for that.

Nick Shvelidze
  • 1,564
  • 1
  • 14
  • 28
1

You can use WebSockets.

Establish a WebSockets connection between the client and a web service that has access to the information you need to pass to the client.

With web sockets, you don't need to poll the server asking it for progress, but rather have the server notify the client whenever it's ready.

A backwards compatible implementation would be long polling.

Cheers

Community
  • 1
  • 1
0x6A75616E
  • 4,696
  • 2
  • 33
  • 57
1

Depends on how you code it. The common way to do it is to make a javascripted ajax request every 1-3 seconds or so and poll the progress from the server.

This will intermediately close the connection and be more gentle to the server. If you use a persistent connection (WebSockets also fall into this category), you will keep the server busy. Besides, a "sleep" keeps the CPU busy - which is something I would try to avoid if I were you. On the other hand, if you've got the resources for that...

I can only repeat myself: it depends on how you code it and what you expect of it in the end.

If you want the client do some more work and treat the server gentle, choose your 1st option and if you think your server can handle it, choose the 2nd option and go "persistent" and even use WebSockets (which represent persistent connections to your server - remember that they aren't widely supported by web-browsing clients yet either).

Although I think that in the end - the trade-off of a simple progress compared to hogging your server CPU with constant sleeps and some persistent connections on-top of that will make you choose your 1st option: poll the server script for the progress value every x secs from the client side. Btw.: it's what Twitter does and their servers survived until today! ;)