tags:

views:

355

answers:

3

Am wondering if anybody has tried this a technique to get events to the client from the server side. I have an environment that uses Unix based servers and so can't use WCF duplex / callbacks etc.

The idea being that my clients are windows boxes running a thick .net app would spin up a WCF self host and register their self host URL on the server for that session. They would have a very simple contract and the server would when it has an update call out the client server telling it that an Update is waiting on the server for it and the client would then get it etc.

I still trying to get my head round WCF so not sure if this is a good way to go, are there any security implications I should worry about ? are there ways to get the Duplex calls to work across platform.

I have done something similar before using sockets or maybe a cross platform message queue would be a better way to go on this anyhow.

Thanks

76mel

+1  A: 

At the very least, that sounds like it ought to work, though I'd guess you could host in IIS as well since the *nix servers could then just make a web call, right? I'm not sure what self-hosting would gain you, though it should work fine, but might be a bit more of a pain in the neck to configure, etc.

Please update here whenever you've made a decision because it sounds like an interesting challenge and some of us would like to see how you make out.

Terry Donaghe
Yes I have thought about putting in a IIS mid tier its a great idea. My thought though is that we have 10,000 clients and 1/3 of that concurrent and so supporing that would cost a bit in IIS boxes.I am going to work up a proof of concept and will keep you posted, but I would be grateful if anybody has more thought, insights and concerns regarding if this a good thing to do as spinning up TCP listeners is common practice why not WCF services.
76mel
Ok I have tried this an got it all working. I think this would work very well for projects that are inside of the firewall. If you want to span the firewall i think using a bus / queue is a better way as you connect at a lower level. What I did here was to have a simple event contract that the Unix server knew about. I ran the WCF service inside a Windows Service that first registers itself with the server with its endpoint. the server then can fire events at my endpoint and I can respond on these by pulling data from the server.
76mel
Excellent! That sounds like it'd make a cool blog article.
Terry Donaghe
+1  A: 

We use self-hosted WCF for a similar scenario. We also wanted to avoid making our client application dependent on IIS, to prevent both licensing and deployment hassles.

It works fairly well for us, though WCF might be overkill for what you need. Since you're using HTTP, you could create a simple web service built directly on Http.sys.

dthrasher
Would the simple web service on http.sys be simpler to write and maintain than using WCF? I doubt it.
John Saunders
I haven't tried implementing a web service on http.sys myself, so I can't say for sure. But I've been working with WCF a while and found it to be much less flexible than I'd like.
dthrasher
Have you tried cassini web server ?
76mel
Not yet. The original Microsoft Cassini sample is in an "archived" status, but a company called UltiDev has an enhanced version: http://www.ultidev.com/products/Cassini. There's also the C# webserver project on codeplex: http://webserver.codeplex.com/
dthrasher
+1  A: 

Another way of getting similar results could be to have the client poll. This does depend strongly on what requirements are there. If you need a near real time update, this obviously doesn't work as you would have to have way to many polls to do this, but if it's ok to take a minute or more to get updates to the client, polling might just be the answer.

Jonathan van de Veen