i have an requirements where i need to have two instances of the custom window service code running at the same time but only one should be doing the work until the other one fails or die.
i'm trying to come up with the clean and simple design to do this.
one way:
create a temp table
and have this two service talk to each other via the table
and if the running one goes down, using probably last modified date
time on the table
then the other one will start
but this is very manual. i'm using c# 4.0.
are there better ways to achieve this?
i saw there's something like EventWaitHandle but not sure if it would be simple to use it.
thanks
~m
Implement a kind of lock/mutex using a common database (as you mentioned)
If the instances on the different servers know of each other (config?), they can chat with each other and decide who's boss.
If the instances do not know of each other try using an UDP broadcast to announce themselves to each other and then decide who's boss.
If you are able to do #1 and do it generic exposing it through a web service that solution would be reusable for other applications as well. I use such a solution myself.
Consider exposing a ping api endpoint (simple Rest API ping method) on both services so that each can monitor the other service state.
Related
Good afternoon,
I'm trying to find a way to synchronize an ObservableCollection between applications. Basically, one would be the server that has a collection of strings, and the other would be the client which would have that same list and display it in a GUI. When a string is modified on the server, I want the modification to be reflected on the client.
I'm not very familiar with server-client architectures or frameworks and would like to know where to start. So far I have looked at the WCF architecture and it looks like it might be a bit overkill for what I'm trying to accomplish, but I could be wrong.
Any guidance will be greatly appreciated.
WCF is the standard way of performing inter-process and inter-machine communications for .NET applications and it works very well. You need your client application to connect to the server and get the current state of the collection. Then each time the collection changes the client needs to be notified so it can apply the same change locally. There are many resource on the Web and at MSDN describing how to create a WCF connection.
I am working on a client server project. Client is built in WPF using mvvm pattern and service is built using WCF. I have to perform some action on a specific event which I am able to do by calling some service functions. I will have to do call the same function on a regular basis at a specific time as configured in database. Can somebody suggest a better approach to achieve this. I am thinking of creating a windows service specifically to do such things. Is that a good choice ? Thanks a lot.
Create a console app that calls the service, and add a scheduled task in Windows to run the console app at a specified interval. It is a lot easier and cleaner than creating a service for such a simple application.
I think the best approach is to use an already created (and properly tested) scheduling system or library instead of developing your own. For a Java project I worked on, I used the Quartz library, which handled the job quite nicely and it integrated easily into said project. It has a .NET port here, never used it but I suppose it works similarly.
This is my first time dabbling in windows services.
I have a service I would like to manage, I would like to be able to connect to this service via a command line / REPL of sorts to avoid the development time of working on a user interface. I was thinking we could communicate much like attaching to an Asterisk daemon or somewhat like connecting to a MySQL server which to me seems like nothing more than a simple custom shell spawned to handle requests. However, I am always concerned about how efficient my code is and would like to keep to common practices. This will be connecting on the same local machine.
My proposed solution:
I believe I can make simple network stream, to create a simple Read - Eval - Print - Loop.
Another option is to use WCF, however my question would then be, how efficient is this as opposed to packet handling?
My question:
What are some standard practices for communicating with or managing services on the local machine?
I'm trying to learn more about service-oriented design, any resources that could help explain common practice models would be much appreciated.
Of course there are so many ways to do this. The way I would recommend is to make sure you use log4net (or some other logging framework) and log the important info. Create the solution with 3 projects, the first will be the "service logic" or the business service, with the second being the windows service wrapper that starts that service, and the third being a console app that does much the same as the windows service only giving you the ability to interact as you wish. The advantage of the console logging appender is that you still get the console output without actually writing to the console... it give good separation.
I will give another option that I have used in the past, but would give with caution. You can selfhost a WCF service inside a windows service. It gives a nice interface that gets away form the messy self rolled TCP server approach. The caution is that if done wrong it can eat up lots of memory and CPU cycles.
Say two clients machines recall a ticket. If one client makes a change, what is the best way to keep the second client in sync? Obviously I don't want the second client to overwrite the first one's changes, but additionally I want the second client to be updated because it may do an operation based on that ticket that needs to include the update the other machine made.
Some approaches I've considered:
MSMQ - our application actually used to use this but by the time I was hired it was just dead code that was no longer being used. I've thought about reinstating it but I don't feel that MSMQ quite offers the functionality I want in regard to not just notifying other clients of a change, but also distributing that change.
SQL Service Broker - it's been a while since I looked at this but I definitely remember it was not the route I wanted to go.
Web Service - Instead of having applications each access the database themselves, I think having a webservice to be in the middle to be responsible for forming the business objects and handing them out would be a partial fix, except for the fact that our application is purely windows forms. But surely there is another way to implement this without the need for an actual web server?
Sockets - I've thought about just creating a windows service that integrates with our business object and uses windows sockets to either a) Just tell other clients they need to call the database for updates or b) Actually give the clients the updates so they don't need to call the database.
This is new territory for me and I'm not aware of any good books or articles that address design patterns that deal with this issue so please direct me to any if you know of them.
With regards to your web-service option, be aware that WCF does not require a web-server. All it needs is a Host, and you can implement one yourself trivially. That host would probably be a Windows Service for your needs.
I m not sure but you can make use of
Observer
- Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.
and implement it
I've been asked to research approaches to deal with an app we're supposed to be building. This app, hypothetically a Windows form written in C#, will issue commands directly to the server if it's connected, but if the app is offline, the state must be maintained as if it was connected and then sync up and issue data changes/commands to the server once it is connected.
I'm not sure where to start looking. This is something akin to Google Gears, but I don't think I have that option if we go a Winform route (which looks likely, given that there are other functions the application needs that a web app couldn't perform). Is the Microsoft Sync framework a viable option? Does Silverlight do anything like this? Any other options? I've Googled around a bit but would like the community input on what's best given the scenario.
The Microsoft Sync Framework definitely supports the scenario you describe, although I would say that it's fairly complicated to get it working.
One thing to understand about the Sync Framework is that it's really two quite distinct frameworks shipping in the same package:
Sync Framework
ADO.NET Sync services v. 2
The ADO.NET Sync services are by far the easiest to set up, but they are constrained to synchronizing two relational data stores (although you can set up a web service as a remote facade between the two).
The core Sync Framework has no such limitations, but is far more complex to implement. When I used it about six months ago, I found that the best source to learn from was the SDK, and particularly the File/Folder sync sample code.
As far as I could tell, there was little to no sharing of code and types between the two 'frameworks', so you will have to pick one or the other.
In either case, there are no constraints on how you host the sync code, so Windows Forms is just one option among many.
If I understand correctly, this doesn't sound like an actual data synchronization issue to me where you want to keep two databases in sync. it sounds more like you want a reliable mechanism for a client to call functions on a server in an environment where the connection is unstable, and if the connection is not present at the time, you want the function called as soon as the connection is back up.
If my understanding is right, this is one option. if not, this will probably not be helpful.
This is a very short answer to an in-depth problem, but we had a similar situation and this is how we handled it.
We have a client application that needs to monitor some data on a PC in a store. When certain events happen, this client application needs to update our server in the corporate offices, preferably Real-Time. However, the connection is not 100% reliable, so we needed a similar mechanism.
We solved this by trying to write to the server via a web service. If there is an error calling the web service, the command is serialized as an XML file in a folder named "waiting to upload".
We have a routine running in our client app on a timer set for every n minutes. When the timer elapses, it checks for XML files in this folder. If found, it attempts to call the web service using the information saved in the file, and so on until it is successful. Upon a successful call, the XML file is deleted.
It sounds hack-ish, but it was simple to code and has worked flawlessly for five years now. It's actually been our most trouble-free application all-around and we've implemented the pattern elsewhere successfully