我即将重新构建一个在单个节点上进行原型化的实时系统,并指定它应该如何扩展到多个节点(在任何一个LAN中可能永远不会超过20个).某些功能将在每个节点的基础上相乘,其中一些功能将在每个系统的基础上保持集中.每个节点与该中央单元(可能是主节点)之间需要通信,但不需要在各个节点之间进行通信.
由于系统的实时需求,UDP应该被考虑用于该通信.但是......它几乎总是被描述为不可靠.总是这样吗？它不依赖于网络的规模,网络上的数据负载以及协议的使用方式吗？
例如,假设我有一个中央单元,通过寻址UDP消息定期轮询每个节点,每个节点立即通过UDP响应其数据.(隔离的)网络上没有其他通信.假设还存在一些机制来确保从不存在任何冲突(例如,所有节点对于轮询消息的响应具有最大传输长度,并且延迟被固定到已知级别).在像这样的简单结构化网络中是否存在任何(隐藏)原因,您将无法传输/接收每个最后的UDP数据包并且具有接近100%的可靠性？
编辑:这个问题的细节受到"不可靠"意味着什么的混淆,以及它是否只适用于UDP,或者是否适用于使用UDP的系统.我选择在这个问题中留下这种混乱,因为回顾UDP上的大量材料,我可以看到这种混乱可能非常普遍,而那些强调混乱并克服它的答案可能是有价值的.
有很多关于如何每 N 秒执行某些操作的提示，但我没有发现任何明确说明这些方法中的任何一个是否由于延迟而慢慢地与系统时钟不同步。
我有一个在 Windows 上运行的多线程应用程序。我需要知道，在较高优先级任务和线程允许的几毫秒内，一个特定线程将根据系统时钟“精确地”在凌晨 1 点可靠地执行，然后在凌晨 1 点 + N 秒、凌晨 1 点 + 2N 秒等处执行。 ..并在晚上 11 点、晚上 11 点 + N、晚上 11 点 + 2N 等无限期地继续可靠地执行此操作。是的 - 情况是这样的（无论如何对我来说）每小时有整数个 N 秒周期。
我完全期望线程执行的实际时间为 1am + d1、1am + N + d2、1am + 2N + d3，...其中每个 d(i) 都是一些延迟增量。这也没什么问题，只要增量值的分布保持相当一致且相当低——通常最多几十毫秒，很少有高于该值的峰值。我不介意系统时钟是否与全球时间标准不同步。
我可以使用什么计时结构来实现此目的？是否有什么东西可以保持同步本身，或者我是否必须编写一些东西来随着处理器负载在白天的上升和下降而不断调整自身以保持同步？
请参阅下面的代码 - 我想知道如何,或者甚至可以编写A :: DoThisOrThat()的主体
class A
{
void DoThis( void ) { // any function body you like... }
void DoThat( void ) { // any function body you like... }
void DoThisOrThat( const bool doThis );
};
void A::DoThisOrThat( const bool doThis )
{
void (*pMemberFunction)( void );
pMemberFunction = doThis? &A::DoThis : &A::DoThat;
(*pMemberFunction)(); // member function invoked controlled by parameter
}
此函数的所有三行都可能需要重写以正确定义成员函数的范围.如上所述,我在第二行得到一个调用约定冲突,我指定了pMemberFunction.我无法解释清楚这一点的简单示例 - 所有示例都很容易找到一个成员变量来保存成员函数指针.我可以不只是创建一个局部变量来做同样的事情吗？
如果系统正在尝试关闭，则应用可以通过覆盖OnQueryEndSession()并返回来阻止此关闭FALSE。当然，这意味着WM_ENDSESSION是有关关机的唯一明确信息。
另一方面，对这个问题的最高答案不亚于雷蒙德·陈（Raymond Chen）所说的回答，WM_ENDSESSION本质上是毫无意义的。因此，这令人困惑。
在确定执行哪种类型的应用程序关闭工作应该响应的消息（如果有）时，是否存在某种“最佳实践”原则可应用？
特别是，如果未处理任何一条消息，关闭过程是否会导致关闭应用程序，就像用户手动关闭了该应用程序一样（例如，单击红色的X关闭按钮）？