I have a server that needs to keep a small number of clients in sync. Whenever there is a change of state at the server, all the connected clients must be informed.
I am planning to use a “callback
contract”,
I can get hold of the
callback reference for each client on
the server by using
GetCallbackChanel().
I then need
to manage all these client channel
reference and call all of them when
needed.
So far so good however:
I don’t wish to block the server, so calls to the clients must be none blocking
Errors calling the client must be logged and coped with
Is there a standard WCF component to do this?
No, there is not a standard WCF component for this, at least through .NET 3.5. I can't speak to what may be available in .NET 4.0.
That said, there is a pretty straightforward way to do this. Juval Lowy, author of Programming WCF Services, describes how to do this using his WCF-based Publish-Subscribe Framework.
Basically, the idea is to create a separate WCF event service that resides in the same hosting application as your server (e.g., Windows service, IIS). When the state of your server changes, you publish the state change to the event service. The clients that need to be kept in sync subscribe to this same event via the event service. In effect, the event service becomes a broker for your server to notify clients of whatever events your server publishes.
The article I listed above has a code download, but you can also get the Publish-Subscribe Framework and a working example for free from his website, IDesign.net. Here is the link to the download. You may need to scroll your browser up just a little bit to see it as I believe their internal hyperlink is wrong.
Related
On WCF callbacks, one doubt is still nagging in my mind, The callback happens only when the client makes a call to the server. Don't we have a mechanism that the client registers with the service, and after a while something happens at the server and the service notifies all the connected clients. In COM we do this by generating a COM exe server and keeping a list of all connected clients and trigger an event whenever the COM exe server deems necessary and that will end up as a callback at the client end.
Are you really looking for a messaging implementation like MSMQ?
Using MSMQ, you can setup your client to be a subscriber to your server's "messages". The server in turn is your publisher and it will produce the effect you seem to desire.
http://msdn.microsoft.com/en-us/library/ms711472(v=vs.85).aspx
You want to look at Duplex WCF bindings...
http://msdn.microsoft.com/en-us/library/ms731064(v=vs.110).aspx
http://msdn.microsoft.com/en-us/library/ms752254.aspx
Another framework you may want to evaluate is NServiceBus ...
http://docs.particular.net/NServiceBus/how-pub-sub-works
I am sure that this is answered dozens of times, but I am at a loss as to what keywords to search for and thus I hope that someone can at least tell me where I should be looking given an explanation of my scenario.
I need two services (one can be just a client if that is easier) to talk to each other, but the client will be on a private network whereas the server will be on the internet. I want to be able to push jobs to the client, but the server obviously does not have an IP to hit the client. I'd rather not poll from the client every X seconds. I have read various topics all circling this issue and so I am going to throw out a few terms that I think are relevant, but I am not sure which to use or exactly how.
Comet, SignalR, WebSockets, XSockets, Publisher/Subscriber Pattern...
I have looked at each of these and I am not sure which is the right way to go. The client can certainly "subscribe" to the server on startup, so that should not be an issue. But the client should be either a console app, windows service, or WCF service. It seems Comet and SignalR are more for ASP.NET apps, where the client is JS in a browser. I just need "server(client)" to server connection where the client is behind firewalls.
Which of these terms (or none of them) is a good way to handle server -> client push notifications?
Pub/Sub architecture pattern with something like Azure Service Bus should help you create the solution you desire. This does require that service and the client are aware of the bus. For the plumbing of the client and the services use the WCF which has built in bindings to facilitate the use of this pattern.
Azure: How to Use Service Bus Topics/Subscriptions.
Azure SB has a counter part that works on-premises as well. There are other popular message bus tech (NServiceBus, MasTransit, etc.)
You can have a look at node.js together with socket.io.
This will give everything you need.
socket.io uses web sockets, and if the browser does not support web sockets, it gracefully falls back to other communication mechanism like xhr, flash, polling, aso.
This is my scenario:
Web application with a self-hosted bus (publisher)
Windows service with NServiceBus.Host.exe (subscriber)
Imagine that trigger an IISRESET (never mind on the why I have to do that) that makes the bus re-initialize and lose the subscriptions that already had. I'm using MsmqSubscriptionStorage and the publisher (web app) implements the IAuthorizeSubscriptions interface.
How can I renew the subscriptions and also call the AuthorizeSubscribe()? Is that possible? What's your suggestion to this scenario?
If NServiceBus is properly using MsmqSubscriptionStorage, then after iisreset, the bus should initialize and load the existing subscriptions from the configured storage queue. This queue name can either be set by configuration or, if omitted, should default to a name based on an assembly plus "_storage". However, having never used this from a web application, I don't know what that would be in that scenario, since there is no class that implements IConfigureThisEndpoint.
That said, trying to publish an event from a web application is a very icky business, and it's generally advised that you avoid just that.
Just a technology update, now that .NET 4.0 is out.
I write an application that communicates to the server through what is basically a message bus (instead of method calls). This is based on the internal architecture of the application (which is multi threaded, passing the messages around).
There are a limited number of messages to go from the client to the server, quite a lot more from the server to the client. Most of those can be handled via a separate specialized mechanism, but at the end we talk of possibly 10-100 small messages per second going from the server to the client.
The client is supposed to operate under "internet conditions". THis means possibly home end users behind standard NAT devices (i.e. typical DSL routers) - a firewalled secure and thus "open" network can not be assumed.
I want to have as little latency and as little overhad for the communication as possible.
What is the technologally best way to handle the message bus callback? I Have no problem regularly calling to the server for message delivery if something needs to be sent...
...but what are my options to handle the messagtes from the server to the client?
WsDualHttp does work how? Especially under a NAT scenario?
Just as a note: polling is most likely out - the main problem here is that I would have a significant overhead OR a significant delay, both aren ot really wanted. Technically I would love some sort of streaming appraoch, where the server can write messags to a stream while he generates them and they get sent to the client as they come. Not esure this is doable with WCF, though (if not, I may acutally decide to handle the whole message part outside of WCF and just do control / login / setup / destruction via WCF).
For bidirectional communications, your best bet is NetTcpBinding, rather than the http bindings, if they're available.
This has the advantage of only requiring that the client can initiate a connection with the server.
I would go with Windows Azure Service Bus. See my answer in the following question:
WCF, 4.0, Bidirectional
Take a look at Windows AppFabric, good place to start is Here. It fundamentally wraps up WCF and WF into an application server, with WCF activation supported through WAS. Its where I would host this type of app. It offerd full duplex connection orientated, p2p or sessions between client and server. Don't confuse the Windows appfabric with Azure appfabric, (formely called Azure Service Bus).
As regards bindings above, both NetTcpBinding and WsDualHttp offer callbacks, but the ws binding you get a lot for your cash, especially if it's a mixed programming environment and you have to flatten the wsdl to make interop work. I also think that WsDual is easier on routers traversal, although I understand talking to friends, that Windows AppFabric mitigates this, with new Relay Services, (which i've not seen, and I think have now been renamed).
Hope that helps.
Does .NET 3.5 (WCF, or other) offer any type of push notification service?
I have a server and a client. I want a service to run on the server and if x happens then push a notification to the client. I don't want to pull the server every x minutes to gather the information.
Your question couldn't be any more general, but I'm going to take a guess and suggest you look at WCF callbacks.
I doubt your question relates to WPF or even WF, but you will need to elaborate if you think otherwise.
You don't need to use any call backs.
You can use MSMQ with WCF.
You can use the attached example I have made.
If you sent it to be a public push server - i.e available via WebService - you will have to add a webservice that will use the MSMQ.
The problem is that you will need to have an IIS installed on both the server and the client.
If you use it internally then MSMQ will be enough.
http://www.codeproject.com/KB/WCF/WcfMsmqServerPush.aspx