0

I want to implement web site that will display to user a notification about some event happened on server. My plan is:

  1. to make an asynchronous request to the server (ASP.NET) which will have a 600 seconds time-out
  2. if event occurs on the server in the time interval of these 600 seconds server will response with an event details
  3. if event is not occurred the server then server will send an 'no event' response at the end of 600 seconds
  4. JS upon receiving a feedback from server will process the response and send the next request.

The problem of the approach is that for a big amount of visitors web site will have a lot of 'pending' requests.

Questions:

Should I consider that as a problem? What is solution for that? Probably I should implement another approach?

Please advice, any feedback is welcome.

Budda
  • 18,015
  • 33
  • 124
  • 206

2 Answers2

1

I don't know specifics about asp.net's handling of pending requests, but what you are describing is basically long-polling. It's tricky for a number of reasons, including but not limited to:

  • each pending request consumes a thread, and you'll need to store state on each of those threads
  • if you have enough connections (not necessarily all that many; see above), you'll need them to span multiple machines, and you then need to come up with an architecture to distribute endpoints across those machines, and make sure each incoming request goes to the right machine. If you're only broadcasting the same data to all your users, this becomes much easier.
  • proxies or ISPs or what-have-you may shut down your long-poll request. You'll need an architecture resilient to that.

Here's a question about long-polling in asp.net: How to do long-polling AJAX requests in ASP.NET MVC? It's probably a good place to start.

Also you could consider a 3rd-party service like pusher to handle these connections for you, or (disclaimer: I work on App Engine) App Engine's Channel API.

Community
  • 1
  • 1
Moishe Lettvin
  • 8,462
  • 1
  • 26
  • 40
  • Hi Moishe, thank you for your answer. Do you see any better idea how to avoid it? After some googling I've found the article (http://query7.com/avoiding-long-polling), but it doesn't really answer my questions... – Budda Nov 04 '11 at 05:26
  • If you need realtime updates, there's really no way around either polling, long-polling or (if you can assume modern browsers) websockets. You just need to make the cost/benefit call about whether the feature is worth the time & expense. – Moishe Lettvin Nov 04 '11 at 14:56
0

Surely you could make more frequent requests to the server that do not consume server resources for 10 whole minutes?

e.g. send an AJAX request every 60 seconds or so, and return whether or not any event has occurred. The downside is that it could take up to a minute for a user to see notification about some event, so if you need it more or less immediately, that is a problem.

If it does have to be immediate, it seems like looking into "long polling" with something like node.js might be a solution, though non-trivial to implement.

GregL
  • 37,147
  • 8
  • 62
  • 67
  • 1
    What he's describing __is__ basically long polling, it's not exclusive to node.js. – Na7coldwater Nov 04 '11 at 01:18
  • GregL, what you are suggesting is actually workaround. I've also thought about the idea to do frequent requests, but don't like it too much. But thank you for your answer. – Budda Nov 04 '11 at 05:20