如何将一些“统计”从c＃程序传递到另一个程序？

Question

I have command-line program that "do a lot of work" and produce "a lot of statistics". It's stocks trading software pretty critical to delays, bugs, and whatever, so I don't want to add GUI to it. (moreover GUI is required sometimes, but console application should be always launched)

I need GUI to friendly display collected statistic (in read-only mode). How to transfer that statistics? It would be enough to refresh it every second. I need to transfer bunch of data from one console c# program to another GUI (probably not c#) program, in future probably by network, but locally for now.

Statistics is like "sensors data", measured every second. There are a lot of (hundreds) of sensors. (in real word it's a lot of different values, like "profit", "orders per second" etc.)

Should I use plain file, db or someting else and how?

Answer 1

You can use any form of IPC (inter-process communication).

Since you're planning to go over the network in the future, I recommend WCF. If the GUI program isn't .NET, then you may need to use a lower-level solution, such as named pipes or sockets.

Answer 2

You can try to use a database with a queuing system or a messaging appliance. A server can receive messages to a queue and then the GUI can "subscribe" to the messages.

Microsoft Message Queuing

Also you can take a look at memory mapped files:

Memory-mapped file

These can be shared amongst applications simultaneously when configured properly.

Hope that helps,

Jeffrey Kevin Pry

Answer 3

让“服务器”将其信息存储在数据库中并让“客户端”在需要时进行轮询时，可能会更有效率和更有弹性。

Answer 4

I suggest you look at a technology like DDS . There are no databases involved and it is not hard to implement. I began looking at OpenSplice DDS recently. There are a number of different implementations out there.

Answer 5

This is going way beyond a single comment of course. What you will eventually need is a dispatching mechanism to notify subscribers about the data record update. Since the amount of data is huge, you might not want to opt for a persistence storage. If the dispatching to multiple subscribers looks overwhelming so far, you can go with a simple interproc (via shared object (aka named pipes) for the consumer-provider to be on the same machine or something more distributed otherwise)