快速多应用通信 [英] Fast Multiple Application Comunication
问题描述
这篇文章真的是为了获得一些关于在多个应用程序之间获得快速通信的最佳方式的意见。我已经在网上搜索了关于这个主题的
信息，并且发现了相互矛盾的观点和
远非理想的解决方案。
我的应用程序必须将大约50字节的少量数据发送到多个客户端应用程序。问题是这必须发生每秒1000美元左右。
我的第一次尝试是.net remotting我必须说非常有效/>
好吧。在我开发了大量帮助程序类来解决这些问题后，它可以很好地运行并且似乎有效。然而它没有
哪里接近足够快并且当你开始达到所需的刷新时间？b $ b率CPU占用内存使用率通过屋顶和
整个系统已经结束了。
所以我得出结论，远程处理不会提供答案。这给我留下了一个问题，还有什么？这是
a我迄今为止找到的候选人名单：
1.命名管道
2. Custom Remotting Sink
3. Mutex
4. TCP套接字
不是.net框架的一部分，并且似乎不支持消息
通知。我甚至不确定自定义romting Sink
是否会实际改善。 Mutex'再次在
..net框架中不会被禁止;它们不是面向对象的，并且高度不受微软的劝阻。一个TCP套接字需要大量的工作才能构建包装和通信层，我想要一个轻松的生活。
所以我会对最好的方法做出评论实现高性能和快速的应用程序通信。我应该说
主要是我关心在同一台机器上运行的应用程序
，理想情况下它是异步的。
This post is realy to get some opinions on the best way of getting fast
comunication between multiple applications. I have scowered the web for
imformation on this subject and have just found conflicting views and
far from ideal solutions.
My application has to send small amounts of data about 50bytes to
multiple client applications. The catch is that this has to happen
about 1000 times a second.
My first attempt was .net remotting which I have to say worked very
well. After I developed a host of helper classes to get around such
problems as events it works fine and seems to work. However it is no
where near fast enough and as you start to reach the desired refresh
rate the CPU races the memory usage goes through the roof and the
entire system keels over.
So I have reached the conclusion that remoting is not going to provide
me with the answer. That leaves me with a question, what else? Here is
a list of the candidates I have found to date:
1. Named Pipes
2. Custom Remotting Sink
3. Mutex
4. TCP Socket
Unfortunatly all these solutions seem to have problems. A named pipe is
not part of the .net framework and does not seem to support message
notification very well. I am not even sure if a custom romting Sink
will actually improve things. Again Mutex''s are not inherant in the
..net framework; they are not object orientated and are highly
discouraged by Microsoft. A TCP Socket would require allot of work to
construct wrappers and comunications layers, I want an easy life.
So I would apreciate comments on the best method to achieve high
performance and fast inter application comunication. I should say that
primarily I am concerned with applications running on the same machine
and idealy it would be asynchronous.
推荐答案
每秒1000次？轻松生活？我不认为他们是兼容的！
命名管道是最好的，你几乎肯定会为他们找到一个包装器
pinvoke 。净。如果做不到这一点，我会看UDP而不是TCP。使用System.Net.Sockets和UdpClient对象很容易实现
。
Steve
1000 times per second? Easy life? I don''t think they''re compatible!
Named pipes are best and you''ll almost certainly find a wrapper for them at
pinvoke.net. Failing that, I would look at UDP rather than TCP. It''s very
easy to do using System.Net.Sockets and UdpClient object.
Steve
如果您在同一台机器上运行，您似乎遗漏了共享内存，这将是最快的解决方案
。这是一个简单的包装器，可以帮助你解决一下 http://addressof.com/blog/archive/2003/05/01/164.aspx
你有另一个解决方案遗漏是使用共享文件进行
通信，这也可以非常快（我没有问题通过这种机制推动
10k /秒）。通常，这样做的方法是使用
检查点机制，然后只在文件流中搜索。我有一个旧的
例子如果你对这条路线感兴趣我可能会退出
....
我不确定你在谈论下面的互斥锁是什么，
互斥体是在.net框架中实现的，但它们不用于从一个推送数据的
应用程序到另一个，它们用于同步？
也没有什么说它们不好用;它们经常用于同步进程，它们通常不会在
相同的进程空间内使用，因为Monitor提供了相同的功能和更好的
性能，没有操作系统资源的开销。
欢呼，
Greg Young
MVP - C＃
" Olie" <流**** @ gmail.com>在消息中写道
news：11 ********************* @ g10g2000cwb.googlegro ups.com ...
You seem to have left out shared memory which would be the fastest solution
if you are running on the same machine. Here is a simple wrapper that may
help you out a bit http://addressof.com/blog/archive/2003/05/01/164.aspx
Another solution that you have left out is using a shared file for
communications which can also be extremely fast (I had no issue pushing
10k/second through this mechanism). Generally the way to do this is to use a
checkpointing mechanism, then just seek within the filestream. I have an old
example I could probably pull out if you are interested in going this route
....
I am not sure what you are talking about in dealign with the mutex below,
mutexes are implemented in the .net framework but they are not used for
pushing data from one app to another, they are used for synchronization?
Also there is nothing that says they are bad to use; they are quite often
used to synchronize processes, they are just not generally used within the
same process space as Monitor provides the same functionality with better
performance and without the overhead of the OS resource.
Cheers,
Greg Young
MVP - C#
"Olie" <ow****@gmail.com> wrote in message
news:11*********************@g10g2000cwb.googlegro ups.com...
这篇文章真的是为了在多个应用程序之间获得快速通信的最佳方式获得一些意见。我已经在网上搜索了关于这个主题的信息，并且发现了相互矛盾的观点，而且远非理想的解决方案。
我的应用程序必须发送大约50字节的少量数据
多个客户端应用程序。问题是，这必须每秒发生大约1000次。
我的第一次尝试是.net remotting，我必须说非常好。在我开发了大量辅助类来解决诸如事件之类的问题后，它工作正常并且似乎有效。然而，它没有足够快的速度，当你开始达到所需的刷新率时，CPU会争夺内存使用率，通过屋顶和整个系统的整个过程。
所以我得出结论，远程处理不会给我答案。这给我留下了一个问题，还有什么？这是
我迄今为止找到的候选人名单：
1.命名管道
2.自定义Remotting Sink
3. Mutex
4 TCP套接字
不幸的是，所有这些解决方案似乎都存在问题。命名管道不是.net框架的一部分，似乎不支持消息
通知。我甚至不确定自定义romting Sink
是否能真正改善事物。 Mutex'再次在
.net框架中不会被禁止;它们不是面向对象的，并且受到微软的高度劝阻。 TCP套接字需要分配工作来构建包装和通信层，我想要一个轻松的生活。
所以我会评价最佳方法以获得高性能和快速的应用程序通信。我应该说
主要是我关心在同一台机器上运行的应用程序
并且理想情况下它将是异步的。
This post is realy to get some opinions on the best way of getting fast
comunication between multiple applications. I have scowered the web for
imformation on this subject and have just found conflicting views and
far from ideal solutions.
My application has to send small amounts of data about 50bytes to
multiple client applications. The catch is that this has to happen
about 1000 times a second.
My first attempt was .net remotting which I have to say worked very
well. After I developed a host of helper classes to get around such
problems as events it works fine and seems to work. However it is no
where near fast enough and as you start to reach the desired refresh
rate the CPU races the memory usage goes through the roof and the
entire system keels over.
So I have reached the conclusion that remoting is not going to provide
me with the answer. That leaves me with a question, what else? Here is
a list of the candidates I have found to date:
1. Named Pipes
2. Custom Remotting Sink
3. Mutex
4. TCP Socket
Unfortunatly all these solutions seem to have problems. A named pipe is
not part of the .net framework and does not seem to support message
notification very well. I am not even sure if a custom romting Sink
will actually improve things. Again Mutex''s are not inherant in the
.net framework; they are not object orientated and are highly
discouraged by Microsoft. A TCP Socket would require allot of work to
construct wrappers and comunications layers, I want an easy life.
So I would apreciate comments on the best method to achieve high
performance and fast inter application comunication. I should say that
primarily I am concerned with applications running on the same machine
and idealy it would be asynchronous.
Mind要根据您的要求添加客户端应用程序的数量，这个
的数字很重要，我想你使用的任何IPC机制，除非你愿意，否则你会盯住CPU的b $ b投资多CPU箱。 Anothor
问题是;你正在向每个单独的
客户端推送1000 * 50字节的消息，或者你只是在广播？
Willy。
" ; OLIE" <流**** @ gmail.com>在消息中写道
新闻：11 ********************* @ g10g2000cwb.googlegro ups.com ...
|这篇文章真的是为了获得关于快速获取的最佳方式的一些意见
|多个应用程序之间的通信。我已经浏览了网页
|关于这个主题的信息并且刚刚发现了相互矛盾的观点和
|远非理想的解决方案。
|
|我的应用程序必须将大约50字节的少量数据发送到
|多客户端应用程序问题是这必须发生
|每秒约1000次。
|
|我的第一次尝试是.net remotting，我必须说工作非常好
|好。在我开发了一系列助手课程之后，这样就可以了解这些
|问题作为事件它工作正常，似乎工作。但是没有
|接近足够快的地方，当你开始达到理想的刷新时间
|评价CPU比赛的内存使用情况通过屋顶和
|整个系统都结束了。
|
|所以我得出结论，远程处理不会提供
|我有答案。这给我留下了一个问题，还有什么？这是
|我迄今为止找到的候选人名单：
|
| 1.命名管道
| 2.定制Remotting水槽
| 3. Mutex
| 4. TCP套接字
|
|不幸的是，所有这些解决方案似乎都存在问题。命名管道是
|不是.net框架的一部分，似乎不支持消息
|通知很好。我甚至不确定是否定制romting Sink
|实际上会改善一切。 Mutex'再次不会在
|中出现.net框架;它们不是面向对象的，而且非常高。
|受到微软的劝阻。 TCP Socket需要分配工作才能获得
|构建包装和通信层，我想要轻松的生活。
|
|所以我会对最好的方法进行评论，以实现高价
|性能和快速的应用程序通信。我应该说
|主要是我关心在同一台机器上运行的应用程序
|并且理想情况下它将是异步的。
|
Mind to add the number of client applications to your requirements, this
figure is important has I guess whatever IPC mechanims you use, you will peg
the CPU, unless you are willing to invest into multi-cpu boxes. Anothor
question is; are you pushing 1000 * 50 byte messages to each separate
client, or are you simply broadcasting?
Willy.
"Olie" <ow****@gmail.com> wrote in message
news:11*********************@g10g2000cwb.googlegro ups.com...
| This post is realy to get some opinions on the best way of getting fast
| comunication between multiple applications. I have scowered the web for
| imformation on this subject and have just found conflicting views and
| far from ideal solutions.
|
| My application has to send small amounts of data about 50bytes to
| multiple client applications. The catch is that this has to happen
| about 1000 times a second.
|
| My first attempt was .net remotting which I have to say worked very
| well. After I developed a host of helper classes to get around such
| problems as events it works fine and seems to work. However it is no
| where near fast enough and as you start to reach the desired refresh
| rate the CPU races the memory usage goes through the roof and the
| entire system keels over.
|
| So I have reached the conclusion that remoting is not going to provide
| me with the answer. That leaves me with a question, what else? Here is
| a list of the candidates I have found to date:
|
| 1. Named Pipes
| 2. Custom Remotting Sink
| 3. Mutex
| 4. TCP Socket
|
| Unfortunatly all these solutions seem to have problems. A named pipe is
| not part of the .net framework and does not seem to support message
| notification very well. I am not even sure if a custom romting Sink
| will actually improve things. Again Mutex''s are not inherant in the
| .net framework; they are not object orientated and are highly
| discouraged by Microsoft. A TCP Socket would require allot of work to
| construct wrappers and comunications layers, I want an easy life.
|
| So I would apreciate comments on the best method to achieve high
| performance and fast inter application comunication. I should say that
| primarily I am concerned with applications running on the same machine
| and idealy it would be asynchronous.
|
这篇关于快速多应用通信的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
