I have a multi-gui one-service architecture (i implement both, service and client) (using .net 3.5, c#, windows application/service).
whats the best practice to update the guis? i know duplex communication, but if the client doesn't send any requests for some time, the channel is closed! increasing the timeout is not the best solution...?!
Regards
Marcus
The GUIs are sending commands to the service per TCP Duplex. Each time, one GUI is changing some things, the other guis have to be informed about the changes, happend to the service.
first solution: the guis can poll each x seconds the service to ask: are there updates?
but i don't really like this solution. each time a change happend, the service send an "gui you have to update" via callback to each gui. but mayby all the channels are not open anymore...
hope this helps to understand (sorry for my very bad english)
If you want architecture where client registers to the service and service pushes data changes to clients immediately when changes happen than duplex binding is the solution. Otherwise don't use duplex binding.
If you don't like the idea of increasing connection timeout you can always implement your own keep alive mechanism. Client will continue sending some keep alive messages to the service in predefined interval so connection will be still opened.
Related
I have a lot of client programs and one service.
This Client programs communicate with the server with http channel with WCF.
The clients have dynamic IP.
They are online 24h/day.
I need the following:
The server should notify all the clients in 3 min interval. If the client is new (started in the moment), is should notify it immediately.
But because the clients have dynamic IP and they are working 24h/day and sometimes the connection is unstable, is it good idea to use wcf duplex?
What happens when the connection goes down? Will it automatically recover?
Is is good idea to use remote MSMQ for this type of notification ?
Regards,
WCF duplex is very resource hungry and per rule of thumb you should not use more than 10. There is a lot of overhead involved with duplex channels. Also there is not auto-recover.
If you know the interval of 3 minutes and you want the client to get information when it starts why not let the client poll the information from the server?
When the connection goes down the callback will throw an exception and the channel will close.
I am not sure MSMQ will work for you unless each client will create an MSMQ queue for you and you push messages to each one of them. Again with an unreliable connection it will not help. I don't think you can "push" the data if you loose the connection to a client, client goes off-line or changes an IP without notifying your system.
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.
I need to create a service which can process queued requests on a configured time interval. For example go to the web and get financial data from a site the requires we limit requests to once per second. I am new to WCF and I am not sure if (1) WCF with MSMQ a proper choice for implementing this? and (2) if so what is the best mechanism for enforcing the interval? a thread wait? a timer (not sure how that would work).
There's nothing built into WCF that would allow you to handle this explicitly, so you'd still need to do all the work yourself.
While your service could certainly process requests from MSMQ, the MSMQ listeners in WCF will pick and process messages as soon as possible; you can't configure them to process messages every X seconds only (you could fake it given the right tools, but seems to me it wouldn't be all that great).
One option if your delay between processing requests isn't very short, would be to use an intermediate queue to hold pending requests. That is, whatever sends the real requests writes them to a queue nobody is directly listening to (queue A), while your WCF service listens on a differet queue (queue B). Then, have something else (could be as simple as a script run from task scheduler) that runs once every X seconds/minutes/whatever and moves just 1 message from queue A to queue B, thus triggering the actual WCF service to run.
WCF and MSMQ are a great team! Definitely worth checking out.
The part that WCF doesn't provide out of the box is the "check every x seconds". The best approach here would be to host your WCF service inside a Windows NT Service, and have a timer inside the NT Service that goes to check the MSMQ queue only once every x seconds. Shouldn't be too hard to implement, really. The beauty is: you can very easily self-host a WCF Service inside a NT Service - just a few lines of code, and you get complete control over what's happening, and when. See the MSDN docs on How to Host a WCF service in a managed application for details.
Resources:
Tom Hollander's blog post series on MSMQ, WCF, IIS: Getting them to play nice
Motley Queue: MSMQ and WCF Getting Started
SOAizing MSMQ with WCF (and why it's worth it)
Or you could just use a window service to consume the messages instead. If you are not using the WCF functionality of consuming a message as soon as it is posted, then you probably have no reason to use wcf in the first place
I need to know if Windows Communication Foundations (WCF) can completely and easly help to solve the next scenario:
I need a server program which
constantly receives events that,
according to the content of the
signal, helps to trigger one or many
processes; this server program will
run as a Windows Service.
These events will be generated as
signals from many client WPF
programs and so, can be enqueued.
These events will be generated
according to the results of a timer
also.
The communication between the client
and the server will be using an
exclusive port.
For security reasons the data
communication using the exclusive
port will need to be encrypted.
Finally, The clients will need to
monitor the results of the programa
execution.
If the answer is yes, please try to indicate me which libraries/classes should I consider for points:
1) The event management
2) The enqueue process
4) The setting, opening, use and closing of the port
5) The encryption process
6) Monitoring of the server program execution from the client.
Many, many thanks.
Rather than writing a Windows Service program from scratch, which will need to handle multithreaded queueing of incoming messages, why not make the server a web service? That way, IIS can worry about receiving, queueing, etc. and you can just write the code to process the requests.
From your description, I think a WCF service hosted in a NT Service seems like a great fit.
1) I need a server program which constantly receives events that,
Not a problem at all, the NT service will be up and running at all times, even without anyone being logged on.
2) These events will be generated as signals from many client WPF programs and so, can be enqueued.
Again, no problem for a WCF service - you can create a http, a net.tcp, a MSMQ queue endpoint - all in a single service, really. You get all the flexibility you might need.
4) The communication between the client and the server will be using an exclusive port.
Works just fine - if you self-host the WCF service in a NT service, you can completely control the endpoint addresses.
5) For security reasons the data communication using the exclusive port will need to be encrypted.
All WCF communication is encrypted by default, unless you turn it off.
6) Finally, The clients will need to monitor the results of the programa execution.
Again - not a problem.
For a MSMQ queue, you can create a number of response queues that clients can listen on. For HTTP or NetTCP, you can create a response message (if the processing is very quick) or create a "check for status" operation that allows clients to check for statuses. Or you can mix and match as needed.
All in all, I am convinced WCF will serve you very well indeed !
I like using WCF callbacks when I can because to me it is better than the client having to poll the server and its more real time than polling. The question I have is when I subscribe to a WCF service event is there any kind of heart beat that keeps the connection alive between the client and the server. I starting to think that there is not because when the server goes away the subscription is lost and the client does not throw an exception (could be the exception is be swallowed by the WCF runtime). Same is true for the server, when the client goes away and the server attempts to invoke the callback and exception is throw. Any thoughts?
Thanks
There is a good short description of the Duplex contract (WCF callbacks) in this link. The duplex contract is basically two one-way channels and there is no implied message correlation. You are right, there are no "heartbeat" messages are involved, only the normal wsHTTP handshaking traffic occurs when making a duplex call.
I fired up the HTTP traffic sniffer called Fiddler2 (an unsupported Microsoft tool) to verify the session traffic. Didn't see any under-the-hood HTTP "heartbeat" communication occurring during and after the service calls. I left the client running for a good while. Good question, it got me digging a bit.
I went ahead and created a recurring heartbeat to the subscribed clients (basically a call to a function they're hosting).
I've run this for hours and it works, this helps ensure the connection.