ASP.NET Updating a control from a separate thread

sunama · 3 Oct 2012 at 18:55

Hi,

I have an ASP.net app, which connects to an external server (using TCPIP).

I need some ideas on how to achieve the following:

the GetServerMessage() thread is constantly running once the app connects to the server. It waits for the server to send message.
Periodically, the server sends the app messages.

I need a system where any messages sent (by the server) to the app, are displayed a text box.

Can anyone advise me on the best way to achieve this?

I am using basic Web Forms...no silverlight or MVC.
I want to keep things as simple as possible. Nothing complicated or too clever.

Current System - heavy server load - bad design
I have this system already running using a Timer control, which updates the contents of the textbox (which is in an update panel), HOWEVER, the timer sends a message and forces a partial reload/postback every X milliseconds. The problem with this is ultra high server load. A partial postback every 10ms, for example, would eventually overload the ASP.NET server.

What I want is to do away with Timer so the (partial) postback only occurs if a message is received from the server.

Any advice would be greatly appreciated.

Thanks

Pho · 3 Oct 2012 at 19:26

Sounds like a simple job for jQuery AJAX - have the client poll over JavaScript for any new messages every x ms and put the results into the text box.

http://www.tugberkugurlu.com/archiv...calling-web-service-page-methods-using-jquery

(no idea if that's the best guide, I tend to roll my own stuff)

Shad · 4 Oct 2012 at 08:09

Your best bet is as above, use jQuery and a simple JSON WCF endpoint you can poll for updates. If it wasn't a web app you could do what you want to without the need to poll, using either WCF or Remoting.

The MS AJAX stuff (UpdatePanel etc.) is pretty nasty and heavyweight compared to AJAX with jQuery. Do you really need to be polling 100 times a second? If you could reduce that to a 100ms interval that would help, although over the Internet that's still a very large number of requests to deal with especially if there are multiple users. Without knowing your system I'd be surprised if 1000ms or even 5000ms wouldn't be suitable.

GravyMonster · 4 Oct 2012 at 08:31

I agree with what Shad said. Most games won't even refresh at 10ms! For a web app updating every 1 or 2 seconds is more than responsive enough.

Dj_Jestar · 4 Oct 2012 at 11:16

Doesn't want complexity.. so uses a grotesquely overcomplicated framework instead of a simple one. :/ (WebForms instead of MVC)

Anyway.. regarding your final bit (re: "bad design") - what's stopping you putting a clause in to stop it sending the "postback" (whatever that is in this context) until the "message" (again, context) has been received?

Use the Async methods and events available on many things, including WCF, and this wouldn't be a problem at all.

lokkers · 6 Oct 2012 at 10:03

Would something like SignalR work for you?

That would turn the problem on it's head - your client isn't polling for data that may or may not be there - the server is sending the information only when there is something to send?

durbs · 6 Oct 2012 at 23:57

Do it the other way round, expose a service at your end that the remote server calls when an update is required then perform a server push rather than timed polling. Search on reverse Ajax.

http://www.frozenmountain.com/websync/

http://pokein.com/

sunama · 7 Oct 2012 at 15:01

Hi Guys,

I have looked into all the suggestions in this thread. Much appreciated.

Over the last 3 nights, have been looking into recreating the webclient completely in JavaScript. I am currently having a few problems with node.js, which is what I am attempting to use.

I think if I were to recreate the client with javascript, then the problem would completely be solved (from the ground up) and would be the right way of going about things. The advantage would be running this web page on a Linux server which would be super fast compared to a Windows server (super slow).

The problem is the man-hours involved in doing this. I have a created a very complicated client which morphs and changes shape depending on the usage of the client. I want to keep this system, as this gives me a 1 webclient fits all, type system.

The main server dictates the shape of the client, in the browser window.

My options are:
1. I can alter my current web client (which is in ASP.NET and is very heavy), to make fewer postbacks. This still leaves quite a lot of data passing to and from the server. Not good, but better than my current situation. This is almost like putting gaffa tape, over something that is broken. This method will be quick to implement (probably 2 weeks).

2. I can re-write the entire client in javascript and in the process, I will need to master javascript (I dislike web programing with a passion). Lots of learning involved. This could take about 2-6 months, including testing/research/learning. This is a no-go.

3. I can outsource the webclient to a contractor to build, however, I would need to pay someone to do this (I would suspect around £1k). Also, once he builds it, it will be difficult for me to update it - updating someone elses code is not "natural".

I think I am going to choose option1.

I spent 1 long evening introducing a system which reduces the number of postbacks...so at some points, postbacks will happen every 5 seconds (which is better...but not great). However, I think given 2 more weeks I can reduce the number of postbacks further.

Once again, thanks for your help gents.