I've created a WCF solution where I can kick off several simultaneous long running processes that report progress and have the option to cancel each one individually. I can disconnect the client and the processes keep running and I can start a new client and add an additional process and they all keep running simultaneously. That part works great.
My question is how can I connect a second client to all of the already running callbacks and also have any processes added from the second client show up in the first client (if it's still running)?
WCF publisher/subscriber pattern is exactly what I needed I just didn't know how to ask it.
Related
I'm writing a multiple user server\client application.
Essentially, it will implement a chat room and allow users to communicate with each other. I've gotten the application to work between the server\client so far by sending a request to the server, which is always checking for an incoming network connection, and responding to it immidiately.
However, for the client to receive chat messages from the server, the only thing I can think of is running a server on the client. If I were to do this, however, the client would freeze up and not be able to do anything. Plus, the client is not designed for opening ports to connect to the server.
What would be the best recommendation on waiting on data from the server to come to the client, without causing the client to lock up?
Thanks!
(and also, I'm not a \professional\ c# programmer, more of an amateur, so please don't give me very complicated answers)
If I were you, I would use either a background worker, or a second thread. If you don't want to do that, you can use thread.suspend.
To start a new thread:
Using System.Threading;
Thread t = new Thread()
t.Start;
Note: this is not recommended.
I am writing one server which will listen for the client connections continuously. It doesn't need any user interactions. So, I am trying to make it as a service. I installed it successfully, but it didn't run successfully except for showing error 1053. I found that the start/stop method should return within 30 seconds. As far as I am concerned that means my server should halt its action and return within 30 seconds. I cant imply this constraint on the server because the client may connect at any time. Can anybody show me a way to install this server as a service?
Note 1: I am using windows platform, c# language and VS 2010.
Note 2: Other ideas are also welcomed.
Without seeing your code, and going on just what you are saying here I would say you should implement threading.
Right now your application starts running and just blocks until a client connects. That isn't best practice, or for a Windows Service it's even impossible because of the 30 sec. limit.
What you should do is start the service and initialize everything (so it will return within 30 sec.) and then start a different listening thread. What also might be a good idea is to start another thread when a client connects. In that case you can handle multiple clients instead of just one.
Of course I have no idea of what transport layer or such you are using, but check out this example based on TCP: http://www.switchonthecode.com/tutorials/csharp-tutorial-simple-threaded-tcp-server
I am building a WCF service that will expose several operations, it will run in IIS because it needs HTTPS endpoints. Most of the operations will perform within seconds or less; however, one or two of these operations will take between 5-90 minutes.
The primary consumer of this service will be an ASP.NET MVC application; what is the correct way to do handle this?
Should I jackup the timeout and do some ajax calls? Should I add a table to my database, and have the long running operations update this database, and have the web interface poll this table every minute? I'm not sure what (if there is) the generally accepted best practice for this.
I wrote something similar for my senior project, basically a job scheduling framework.
I chose to go down the path of storing the "status" of the "job" in the database.
I wrote a manager windows service that implemented a WCF client (proxy)
I wrote a WCF Service that implemented my "worker host".
The manager service would read the queue from the database, and hand out work to all of my "worker hosts". The reason I had windows service perform this task as opposed to just having the UI talk directly to the worker host, was because it gave an extra level of control over the whole process.
I didn't like the idea of having "the network cable unplugged" from my worker host, and never getting a status update again from this specific job. So, the windows service gives me the ability to constantly monitor the progress of the WCF worker host, and if a connection error ever occurs (or something else unexpected), I can update the status to failed. Thus, no orphaned jobs.
Take a look at this
WCF Long Running Operations
There could be other options but they are nearly the same. You can also come up with some push notifications (I assume no data is returned) as one int the following link
WCF Push
I have my software(.NET) running on clients. I need to push the updates to the clients whenever available.
I thought to implement a web service which is running on the main server which broadcasts the update notifications to the client. For dat, CLient has to register their identity over the web to the server.
Server will send the notification on availability of the update. Client has to download the update from the server.
Will WCF would be the good option? .. Is that possible to implement? .. I know there are so many constraints in the networked environment. Suggestions are welcome...
You can make a table for application details including version and in application loading check the version of the application against last version number in database via a webservice if the versions are different fire error method to notify the client there is a new version of his application
but that I think valid from the start but you says the application is already running so I think you have to add this feature to the application and reinstall it on client machine.
check the following posts it may help you to find what you looking for
http://www.installsite.org/cgi-bin/frames.cgi?url=http://www.installsite.org/pages/en/tt_patch.htm
Is there a standard way for .NET Winforms apps to auto-upgrade?
http://www.devx.com/dotnet/Article/10045/1763
http://www.codeproject.com/KB/install/DDayUpdate_Part1.aspx
Maybe "long polling" is a solution. Consider this scenario: Your clients connect to a server using a timeout of lets say 60 minutes. If your server has an update it sends the data and closes the connection causing your client to reconnect and wait for the next update.
Wikipedia: Comet (Programming)
Since you provided details regarding infrastructure and communications I'll go with long polling again. Here is an example (first hit for "WCF long polling" on Google):
Simple Long Polling in WCF - Server
Write a windows service which runs on the clients and periodically checks the update server for new version of your software.
I am working on one Asp.Net application and need to send mails periodically based on some event. First I thought of creating a thread in global.asax and start thread in application_start. But that becomes a bit of problem when application pool crashes or something. So I implemented a windows service and started thread in that and log any errors in windows event log. This works fine. But I need to know whether I am implementing it correctly or is there a better way of doing it?
I think you are moving (or moved already) to the right direction.
We have similar architectures as well, in some cases we used MSMQ to queue outgoing notifications from the ASP.NET application then the Windows Service, usually called Messaging Manager, can grab asynchronously the incoming messages and send the emails or alerts out.
this proves to be effective and robust, if anything crashes after the message has been queued, nothing will be lost because the windows service will always process the messages in the queue, so you can have ASP.NET recycling or the machine with the windows service being rebooted, nothing is lost ever. And in fact in normal production mode, messages are sent out instantly, the decoupling or loose of sync is mostly hidden when everything is working smooth and servers are not overloaded or suffering anything.
In a later project we are now implementing something similar using TIBCO technologies, EMS for the queues and Business Works for queue subscribers.
Using a Windows Service for this kind of tasks is the preferred way instead of doing it in the ASP.NET application. You may also take a look at Quartz.NET which could simply your code for scheduling the task execution and dealing with threads. But if you don't want to write Windows Services probably the simplest would be to have a console application that will do the job of sending emails and then simply use the Windows Task Scheduler to run it at regular intervals.
Another option is a message-based approach. You could have a Windows Service/Console Application reading messages of a message queue (like msmq) and send email when a message is recieved. You can then have your ASP.NET application publish messages to this queue.
Minibuss is a lightweight client for msmq which is very easy to work with. Another options is NServiceBus.