I am using wsdualhttpbinding to connect the client and WCF Service. My client likes to invoke a long running request and wanted a periodic status update, hence I have choosen callbackcontracts. that worked fine. However It publishes for all clients who have just been loaded and has not requested that operation.
Is it possible to direct the callbacks to the requestor alone, though all clients are loaded.
I received an answer from this forum. Sharing this.
http://social.msdn.microsoft.com/Forums/en/wcf/thread/c0fce1de-9793-48fa-8e4d-329297ac54d3
Related
In a scale-out scenario where one server consists of master+worker endpoints and another server consists of workers, is it safe to call bus.Publish from an endpoint when it finishes handling a given event? (Keeping in mind bus.Publish could be invoked from an endpoint sitting on the worker server).
My initial reaction is that it's not safe since it sounds like the example where you should never call publish from a web server...
We could certainly use the WCF wrapper and call out to a service that exists only on the master+worker endpoint server, but does anyone have any practical experience with this?
Thanks!
Each logical subscriber has a receiving endpoint. If you're using the distributor, this is the distributor endpoint, or distributor queue, if you will. So the subscriber will subscribe to specific events and specify it's receiving endpoint. The publisher will have no idea if it's a single endpoint instance, or if it's a distributor receiving the message.
The distributor will then send the message to a worker that is ready to process the message.
This is explained in more detail and with some clarifying images on this page: http://docs.particular.net/nservicebus/scalability-and-ha/distributor/publish-subscribe
In the end, we made our web apps "send-only endpoints" which essentially means they simply send commands directly to an endpoint via a chosen transport (in our case MSMQ). Once we need to scale, we will eventually implement "Sender Side Distribution" rather than utilizing the distributor.
From the NSB support team: "If you add more endpoints, Sender Side Distribution is the way to go. It acts as a round-robin mechanism running on the sender side which would send messages to a different 'worker' endpoint when you scale out."
https://docs.particular.net/transports/msmq/sender-side-distribution
If you only need to fire-and-forget messages from a website or some other app/service, I'd recommend this approach - it's quite simple.
I've tried a few different ways to do this, but I keep coming up short.
In short, here's what I need to do:
Create a WCF service that acts as a router between client (desktop pc) run diagnostic tools and "widgets" (that also run desktop windows and are have internet connectivety). Since these "widgets" are typically behind some sort of firewall, we've decided to use an IIS hosted WCF service over a tcp connection (port 800, i believe) for callbacks.
Notifications of what the widget is doing need to be sent, asyncronously up through the router to any "connection" clients.
Clients need to be able to syncronously call into the widgets to get diagnostic data or command them to perform a task.
Right now I have a windows service running on the widget that monitors it's status and provided a link to the internal programs to get data.
I also have a light weight diagnostic application running on desktops.
I have created a single callback interface for both status-push and data-pulls that both the widget monitoring program and desktop program implement.
My first attempt was to have the router service keep a list of registered devices and clients and pass messages between them.
Ie: Desktop calls server.getwidgetcolor("widgetid"); and the service calls _widgetlist["widgetId"].getcolor() and returns it.
Similarly the widget monitoring program calls server.notifywidgetcolorchange("widgetid") and the service calls, on all registered client _widgetlist["widgetid"].clients.Notifiycolorchange()
The problem I am running into is that if a wigdet is calling up to the server at the same time the client is calling down to that widget, both calls timeout.
I initially had the server setup as a singleton, and have played with changing the concurancy mode to multiple or re-entrant, but those didn't seem to work.
Conceptually, i'd like to have the service be per-call and persist somehow, that device and client call backs so that when a call comes in, the server wakes up, depersists the call back, sends the message, then goes back to sleep.
With all that said:
Is that ^^ possible (to persist call-back data so that a per-call server can call back on clients)? If not, could I make the service per session (for clients/widgets) but pass the data between service sessions through some other means? Shared memory? File?
Is the over all design possible/recommended? I've looked into the WCF routing library, but that doesn't seem to do what I want, unless I'm reading it wrong?
Are there other technologies I should be using that can do this more easily?
Thanks,
-Bill
I am creating a WCF service where multiple users connect to it. On my WCF I implement callback contracts so that if a user makes a specific action it can notify other computers that are connected to the same WCF service. So if Company A creates an action on the WCF service then the WCF service will make a callback to all Company A machines that are connected to it. Company B will receive no notifications for example.
Anyways so far everything works great NOW. what about in the future where there are more connections at the same time? will that cause a problem?
To avoid that problem will it be better to create a web service where connections are not held open? The problem with this approach is the callback mechanism where the web service needs to send a notification to multiple computers In order to resolve the callback problem I am going to have all machines sending a UDP packet every 10 seconds to the web server. (this will make the router open a port so that the web server can reply in case it needs to) If the web service needs to send a notification to all computers on Company A for instance then it will Send multiple UDP packets. If a computer receives a UDP packet from the web service then it knows it has to make a request to perform the callback. Should I use this approach?
I have a WCF service with a function GetData()
When my client calls this function,it takes a while to return the data after looping through some stuff
Within that period of time,if I pull of the wires on the server,no error is thrown.
How do I get to know if the client gets disconnected?
Thanks.
Edit:I'm using Wshttpbinding
I don't know if this only works for duplex channel but you could subscribe to the client close event of the channel. Look at OperationContext.Current.Channel.Closed.
Blog post listed below has more info
http://www.rcs-solutions.com/blog/2008/09/24/HandlingDisconnectsWithWCF.aspx
What kind of bindings and protocols are you using?
Typically, the server has no knowledge of the client, and will not know about the client disappearing. If you have a duplex binding, then you have a channel from the server going back to the client, and then you can use the technique described in the link Emmanuel posted.
Other than that - I do not know of any way the server could find out that the client has been disconnected before an error happens (e.g. a channel faults, since the client can't pick up the response anymore).
Marc
I'm trying to use WCF to implement a comet style server push to an ajax web application.
In my WCF service, I've implemented a WaitForEvents method that calls Monitor.Wait to suspend the thread until new data arrives. At that point, the Monitor is pulsed, and the method returns the new data which closes the comet style request.
The request is made again when this happens.
Currently, this works fine but I noticed that WCF needs to create a new thread for each connected user. This is probably because the thread cannot be returned to the threadpool until data comes in, and so each connected user requires a new thread.
I want to make this implementation more efficient by having one thread service multiple connections. If I were to use a socket, this could be done by leaving the socket open and returning the thread to the thread pool first. When new data arrives, it will be delivered by another thread and we can write the new data directly to the socket and close it.
Does anybody know how this can be done via WCF?
I have been looking at "Push-Style Streaming" http://msdn.microsoft.com/en-us/library/bb472551.aspx and they mention that "WCF implements a "pull" model in which the application code (the service) returns an instance of Stream and relies on the lower-level infrastructure to pull data from this stream and write it out to the network." but I cant find any examples of this one the website.
Many thanks in advance!
Check out nComet
It's not using WCF, but I believe the author is working on a version that uses WCF. Contact him via codeplex and ask him :-)
"nComet is a .NET implementation of
the Comet (reverse-AJAX push)
architecture. This server-side
pipeline uses long-lived
client-initiated HTTP connections to
push messages to the client. Once the
client receives a response, it
immediately opens another HTTP
request, which the server holds until
a message is ready. This architecture
allows the server to push dynamic
html/xml/json/etc to the browser,
rather than the browser polling the
server.
This project is scoped to the .NET
server-side architecture, initially
providing a HttpListener (for a custom
host communicating with HTTP.SYS
directly) as well as a ASP.NET
implementation, where the ASP.NET
implementation can be hosted inside
IIS as well as an external process.
The library will simplify the
implementation of common message
patterns such as pushing the latest
data, as well as sync. Example code
and links to multiple client-side
javascript implementations will also
be provided."
You may also want to check out WebSync, a .NET comet implementation. Works just dandy with WCF.
(Disclaimer: I work for the company).