I'm working on a project including WCF server and remoting clients.Now the necessary functional part of the software need to push message from server to specified client.
I know that Socket can achieve this, but I want to use WCF Only. So I find document on WCF duplex service.Here is my idea:
I start a new thread which communicate with duplex service only once
and then wait for the callback from the server.(Keep the thread
alive and let the proxy opened for waiting the callback )
At the server side,I save all the clients' callbackInstance in a List,and once I want to invoke callback on the specified client,I will take the callbackInstance out from the List and invoke the callback method.
Question
Is my idea feasible?
If question one is yes,how to detect whether the client is still alive(Prevent from invoking the callback on a client-proxy which is closed. )
Is this something we can replace Socket in WCF Service?
Thanks a lot.
Everything is feasible ... It's all a question of what you know, what's involved, and how much time/money you have.
I haven't worked much with duplex WCF because I had to use one way in webservices, but another approach is using a framework like XSockets . It's version 4 is in beta ATM, but the developers are quite approachable and active, so if you have any issues, they'll be happy to work.
It'll give you real time communication in both direction with one to one or one to many, and might fit your use case ...
Related
I am new to Zero Mq.
I am trying to implement an asynchronous request/reply pattern.
I have 1 server and N clients.
When a server receives a request from a client it passes this request to exactly one worker and waits until the worker has finished processing the request.
The worker shall then send the reply back to the frontend socket which will then send it to the client.
The problem is that the socket.Send/SendMessage method does need a byte[] which does require to serialize my reply in the worker and then derserialize it back on the frontend.
Is there another way, where I do not need to serialize/deserialize?
I would like to use the reference to the object itself, is this possible?
Thank you for your support.
You can't do that. More, you don't want to do that, if you are using ZeroMQ you are working at a much lower level and are probably looking for speed and more control over your communications.
If you really want this I think you are looking for the concept of Remoting. Note that even here, you don't actually use the server reference, its just an illusion to make you feel like its the same but it involves significant overhead which is not in line with you wanting to use ZeroMQ.
NET-Remoting-with-an-easy-example
.Net Remoting versus WCF
I have a WCF service that will be hosted on a server and a WinForms desktop application.
I would like to implement two-way communication between them and was just after some advice on which is the best way to go about this?
I've done some looking about and the two methods I'm seeing mentioned a lot are either implementing a callback contractor using web sockets.
I'm just after some advice and guidance on which of these methods to take or if there is a better method.
I've used Callback Contract for school project and it served it's purpose nicely. If implemented well, it transfers any kind of data between the server and client. Callback is defined the same way as Contract. It's pretty simple and I advise you to look for some examples on Code Project , like this one Callback example , it's explained with minimum code. Also, in most books, Callback is used as an example for response from server. :)
You tag this question as winforms, so, probably, web sockets less relevant for it.
You can use callbacks (look for Duplex for mode details).
But if you have complex functionality on both sides, and firewalls on clients are not the issue - you can create 2 wcf "services" - one will run on client machine, another one - on server.
This will allow you to be even more flexible (for issue like server restarted, client restarted, ...)
WCF duplex performs a callback after a method has run on the server that then runs code on the client.
If i want to execute a method on the client from the server at the push of a button on the server then i don't think WCF duplex is appropriate.
Why would i not just create a client and a server at each end of my 2 applications?
I was one of the people that commented on your previous question so I probably owe you an answer here :o)
You have posted rather a lot of code and I have not looked at it in detail. However, in general terms, there is a reason for using wsDualHttpBinding and duplex contracts in general instead of more of a peer-to-peer approach where you have services on both sides, as follows:
The duplex approach is appropriate where you have a clearly defined server that is running permanently. This provides the hub of the interaction. The idea is that clients are in some way more transient than the server. The clients can start up and shut down or move location and the server does not need to be aware of them in advance. When the client starts up, it is pre-configured to know where the server is, so it can "register" itself with the server.
In contrast, the server does not need to be preconfigured to know where the clients are. It starts up and can run independently of any clients. It just accepts "registrations" from all clients that have valid credentials whenever they come online, and can continue to run after the client goes offline. Also, if the client moves, it just re-registers itself with the server at its new location.
So the server is in some sense a more "important" part of the system. No client can participate in the communication without the server, but the server can operate independently of any client.
To do this with WCF duplex service, you have to do some extra work yourself to implement the publish/subscribe behaviour. Fortunately, the MSFT Patterns and Practises team have provided some guidance on how to do it
http://msdn.microsoft.com/en-us/library/ms752254.aspx
This is fundamentally different from a genuine peer-to-peer approach where there is no well-defined hub (i.e. server) for the network and each node can come and go without affecting the overall functioning of the network.
WCF Duplex is used when you have a Publish/Subscribe setting (also known as the Observer Pattern). Let's say you have a service that subscribes for notifications of some sort (e.g. new email). Normally, you would need to check periodically for updates. Using WCF Duplex, the subscriber can be notified automatically by the publisher when there are updates.
Tooday I use ServiceHost for self hosting WCF cervices.
I want to host near to my WCF services my own TCP programm for direct sockets operations (like lien to some sort of broadcasting TCP stream)
I need control over URL namespaces (so I would be able to let my clients to send TCP streams directly into my service using some nice URLs like example.com:port/myserver/stream?id=1 or example.com:port/myserver/stream?id=anything and so that I will not be bothered with Idea of 1 client for 1 socket at one time moment, I realy want to keep my WCF services on the same port as my own server or what it is so to be able to call www.example.com:port/myWCF/stream?id=222... and I want it to work on Any port - not only 80)
Can any body please help me with this?
I am using just WCF now. And I do not enjoy how it works. That is one of many resons why I want to start migration to clear TCP=)
I can not use net-tcp binding or any sort of other cool WS-* binding (tooday I use the simpliest one so that my clients like Flash, AJAX, etc connect to me with ease).
I needed Fast and easy in implemrnting connection protocol like one I created fore use with Sockets for real time hi ammount of data transfering.
So.. Any Ideas? Please - I need help.
Well if you're going to drop down to pure sockets, you could as well make your service act as proxy. Make WCF Services listen on some other port, and your app on the desired port. When you receive request in your app, manually parse header and check weather it is intended for your service or WCF Service. If it's intended for WCF service, open a TCP connection to WCF service and pass the received data to it, and then simply pass back WCF's answer to the client..
On the other hand you could speed up WCF quite a lot by writing your own custom binding. Lots of time WCF looses on serialization that is done using reflection (which is slow), going around this would improve your speed considerably.
If your problem with WCF is performance then you should try the binary net TCP binding to eliminate XML serialization to improve performance.
Some high traffic applications, like realtime games, use UDP for the majority of communication since it cuts through the protocol. With TCP you get ordering and reliability built in, but this comes at the cost of performance because it will implicitly delay packets to wait for out of order packets so that it can hand them to the application in the correct order, or wait for lost packets to be resent. Instead you can use UDP and implement your own scheme for verification of data that is less stringent than TCP.
There are UDP options available for WCF, or you could implement your own. WCF is nothing more than a message pump, and you can replace different steps with whatever you want.
Not sure if this will help you or not, but try turning on your Net TCP Sharing Service.
Some time ago i Wrote a service with a timer that make an action every n minutes. All was right. But now, I want to write a service that waits for a signal, message or something from a gui application for doing his job.
I want me process to sleep pacefull (not in a infinite loop sniffing something) until my winforms application tell him "Hey, do things and give me a ring when the work is done"
could someone give me staring point?
Thanks.
You can use Windows Communication Foundation to allow your client to communicate with your service, send it requests, and register to receive progress events from existing running jobs.
You need to use interprocess communication (IPC). For C#, this usually means either .NET remoting -- on older versions of .NET -- or Windows Communication Foundation (WCF) -- on newer versions of .NET.
Essentially, the client application connects to an interface implemented by the service, and can then call methods on it, as if it was in the same process.
If this is too complicated, you could use a named event object, which the service waits on, and the client sets.
Starting point:
Self-hosting WCF service
Any of the IPC mechanisms qualify to get this done. If your needs a simple, just message passing, consider either a named pipe (NamedPipeServerStream) or a socket. If they are elaborate, consider Remoting over an IPC channel or WCF.
Personally, I like named pipes for this. Just make sure the pipe name is prefixed by "Global\" so it is visible from the interactive desktop session. Encrypt the messages if security is a concern. Spin up a background thread in your service that makes a blocking call on the pipe stream to implement the message handling.
If the windows service is on the same machine, you could stop and start the service? or call a webservice that stops/starts a service on a another machine?
If you did have a service that polls (or "sniffs") for something to do , this could be a very small and basic call to a database to check for something that will trigger the actual work?