First of all, sorry for my english. It's not my native language.
Here is the problem: I'm writing client-server application based on .net remoting. The application is some kind of calculator.
Client application has some field(number A and number B, and label for result) and some possible actions, represented by the buttons: Add, Substract, Multiply, Divide, etc..
Server application is a console application, that should habe following functions:
make this calculations
detect, what actions are done by the specific client.
Eg of output:
Server started
Client A(IP: 192.168.0.133) connected<br>
Client A Add 18 to 12<br>
Client A disconnected
The main problem is - how to get actions on server and how can i detect, what clients do.
Thx for help.
I know 2 common ways for tracing with .NET Remoting:
Turn on trace in app.config
Use Remoting Analyzator Studio, an open-source project from Codeproject.com.
This may not be ideal, but you can create a custom sink that hooks into the remoting channel which logs all remoting traffic. You can learn how to create a custom sink from Ingo Rammer's Advanced .NET Remoting book.
I've used his book to create custom sinks in the past.
We modified Mono TCP remoting channel to do this. It takes like 30 minutes and you can add information about the method call being invoked, time to execute and so on. It turns out to be a extremely good tool to measure performance on real servers. You can parse the output and learn which methods are taking more time, sending or receiving more data and so on. Really helpful.
Related
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.
The scenario that I bring forward is basically that of, interaction between two .NET executables.
I have made a .NET Windows Forms application in C# (Application-A) that runs on a user's machine and does some specific activity, due to which it collects some data.
Now I have another .NET Windows Forms executable (Application-B), also made in C#, which also does some specific activity based certain inputs or data provided.
Now what I want to do here is, call Application-B from the Application-A and pass the some data to it.
How do I accomplish this?
You can use several options. You have some resources for each option below.
.NET Remoting
WCF
Use a communication file
MSMQ
Two last options are valid only if the processes are in the same machine.
Since they are two separated processes I think that the easiest way to do this is using .NET Remoting. Here you can find documentation and examples about how to do it.
An alternative to Remoting is WCF (>= .NET 3.0). It performs better than remoting.
If the processes will be always in the same machine, if you don't want to use remoting on localhost you can communicate them through a file (simple solutions usually work fine!)
And other more complex solution is communicate them using a Message Queue (MSMQ). Here you cand find out an example about how to use it.
You can use MSMQ to communicate between the applications.
Any mechanism will do, however.
You could use file based communications (write to a known directory and read from it).
WCF is another solution.
WCF is going to allow you a lot of flexibility in the future : Should you ever decide to enhance this communication to support multiple modes of communication, app.config changes should be the majority of the work to support a different binding.
In some of the projects I've been involved in, there's a mix of communications technologies where one choice would've been far easier to maintain-- this leads me to embrace the WCF decision for its inherent flexibility (WCF also supports MSMQ should the need arise to have queued communication).
If you're concerned about the learning curve and you're sure that no future need will arise for you to embrace other communication topologies, remoting could be a useful solution. Remoting is probably the easiest, least-developer-work needed way of setting up IPC.
You should stay away from things like Web Services -- there's unnecessary overhead in the web service operations that WCF doesn't suffer from (WCF can still allow binary transport, for instance).
If both the applications are running on same user computer than
1- this can be achieved through inter-process communications channel (IPC channel)
2- If you are using .NET 4.0, you can use memory mapped files
If both the applications are running on different system
1- You can make use of .NET Remoting
2- You can have WCF service based communication
3- Web Service is also an option if using .NET 2.0 or lower versions
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
Is there any way to have apache "pass" the request it takes to a c# "application" to handle, allowing it to return specific content. I want to handle an intense amount of asynchronous calls to apache via javascript and have these calls routed through c# (much the way asp.net does). Has anyone successfully done this before? Any idea where to start looking?
Update:
Some more information. I want to be able to handle thousands of concurrent asynchronous requests as fast as can possibly occur writing the interpreting agent in some kind of threaded c# application. I could be wrong, but I dont think that iis with asp.net is tailored for this sort of thing (a proof of concept would be great).
I feel that going with something like apache would be better suited. If that means going from something else to c# first is fine I guess, but I would like to be more direct.
Apache actually supports running C# libraries using mod mono. Also, you could use CURL to send a web request to C# running on IIS. Another way would be to open a server socket directly in C#, and have apache (via php, python, or some other scripting language) connect to you C# application to handle the request. I think you need to be more specific about what exactly you are trying to accomplish.
with apache2, you could run mod_aspdotnet
or if it suits you, run some urls in proxy mode (pass them to another asp.net server), using mod_proxy
or Kibbee's excellent solution
So my company stores alot of data in a foxpro database and trying to get around the performance hit of touching it directly I was thinking of messaging anything that can be done asynchronously for a snappier user experience. I started looking at ActiveMQ but don't know how well C# will hook with it. Wanting to hear what all of you guys think.
edit : It is going to be a web application. Anything touching this foxpro is kinda slow (probably because the person who set it up 10 years ago messed it all to hell, some of the table files are incredibly large). We replicate the foxpro to sql nightly and most of our data reads are ok being a day old so we are focusing on the writes. plus the write affects a critical part of the user experience (purchasing), we store it in sql and then just message to have it put into foxpro when it can. I wish we could just get rid of the foxpro, unfortunately the company doesn't want to get rid of a very old piece of software they bought that depends on it.
ActiveMQ works well with C# using the Spring.NET integrations and NMS. A post with some links to get you started in that direction is here. Also consider using MSMQ (The System.Messaging namespace) or a .NET based asynchronous messaging solution, with some options here.
MSMQ (Microsoft Message Queueing) may be a great choice. It is part of the OS and present as an optional component (can be installed via Add/Remove Programs / Windows Components), meaning it's free (as long you already paid for Windows, of course). MSMQ provides Win32/COM and System.Messaging APIs. More modern Windows Communication Foundation (aka Indigo) queued channels also use MSMQ.
Note that MSMQ is not supported on Home SKUs of Windows (XP Home and Vista Home)
Its worth mentioning that the ActiveMQ open source project defines a C# API for messaging called NMS which allows you to develop against a single C# / .Net API that can then use various messaging back ends such as
ActiveMQ
MSMQ
TibCo's EMS
any STOMP provider
any JMS provider via StompConnect
You may want to look at MSMQ. It can be used by .NET and VFP, but you'll need to rewrite to use them. Here's an article that tells you how to use MSMQ from VFP. https://learn.microsoft.com/en-us/previous-versions/visualstudio/foxpro/ms917361(v=msdn.10)
Sorry if this isn't what you are asking for...
Have you considered some sort of cache behind the scenes that acts a bit like the "bucket system" when using asynchronous sockets in c/c++ using winsock? Basicly, it works by accepting requests, and sends an immediate response back to the web app, and when it finally gets around to finding your record, it updates it on the app via AJAX or any other technology of your choice. Since I'm not a C# programmer I can't provide any specific example. Hope this helps!
Does the Fox app use .CDX indexes? If so, you might be able to improve performance by adding indexes without needing to change any program code. If it uses .IDX indexes, though, the change would have to be done in the actual app.
As the problem is with writes, I would look more towards >removing< any unneeded indexes on the tables. As is common in RDBMS, every index on a FoxPro table slows down a write operation as the indexes need to be updated, and as you aren't reading directly from (or presumably directly querying) the table you shouldn't need very many indexes. You might also want to look at any triggers or field rules on the tables as they may be slowing down the write operation. Be sure your referential integrity is still preserved, though..