【问题标题】:C# TCP Socket "Blocking" Property InconsistencyC# TCP 套接字“阻塞”属性不一致
【发布时间】:2010-08-11 15:45:05
【问题描述】:

我通过以下方式使用 tcp 套接字:

m_socket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp); m_socket.ReceiveTimeout = 15;

一般流程是我在一个无限的while循环中运行m_socket.Receive,并且在某个时候套接字会长时间为空,但我不想关闭它。 相反,我想继续尝试每 15 秒读取一次异常并超时。

发生的情况是,在套接字第一次变空时,我在 15 秒后得到了一个超时套接字异常,正如预期的那样。 然后,因为我仍在循环中,所以再次调用 m_socket.Receive - 但是这次无法完成非阻塞套接字操作异常被抛出(这不是我所期望的,它应该再阻塞 15 秒) 即使当我查询 m_socket.Blocking 上面的一行时,它说的是 TRUE。

有趣的是,如果我执行 m_socket.Blocking = true;就在 m_socket.Receive 之前,一切都按预期运行(仅每 15 秒抛出一次超时异常)。

唯一可能的解释是超时异常以某种方式改变了接收操作或一般的套接字操作以非阻塞方式工作,而没有相应地改变“阻塞”属性。

【问题讨论】:

  • 请发布接收循环代码

标签: c# .net sockets networking tcp


【解决方案1】:

我找到了this

显然,在 .NET 4.0 中修复了一个关于此问题的错误

【讨论】:

    【解决方案2】:

    您是否在同一个线程上阻塞另一个 winsock 函数调用?

    来自msdn

    注意发出阻塞时 Winsock 调用,如 send、recv、 选择、接受或连接函数 调用,Winsock 可能需要等待一个 通话前的网络事件可以 完全的。温索克执行 在这种情况下警惕等待, 这可以被打断 异步过程调用 (APC) 安排在同一个线程上,并且 从而产生未指定的结果。做 不发出阻塞 Winsock 功能 在不确定的情况下调用 当前线程没有在里面等待 另一个阻塞 Winsock 函数 称呼;这样做会导致 不可预知的行为。

    【讨论】:

      【解决方案3】:

      ReceiveTimeout 以毫秒为单位指定。您应该设置 15000 以使其工作。看http://msdn.microsoft.com/en-us/library/system.net.sockets.tcpclient.receivetimeout%28v=vs.110%29.aspx

      【讨论】:

        猜你喜欢
        • 2013-10-15
        • 1970-01-01
        • 1970-01-01
        • 2011-05-31
        • 2012-01-05
        • 1970-01-01
        • 1970-01-01
        • 2011-12-18
        • 1970-01-01
        相关资源
        最近更新 更多