建筑建议通缉。 [英] Architecture advise wanted.

查看:98
本文介绍了建筑建议通缉。的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我不确定这是不是这个地方,但在这里它... ...

我有一个项目,我接受来自许多不同

来源的许多UDP数据包(即安装在大约一千台PC上的程序)。包裹

通常是快速连续发生的。


我应该选择什么样的架构以免丢弃任何

包?我在哪里可以了解更多有关如何处理UDP数据包?
的信息?例如,如果我的进程繁忙,UDP数据包是否会在那里(在网络堆栈中或其他地方)等待进程

来解决它?


谢谢

I am not sure if this is the place, but here it goes...
I have a project where I accept many UDP packets from many different
sources (i.e. programs installed on about a thousand PCs). The packets
usually comes in a rapid fire succession.

What kind of architecture should I go for in order to not to drop any
packets? And where can I learn more about how UDP packets are
processed? For instance, if my process is busy, will the UDP packet sit
there (in the network stack or whereever else) waiting for the process
to get around to it?

Thanks

推荐答案

单向。创建一个侦听端口n上的udp的侦听器线程。它抓取了
数据包并验证它们等,并将它们放入队列(阻塞队列,

等),堆栈将在某种程度上排队,然后只丢弃任何新的(一旦winsock队列满了,我就会认为这是
。 udp没有gaurenteed的一个原因

交付(tcp另一方面会重新发送数据包等)客户

然后需要重新传输,如果它没有得到一个使用你自己的算法回复。

hth

-

William Stacey,MVP


Frank Rizzo <无**** @ nospam.com>在消息中写道

新闻:#X ************** @ TK2MSFTNGP12.phx.gbl ...
One way. Create a listener thread that listens for udp on port n. It grabs
packets and verifies them, etc and puts them into a queue (blocking queue,
etc.) the stack will queue to some extent then just drop anything new (I
think) once the winsock queue is full. One reason why udp is not gaurenteed
delivery (tcp on the other hand would resend the packet, etc.) The client
then needs to restransmit if it does not get a response using your own algo.
hth

--
William Stacey, MVP

"Frank Rizzo" <no****@nospam.com> wrote in message
news:#X**************@TK2MSFTNGP12.phx.gbl...
我不确定如果这是这个地方,但它在这里......
我有一个项目,我接受来自许多不同来源的许多UDP数据包(即安装在大约一千台PC上的程序)。这些数据包通常会快速连续发生。

我应该采用什么样的架构才能不丢弃任何数据包?我在哪里可以了解有关如何处理UDP数据包的更多信息?例如,如果我的进程繁忙,UDP数据包是否会在那里(在网络堆栈中或其他地方)等待进程来处理它?<​​br />
谢谢
I am not sure if this is the place, but here it goes...
I have a project where I accept many UDP packets from many different
sources (i.e. programs installed on about a thousand PCs). The packets
usually comes in a rapid fire succession.

What kind of architecture should I go for in order to not to drop any
packets? And where can I learn more about how UDP packets are
processed? For instance, if my process is busy, will the UDP packet sit
there (in the network stack or whereever else) waiting for the process
to get around to it?

Thanks






William Stacey [MVP]写道:
William Stacey [MVP] wrote:
单向。创建一个侦听端口n上的udp的侦听器线程。它抓取数据包并验证它们等,并将它们放入队列(阻塞队列,等等),堆栈将在某种程度上排队,然后只丢弃任何新的(我认为)一次winsock队列已满。 udp没有gaurenteed交付的一个原因(另一方面tcp将重新发送数据包等)客户端如果没有使用你自己的算法得到响应,则需要重新传输。 /> hth
One way. Create a listener thread that listens for udp on port n. It grabs
packets and verifies them, etc and puts them into a queue (blocking queue,
etc.) the stack will queue to some extent then just drop anything new (I
think) once the winsock queue is full. One reason why udp is not gaurenteed
delivery (tcp on the other hand would resend the packet, etc.) The client
then needs to restransmit if it does not get a response using your own algo.
hth



谢谢。这就是我所确定的。唯一还有错误的是

,我在另一个线程上监听UDP数据包(因为

UdpClient.Receive阻塞),然后我生成一个

由调用类消耗。我只是不确定这个设置是否是

线程安全。


谢谢。


Thanks. That''s what I settled on. The only thing that still bugs is
that I listen for UDP packets on a different thread (because
UdpClient.Receive is blocking), then I generate an event that is
consumed by the calling class. I am just not sure whether this setup is
thread-safe.

Thanks.


不确定我跟着。为什么要举办活动?您的听众会将数据包

对象放入CQueue并再次收听。你的消费者会等到

队列有一个对象,然后去。所以你不需要一个活动,除非你因为其他原因使用了b $ b。您可以使用无锁队列和两个

锁定队列(等),但最后我认为一个锁定阻塞队列(而不是

Framework队列)关于所有事情的最佳结论并且是相对的易于验证线程安全性和rw内存屏障问题。什么是

你的拱门更详细? tia


-

William Stacey,MVP


" Frank Rizzo" <无** @ none.com>在消息中写道

新闻:#j ************** @ TK2MSFTNGP12.phx.gbl ...
Not sure I follow. Why gen an event? Your listener will put the packet
object into the CQueue and Listen again. Your Consumer will wait until the
queue has an object and then go. So you don''t need an event unless your
using for some other reason. You can get fancy with no-lock queues and two
lock queues (etc), but in the end I think a one lock blocking queue (not the
Framework queue) is about the best concidering all things and is relatively
easy to verify thread safety''ness and rw memory barrier issues. What is
your arch in more detail? tia

--
William Stacey, MVP

"Frank Rizzo" <no**@none.com> wrote in message
news:#j**************@TK2MSFTNGP12.phx.gbl...
William Stacey [MVP ]写道:
William Stacey [MVP] wrote:
单向。创建一个侦听端口n上的udp的侦听器线程。它
grabspackets并验证它们等,并将它们放入队列(阻塞
队列等),堆栈将在某种程度上排队,然后只丢弃任何新的东西(我想) winsock队列已满。 udp不是
gaurenteeddelivery的一个原因(另一方面tcp将重新发送数据包等)如果没有使用你自己的
算法获得响应,
客户端需要重新传输。 hth
One way. Create a listener thread that listens for udp on port n. It grabspackets and verifies them, etc and puts them into a queue (blocking queue,etc.) the stack will queue to some extent then just drop anything new (I
think) once the winsock queue is full. One reason why udp is not gaurenteeddelivery (tcp on the other hand would resend the packet, etc.) The clientthen needs to restransmit if it does not get a response using your own algo.hth


谢谢。这就是我所确定的。唯一还有错误的是我在另一个线程上监听UDP数据包(因为UdpClient.Receive阻塞),然后我生成一个由调用类消耗的事件。我只是不确定这个设置是否是线程安全的。

谢谢。


Thanks. That''s what I settled on. The only thing that still bugs is
that I listen for UDP packets on a different thread (because
UdpClient.Receive is blocking), then I generate an event that is
consumed by the calling class. I am just not sure whether this setup is
thread-safe.

Thanks.






这篇关于建筑建议通缉。的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆