在选择中响应 ICMP

发布于 2024-12-19 10:56:29 字数 725 浏览 1 评论 0原文

我感兴趣的基本代码序列是（伪代码）

sendto(some host); // host may be unreachable for now which is normal
...
if(select(readfs, timeout)) // there are some data to read
  recvfrom();

从Win2000开始，将UDP数据报发送到无法到达的端口后发回的ICMP数据包会触发select，之后recvfrom会因WSAECONNRESET而失败。这种行为对我来说是不可取的，因为我希望 select 在这种情况下以超时完成（没有数据可读取）。在 Windows 上，可以使用 WSAIoctl SIO_UDP_CONNRESET 解决此问题 ( http://support.microsoft.com/kb/263823）。

我的问题是：

SIO_UDP_CONNRESET 在这种情况下是最好的方法吗？
是否有其他一些方法可以忽略“select”的 ICMP 或过滤它以进行接收（也许，忽略 Windows 上的 WSAECONNRESET 错误将其视为超时，在其他情况下可以触发此错误）吗？
Linux 和 Unix（Solaris、OpenBSD）上是否存在类似问题？

原文

The basic code sequence I'm interesting for is (pseudocode)

sendto(some host); // host may be unreachable for now which is normal
...
if(select(readfs, timeout)) // there are some data to read
  recvfrom();

Since Win2000, ICMP packet, which is sent back after sending UDP datagram to unreachable port, triggers select, after that recvfrom fails with WSAECONNRESET. Such behaviour isn't desirable for me, because I want select to finish with timeout in this case (there are no data to read). On Windows this can be solved with WSAIoctl SIO_UDP_CONNRESET ( http://support.microsoft.com/kb/263823 ).

My questions are:

Is SIO_UDP_CONNRESET the best way in this situation?
Are there some other methods to ignore ICMP for "select" or to filter it for recvfrom (maybe, ignoring WSAECONNRESET error on Windows treating it like timeout, can this error be triggered in some other case)?
Are there similar issues on Linux and Unix (Solaris, OpenBSD)?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

征﹌骨岁月お 2024-12-26 10:56:29

select() 的 readfds 设置实际上只是报告套接字上的 read() 不会阻塞 ——它不承诺是否有实际数据可供读取。

我不知道你具体想用两秒超时来完成什么，而不仅仅是永远休眠——也不知道为什么你不能只添加一个 if 块来检查 来自 recvfrom() 的 WSAECONNRESET ——但如果不能很好地处理这种情况，就会感觉你的设计过于复杂。

许多 Linux 系统上的 select_tut(2) 联机帮助页有一些正确使用 select() 的指南。以下是最适合您情况的几条规则：

   1.  You should always try to use select() without a timeout.
       Your program should have nothing to do if there is no
       data available.  Code that depends on timeouts is not
       usually portable and is difficult to debug.

   ...

   3.  No file descriptor must be added to any set if you do not
       intend to check its result after the select() call, and
       respond appropriately.  See next rule.

   4.  After select() returns, all file descriptors in all sets
       should be checked to see if they are ready.

select()'s readfds set really just reports that a read() on the socket won't block -- it doesn't promise anything about whether or not there is actual data available to read.

I don't know what specifically you're trying to accomplish with the two-second timeout rather than just sleeping forever -- nor why you can't just add an if block to check for WSAECONNRESET from recvfrom() -- but it feels like you've got an overly-complicated design if it doesn't handle this case well.

The select_tut(2) manpage on many Linux systems has some guidelines for properly using select(). Here's several rules that seem most apropos to your situation:

   1.  You should always try to use select() without a timeout.
       Your program should have nothing to do if there is no
       data available.  Code that depends on timeouts is not
       usually portable and is difficult to debug.

   ...

   3.  No file descriptor must be added to any set if you do not
       intend to check its result after the select() call, and
       respond appropriately.  See next rule.

   4.  After select() returns, all file descriptors in all sets
       should be checked to see if they are ready.

回复收藏 0 原文

~没有更多了~