Client callbacks over the internet

Nitz posted on Thursday, July 30, 2009

Hi,

In my application, i am using Win Forms and CSLA 3.0. The client machines connect to the app server using WCF over https. Now, i have a requirement for implementing the maintenance window activity. At any point of time, the administrator of the application needs to send a message stating "Please save your work. The system will log you out after 15 minutes." to all of the clients connected in the application. After which all of the clients connected at that point of time will be logged off the system.

The cleint machines may not be in the physical network while connecting to the server as some of the users will be accessing the application from home over the internet. Please suggest the best way of implementing it.

RockfordLhotka replied on Thursday, July 30, 2009

First, the data portal won't help you here, because this sort of scenario is entirely outside its scope. This means you'll need to create your own messaging model outside the context of the data portal.

Second, doing actual callbacks turns out to be very hard - nearly impossible. There are numerous technical reasons for this, and solving them requires very low-level programming to deal with the various NAT/router/firewall products in use today.

Third, fortunately there are a couple realistic options provided by Microsoft.

One is to use the dual http channel provided with WCF, which is a bi-directional channel that is client-initiated (and so avoids the networking complexities I mentioned above). I'd look at this first.

Another is the Windows Azure platform, which might be cost-prohibitive, but includes a message bus technology that does work through nearly any NAT/router/firewall.

Yet another is to write your own http polling component. The Silverlight WCF dual http channel uses a very efficient http polling model, and you could construct yours by using theirs as a conceptual model. I suspect, however, that you are better off using the existing dual http channel with WCF.

ajj3085 replied on Thursday, July 30, 2009

RockfordLhotka:
Yet another is to write your own http polling component. The Silverlight WCF dual http channel uses a very efficient http polling model, and you could construct yours by using theirs as a conceptual model. I suspect, however, that you are better off using the existing dual http channel with WCF.

This is actually what I've done, but with standard threads and Csla (although I'm using remoting). Basically when my application starts I spin up a background thread that starts a timer. Every so often, the timer fires and executes a Csla command object to see if the application needs to shutdown. If it does, it will notify the user when the system is going down (so I can provider warning). Subsequent checks will cause the message to display again, tell a user the shutdown time has moved or the shutdown has been canceled... or actually shut down the application.

Also, when initially logging on, theres a check that the application has not been locked out, and if there is, the application closes immediately.

RockfordLhotka replied on Thursday, July 30, 2009

I'm sure that works Andy, but it isn't real efficient.

As it was described to me, what the Silverlight dual http channel does is to
have the client make an http request to the server. The server doesn't
respond immediately - in fact it doesn't respond until it has outbound data
or some time (30 seconds?) has elapsed.

As soon as the client gets a response from the server it processes the
result (if any) and re-issues the request.

This way any outbound data is delivered almost instantly, because there's
virtually always a client request just waiting for the data, but there's
relatively little overhead, because the client only issues a request every
30 seconds or so.

To get similar responsiveness with traditional polling would require the
client to issue a new server request a few times a second.

Rocky

RockfordLhotka replied on Thursday, July 30, 2009

I suspect you could use the same model with remoting.

Most of the work is actually on the server side, where the inbound request
doesn't return immediately, but rather blocks until it either has data or
times out.

This implies that there's an outbound data queue of some sort on the server
btw, so anyone wanting to send data to the client puts the data in that
client's queue (could be in memory, or database or whatever), and the
server-side code checks the queue or is notified when new data gets into the
queue.

I imagine, now that I think about it, that you could do this with a
ReadOnlyBase or CommandBase object, as long as it was invoked on a
background thread from the client (maybe using the async data portal if you
are using 3.6 or higher).

Rocky

Jack replied on Thursday, July 30, 2009

Rocky,

Would this work as a way to refresh client side caches from the server?

I could see all my SL clients doing a 'When were datasets 'abc','def', & 'ghi' changed?' request and then either getting fresh data back to load asynchronously or having a last changed date to make a new client request for the delta changes.

I could then simulate simple push schedules for app data, site specific data, and user specific data.

I've been toying with how best to manage aging data on the client and whether to let the user make a decision to ask for new data based on a 'reload/refresh' datetime + button or to put a timer in. I have clients on both the east/west coast sharing a westcoast server so a couple of my eastern clients have much poorer bandwidth and so some generic policies don't make sense or are overkill at certain sites.

Any chances on a SL demo/sample?

Jack

RockfordLhotka replied on Thursday, July 30, 2009

I’d love to see whatever sample you come up with :)

Seriously – I’ve been talking about the basic capability of a WCF feature, not a specific implementation.

I don’t think the dual http channel would work with the data portal. The data portal is designed around a connectionless model. But maybe I’m wrong and it would work – but it isn’t something I’ve tried.

But doing this yourself (with the normal wsHttpBinding or basicHttpBinding) should be possible. Certainly you could write a ROB object that blocked on the server for 30 seconds – that’s easy. The hard part is interrupting that 30 second wait when outbound data arrives – that’d require some server infrastructure around an outbound message queue on a per-client basis.

That’d be fun to write, and I’d be tempted if I wasn’t in the middle of implementing some MVVM support (though the deeper I get into MVVM the more I’m convinced it isn’t the right direction).

Jack replied on Thursday, July 30, 2009

You'll love me latest reply then :-).

I'm sure you could do it with a looping set of commands and a progressId as part of the command. Kick of the command, then kick off a loop of GetProgressCommands that query a static dictionary on the server for updates. Same idea.

On the MVVM front I'd love to hear your running commentary (especially after our last email thread).

From: Rockford Lhotka [mailto:cslanet@lhotka.net]
Sent: July-30-09 3:55 PM
To: jaddington@alexandergracie.com
Subject: RE: [CSLA .NET] RE: Client callbacks over the internet

I’d love to see whatever sample you come up with :)

Seriously – I’ve been talking about the basic capability of a WCF feature, not a specific implementation.