Fog Creek Software
Discussion Board




Pushing data to a .NET Windows Forms client?

What is the best way to push data out to a .NET windows client?  I plan to have a zero-touch deployment windows forms client and need to push out messages to that client.  The behavior is similar to a stock quoting application.  Messages are coming from the server much more frequently than from client to server.  Client to server calls are web service calls.  Both client and server are written in .NET. 

I'm looking for a high level solution, I don't want to think about sockets.  Remoting seems to be the likely candidate, but I've heard mixed reviews about .NET Remoting and don't have any personal experience.  It often feels like .NET Remoting has already been deprecated.  This is shrinkwrap, not enterprise ware, so the users may be on the other side of multiple firewalls from the server.

Hockey Player
Tuesday, August 03, 2004

Remoting (or a home grown derivative of that) is about your only choice unless you can manage to use something like Casini to host web services on the client.

Although you may have a hard time getting remoting working through a firewall, it will be the same for the webservices solution.

You may want to look at the code for terrarium (if that is available) and see how that does it.

Chris
Tuesday, August 03, 2004

why push instead of pull?

mb
Tuesday, August 03, 2004

Unless every bit count (CDPD/GPRS packet modems paying bandwidth through the teeth), you might want to go to a pull model. Basically give your Winform apps 2 threads for this purpose. 1 thread is the monitor: it pulls an aspx/ashx from the application server which basically tells you that you should update your client. It should be a zero size file updated/created by a database trigger or a file system monitor. Then, when it's time to download data (when something happens to a database), a trigger will invoke and update the file. If your Winform application detects a last update change to this "signal file" then start initiating proper download jobs. I am sure there's an easier way to do this but it's one way.

Li-fan Chen
Wednesday, August 04, 2004

Thanks for the comments.  I'm reading Ingo Rammer's "Advanced .NET Remoting" and have found some interesting discussions in the the remoting newsgroup. 

As for pull, the stock prices may change every second or every day, so the polling would have to be very frequent to catch the updates, but most poll calls would be wasted.  Besides, I've never liked polling.

Hockey Player
Wednesday, August 04, 2004

Theoretically speaking...
Can your client-side app post it's IP & port to the server and when the server needs to, it can send a request to your client because it knows the IP & the specific port.  Once your client gets this request from the server, you know that an update is available and proceed to pull the data from the server. Naturally, you would want your client side app to notice whenever the IP changes,  also I don't know how well this would work on a NAT and/or behind a firewall.

James Thomas
Wednesday, August 04, 2004

this works very well, plug in HTTP or TCP remoting channel.
http://www.genuinechannels.com

bFlood
Wednesday, August 04, 2004

You mentioned firewalls.  I suspect there might be issues with firewalls etc between your server and your client machines?  For instance, I have Zone Alarm on my PC, and it probably wouldn't take kindly to a client app _receiving_ connections from a server.  (Yes, I could allow it, but will all your users be able to do the same thing on their firewalls?)

While polling might be unattractive, I suspect you might find that its your best option...

It seems to me that, when you do not control the networks and firewalls that will be used, there's really only one thing that you can rely on: client-connects-to-server-via-HTTP (or HTTPs).  Of course what you pass over HTTP might be whatever you like, including web services or remoting.

>As for pull, the stock prices may change every second or every day, so the polling would have to be very frequent to catch the updates, but most poll calls would be wasted. 

When a stock price does change, how quickly must you get it to the client?  Depending on your answer to that, you might be able to do something like this:

(a) Every time something changes (I'm assuming you have more than one stock price), the server increments some kind of "change counter", but does not actually push to the clients.  The change counter is like a version number for the "state of the world".

(b) When the client retrieves data from the server, it doesn't just get data, but is also gets the current value of the change counter.

(b) The client polls every 5 seconds (for example). When the client polls, it sends a message to the server that says "The last change counter you sent me was X.  Gimme everything that's changed since then."

This scheme means the polling is very efficient when there is no new data.  It also means that, if lots of stocks change within a few seconds of each other, your bandwidth is still fairly efficient, because when a client polls it gets everything that's changed since it last polled, all in one "hit". 

John Rusk
Thursday, August 05, 2004

If you go for polling, I'd let the server app push.

What I mean is, have static data pages be puched out to the webserver by the application server whenever the data changes. The clients poll these static pages.

Just me (Sir to you)
Thursday, August 05, 2004

*  Recent Topics

*  Fog Creek Home