Just starting to look into WCF and came across the
WSDualHttpBinding binding.
I have used .Net remoting in the past, but it was not possible to have callbacks to occur when the client was behind a router.
Callbacks only worked when 2 applications were running on a LAN.
As explained by this article.
http://blogs.msdn.com/manishg/archive/2004/10/16/243414.aspx
It mentions
“If your client application is running behind a router (as in the case of most home networking setups), there is no way for the server to dispatch events to the client”
Does WCF find a way of rectifying this, I understand the binding TCP supports callbacks only works on a LAN? Am I right? It would good to have callbacks work across the Internet and was just wondering if this was possible?
Not yet. The new relay bindings in WCF 4.0 rectify this for real, but the dual bindings are just a way to define server to client callbacks in a single contract.
Related
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.
I built a application with 5 wcf services and hosted them in IIS 7.5. I used the default configuration for the net.Tcp port (808*).
I am not used to host WCF services in IIS (I always hosted in Windows Services) and I found interesting that when I call the service (using tcp binding) I got two different process on the server.
One is SMSvcHost.exe (the one that is actually using the 808 port) and the other is w3wp.exe wich I think is handling a instance of the server I am calling.
I have a lot of questions so I will enumerate them:
Should I use IIS instead of Windows Service to host WCF Services (tcp binding) ?
The fact that I have two processes to answer my request means that I may have cpu impacts ?
Sometimes my services stop answering using the tcp binding. I got a timeout error on my clients but the mex is correctly answering if I go to the http://myServer/Service1.svc. I suspect that this problem is caused by fault connections but I am throwing exceptions correctly (using fault exceptions) and catching them correctly on my clients. Besides, I am also implementing a partial class for every service to dispose corretly (either using Close or Abort methods). Is there any way to figure out what's going on when the services stop answering ?
Shouldn't the w3wp.exe processes be closed after the client ends the request ? They remain on the Task Manager even when no one is using the services. I guess this is the reason of why my Entity Library logging locks the file after my request is completed.
Ideally it would be better hosted in Windows Activation Services (WAS) which is close to what you think of as IIS, but not quite. Here's a good introductory article on MSDN magazine:
http://msdn.microsoft.com/en-us/magazine/cc163357.aspx
What is the best way to combine a single instance WCF service that uses ActiveMQ and runs within IIS/AppFabric?
Our Services need to support both HTTP transports and ActiveMQ (listening and sending messages). We've elected not to use MSMQ, and will use Spring.Net.NMS. The fundamental issue I have now is that ActiveMQ needs to connect to the queue(s) at startup and remain connected, but WAS is getting in the way with it's message-activation feature. If the service is not activated until a message arrives (HTTP/MSMQ, etc) then there is no trigger to have the connection to AMQ occur.
I know I can disable the recycling behavior, and I know I can do self-hosting with a Windows Service. But I want to take advantage of the monitoring and other features in AppFabric. I've already been down the route with IServiceBehavior and will use that for other nice things. But that interface is not called until a (non-AMQ) message arrives. So it won't work for this. What I was hoping for was something along the line of how ServletContextListeners work in Java, where you get both the start up and shutdown events. But it seems no such thing exists in WAS... it is driven only by messages arriving.
I've scoured every inch of web info for 3 days and the only thing I came across was to use a static class construction (C#) trick as the trigger. That's a hack, but i can live with it. It still leaves the issue of cleanly shutting down, which I can figure out later.
Anyone have a solid solution to this?
The direct WCF support for ActiveMQ that Ladislav mentions is still being supported. There just hasn't been an official release for the module in a while. However, you can still get the latest version of it from the 1.5.x branch or trunk and compile it yourself.
1.5.x branch for use with Apache.NMS 1.5.0:
https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.WCF/branches/1.5.x/
Check out instructions:
http://activemq.apache.org/nms/source.html
There was direct WCF support for ActiveMQ but I guess it is not developed anymore. Your problem actually is the IIS / WAS (provides hosting for non-http protocols) hosting architecture. Services in WAS are always activated when message arrives - there is no global startup. The reason for this is that WAS hosting expects that there is separate process (windows service) running the listener all the time and this process has adapter which calls WAS and uses message level activation. I guess you don't have such process for ActiveMQ and because of that you will have trouble to use ActiveMQ endpoint hosted in WAS. Developing such listener can be challenging task (example for UDP).
Creating custom listener can be probably avoided by using IIS 7.5 / AppFabric auto start feature. There is also not very well documented way to run the code when the application starts.
After developing mini project with WCF duplex (Chat Service | Sms Service), I got a Point that maybe not be correct!!
I believed Duplex theory is good and useful but there is a lot problem about using Wcf Duplex. (like reliable session, Time-out exceptions, Client address-Management on server side, proxy management on Client Side)
am I think wrong ? am I miss something?
For more Information I Used wsDualHttpBinding not tcpBinding.
If you need bidirectional communication and you want to use WCF, duplex channels are the way to go. You just need to design your application correctly and correctly handle all problems you have described. If you feel that these problems are overhead and make things even worse you can always use network programming directly (sockets) or handle bidirectional communication by yourselves exposing separate service on server and another on client (where first call from client inform server about clients address) - this scenario will suffer from the same communication problems as WsDualHttpBinding.
WsDualHttpBinding itself is special kind of duplex communication. I personally don't like it because people very often misuse it. The problem is that this binding uses two separate connections - one from client to server and second from server to client. That is big difference to net.tcp where only connection initiated from client to server is used. Obviously using WsDualHttpBinding over internet (= you don't have control over client machines) becomes much more complicated because each client must configure its firewall (in computer, on home internet gateway, etc.) to allow connection on some port. Also if you want to run more then one instance of application on the same client machine, each instance must use its own port.
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.