I have a windows application which hosts two services as netTCPBinding and also has some client dialogs.
one of the services is duplex. When i run two different instances of my software (one as server and one as client) there will be no problem.
However, when i run only one instance as server and client (in tandem), the duplex service does not work. The problem happens on Subscribe() method call. after timeout exception, Subscribe() method of host will be invoked.
Do you have any idea how to solve this?
There's not enough information in your question to provide a detailed answer, and I'm not sure but I'll give it a try anyway.
I bet your problem lies in the reentrancy behavior: Just mark your service implementation with the following:
[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant)]
This will allow incoming calls from the same endpoint while you're processing a request.
The problem was not because of the WCF. It was because of the StreamInsight. If you are using WCF based sinks in embedded StreamInsight scenarios note that the sink will not be generated until an event comes into your query. In my case, it was not possible to connect to sink at first before sending data to source.
Related
I'm new at WCF and I've got one problem, and I don't have an idea how to solve it.
I've got Windows Service app listening to COM ports, and GUI WPF app for configuring Windows Service app. Among that my idea is to send notification to WPF app every time when something comes to COM port and maybe send that data to WPF.
For communicaton between those two clients I use WCF, and for sending data from WCF service to WPF app I got to use callbacks.
I got to use two different ServiceContracts because of two different clients. One of ServiceContacts supports callback method, and one of them not so there are two different bindings.
Is there any way to invoke callback method implemented on WPF app when WS gets data from COM port. On WS I invoke proxy method defined in ServiceContract for WS, and get data in WCF service but when I invoke callback its always null. I know that there is problem with OperationContext and I know what problem is but I dont know how to solve it, or is there any way to solve it.
Please help me and thank you.
I think duplex WCF (i.e. contract with Callback) is one way to go if your WFP client is normally calling the "service" via WCF anyway. You will obtain the callback context in the "service" contract class (its constructor usually) and then use it to forward anything to the WPF client at any time. Google "Duplex WCF".
However this is a situation for which in enterprise scale you will use a middleware solution, i.e. a separate "message queue/bus" infrastructure to which the WPF clients subscribe and get their updates. If no one is subscribed, messages are sent to /dev/null. The "service" publishes everything to the bus at any case.
We have a WCF ServiceHost, wich has a few different Endpoints. One of the Endpoints uses MSMQ. Now we have the Problem, that the Server uses multiple Threads to read from this Endpoint! Is it possible to tell WCF to allow only one Thread using this Endpoint? So that I read one Message after another?
You can set the ConcurrencyMode on the WCF service, take a look here at this link, it should help with your issue.
This link might also be helpful Should WCF service typically be singleton or not?
This might look a question where you can read the answer on MSDN, but I still want to ask about the scenario, as I want to solve the business problem.
I have a service hosted on a server, and a client makes service calls. It currently uses netTCP binding. Everything works fine when the service is available, when the server is up and running. Now, I need to handle the server down scenario. I use the local cache file on the client to serve the client requests in case of server down scenario. Now I want to cache all the requests made while server down and want to make service calls once server is up and running.
I am thinking about using the netMsmqBinding, because all I've read suggests that it works well in the disconnected scenario.
Q.1 Can I use the netMsmq to handle this scenario?
Q.2 If not then what could be another approach with which I can follow to solve this problem?
Q.3 Can I use WS-Discovery in case of server down to find that the client calls won't be able to contact the service?
EDIT : The scenario is Client-Server. But i do need to give response on every call to the client. The client is also developed and maintained by me only so i am in a good position to implement the best suitable solution.
Please guide me as I'm not too good with WCF.
Yes, you can use netMsmqBinding for this purpose. We are doing that for services running over a satellite link that can be down often.
One important limitation you need to take into account is that all calls must be one way, being a queue-based transport. If you need to get the results of a request, you'll have to provide a separate response mechanism (it can be a similar queue in the opposite direction)
Ad question 1: using MSMQ is excellent for a scenario where the service may not always be up and running. Note that the server that hosts the message queue must be up and reachable to receive the messages. However, you haven't told us anything else about your scenario, particularly why you currently have NetTCP. The reason that's important, is because there are some things you can not do with MSMQ, for example duplex communication won't work out of the box.
Ad question 2: an alternative may be to implement logic in the client (it's unclear from the question if you're the owner of the client software) to have a local queue and retry messages later if a service is (temporarily) offline. I guess you may even have a proxy MSMQ service on the client, relaying the messages to the main service once it's up.
Ad question 3: yes, you can use Discovery for this. The service will have to announce to the clients when it goes online or offline. The simplest example is using the UdpAnnouncementEndpoint. In the clients you can use the AnnouncementService class to listen to the service coming online or offline, and keep a local list of available services. Alternatively (for example when UDP broadcasts aren't feasible) you can create a discovery proxy service at a well known location that listens to announcements, which the clients can access for instant-knowledge on whether the service they need is online
I'm trying to build a http listener (webservice) with wcf. This listener is part of a bigger desktop application. This desktop application also invokes the http listener.
When the listener receives data it should be passed to the desktop application. I tried to build an httpbinding service and use the callback mechanism
[OperationContract(IsOneWay = true)]
void OnDataReceived(Data data);
The problem is that I need wsDualhttpbinding because of the callback.
Do I really need to use the dualhttp to send data from one .NET app to another or am I missing something?
Thanks
Yes you need dual or duplex communication. HTTP by its very nature is a single direction protocol. The client has to invoke the server. The server has no way to talk to the client with out that.
Your problem is you have an event source which is exposed as a WCF service. The only way to for the service to send events to it's clients in real time is via a full duplex connection which means using either duathttp or dualtcp bindings.
However, using duplex bindings is complex at best. It would be simpler to allow the client to subscribe to the service and to then receive messages when events happen which the client is interested in.
This is much simpler than duplex bindings because there's no actual connection between client and service, only asynchronous messages.
While WCF provides bindings for msmq transport, it does not provide a binding with this kind of pub-sub support, so you can either code for this or you can use an open source messaging bus like NServiceBus.
If you are using a callback mechanism, as opposed to a polling mechanism, then yes, you need Dual binding as the WCF services needs to be able to both Send and Receive messages (as opposed to Receive and return responses)
I’m writing a prototype WCF enabled distributed app, to try and find out any issues I’ll have upgrading my existing “sending xml over tcp to communicate” apps I’ve got. I’m using Callback Contracts to register clients with a server (Singleton in ServiceHost) and so far all the communications between client and server work. I can connect multiple clients to the server and send a broadcast from the server that is received by all clients. I can block a particular client and the other clients still receive the calls. This is good.
To continue my learning and evaluation of performance I would like the client to record what time the server sends each message, as well as what time the client receives that same message. How should I best go about this?
Is there something similar to SOAP extensions, where I can add to the outgoing from the server and incoming to the client? Or would I need to add a “timeSent” parameter to every method that the server calls on the client and record the time received on the client (yuck!)? Is there a better way to accomplish this?
I am using net.tcp rather than wsDualHttpBinding (which also works but is less performant).
Hmmm... that's a difficult one. The problem here is you can't even make sure both the client and the server timers are in sync.
If what you want to do is send some out-of-band data, so that you don't need to modify your methods, you can use the method suggested here. I think it should be enough.
David is right about the problems with clock synchronization. However, adding the timestamp information outside of the service/client implementation is not hard at all on WCF.
You're right it doesn't support SoapExtensions, though, in fact, it has a much richer set of extensibility point. In your specific case, I think a custom behavior that adds a MessageInspector would probably work.
There are actually two message inspector interfaces: One for the client (IClientMessageInspector), and one for the server (IDispatchMessageInspector).
The easiest way to hook up a dispatch inspector on the service side is through a service behavior (IServiceBehavior), since you can hook that up to your service implementation as a custom attribute. Here's a simple example of how to do it. You can also hook it up through an IEndpointBehavior, but you need to do that either through code when setting up the service host or through configuration, which requires writing a bit more code.
On the client side, you still use an endpoint behavior, but introducing those through code is a lot easier since you have direct access to the ClientRuntime from the proxy client.
Anyway, I would think that something like a timestamp is better added to the message as a custom header so that it is not part directly of the message payload.