是否有可能无法收到 WSASend 调用的完成信息?

发布于 2024-10-27 10:33:42 字数 1359 浏览 7 评论 0原文

正如标题所示,在与 I/O 完成端口关联的套接字上进行成功 WSASend 调用是否可能因线程以外的任何原因而不会发布完成结束?

我遇到了一种奇怪的情况,似乎没有为 WSASend 发布完成,这会导致套接字泄漏;应用程序认为套接字的发送仍在等待中并拒绝释放它。

发送代码如下:

void CSocketServer::Write(
    Socket *pSocket,
    CIOBuffer *pBuffer) const
{
    pSocket->AddRef();

    pBuffer->SetOperation(IO_Write_Completed);
    pBuffer->SetupWrite();
    pBuffer->AddRef();

    DWORD dwFlags = 0;
    DWORD dwSendNumBytes = 0;

    if (SOCKET_ERROR == ::WSASend(
        pSocket->m_socket,
        pBuffer->GetWSABUF(), 
        1, 
        &dwSendNumBytes,
        dwFlags,
        pBuffer, 
        NULL))
    {
        DWORD lastError = ::WSAGetLastError();

        if (ERROR_IO_PENDING != lastError)
        {
            pSocket->OnConnectionError(WriteError, pBuffer, lastError);

            pSocket->WriteCompleted();  // this pending write will never complete...

            pSocket->Release();
            pBuffer->Release();
        }
    }
    // Note: even if WSASend returns SUCCESS an IO Completion Packet is 
    // queued to the IOCP the same as if ERROR_IO_PENDING was returned.
    // Thus we need no special handling for the non error return case.
    // See http://support.microsoft.com/default.aspx?scid=kb;en-us;Q192800
    // for details.
}

Like the title says, is it possible for a successful WSASend call on a socket associated with an I/O completion port to not post a completion for any reason other than the thread ending?

I have a strange situation where it looks like a completion isn't being posted for a WSASend, which results in a socket leak; the application thinks a send is still pending for the socket and refuses to release it.

The send code is as follows:

void CSocketServer::Write(
    Socket *pSocket,
    CIOBuffer *pBuffer) const
{
    pSocket->AddRef();

    pBuffer->SetOperation(IO_Write_Completed);
    pBuffer->SetupWrite();
    pBuffer->AddRef();

    DWORD dwFlags = 0;
    DWORD dwSendNumBytes = 0;

    if (SOCKET_ERROR == ::WSASend(
        pSocket->m_socket,
        pBuffer->GetWSABUF(), 
        1, 
        &dwSendNumBytes,
        dwFlags,
        pBuffer, 
        NULL))
    {
        DWORD lastError = ::WSAGetLastError();

        if (ERROR_IO_PENDING != lastError)
        {
            pSocket->OnConnectionError(WriteError, pBuffer, lastError);

            pSocket->WriteCompleted();  // this pending write will never complete...

            pSocket->Release();
            pBuffer->Release();
        }
    }
    // Note: even if WSASend returns SUCCESS an IO Completion Packet is 
    // queued to the IOCP the same as if ERROR_IO_PENDING was returned.
    // Thus we need no special handling for the non error return case.
    // See http://support.microsoft.com/default.aspx?scid=kb;en-us;Q192800
    // for details.
}

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

扫码二维码加入Web技术交流群

发布评论

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

评论(2

少钕鈤記 2024-11-03 10:33:42

您是否正在使用任何时髦的新功能,例如使用 FILE_SKIP_COMPLETION_PORT_ON_SUCCESS 关闭成功调用的完成功能?

您是否对发送进行了任何形式的流量控制,或者您只是在您愿意的时候发送,并且按照您想要的频率发送?您可能看到的只是缓慢的完成,因为 TCP 堆栈正在执行拥塞控制并且还无法发送您的数据。如果您继续以不受控制的方式发送数据,您通常会遇到完成时间开始变得越来越长的情况。特别是如果您发送数据的速率比 TCP 连接成功将数据发送到另一端的速率快,尤其是当 TCP 窗口不是那么大时。请参阅此处:http://www.lenholgate.com/ blog/2008/07/write-completion-flow-control.html 了解更多信息。

当然,这可能只是您的发送逻辑中的错误,您可以发布一些代码吗?

请注意,使用 FILE_SKIP_COMPLETION_PORT_ON_SUCCESS 时,WSARecv() 和 UDP 存在一个已知错误(因此与您的问题完全无关),如果数据报大于您所设置的缓冲区,则会出现您所描述的情况供应和 WSARecv() 调用将生成一个 WSAEMOREDATA;请参阅此处: http://www.lenholgate.com/blog/2010/01/file-skip-completion-port-on-success-and-datagram-socket-read-errors.html

Are you using any of the funky new features, like turning off completions for successful calls using FILE_SKIP_COMPLETION_PORT_ON_SUCCESS?

Are you doing any form of flow control on your sends or are you just sending whenever you feel like it and as often as you want? What you MIGHT be seeing is simply a SLOW completion due to the fact that the TCP stack is doing congestion control and cant send your data yet. If you keep sending data in an uncontrolled manner you can often get into a situation where completions start taking longer and longer to occur. Especially if you are sending data at a faster rate than the TCP connection is successfully getting it to the other side and especially if the TCP window isn't that big. See here: http://www.lenholgate.com/blog/2008/07/write-completion-flow-control.html for some more information.

Of course it could simply be a bug in your send logic, could you post some code?

Note that there's a known bug with WSARecv() and UDP (so nothing to do with your question at all) when using FILE_SKIP_COMPLETION_PORT_ON_SUCCESS which gives the situation that you describe if the datagram is bigger than the buffer that you supply and the WSARecv() call would have generated an WSAEMOREDATA; see here: http://www.lenholgate.com/blog/2010/01/file-skip-completion-port-on-success-and-datagram-socket-read-errors.html

溺孤伤于心 2024-11-03 10:33:42

通过设置 OVERLAPPED 结构的有效 hEvent 的低位,可以防止完成端口发布:

来自 GetQueuedCompletionStatus

即使你已经传递了函数a
与 a 关联的文件句柄
完成端口和有效的 OVERLAPPED
结构,应用程序可以防止
完成端口通知。这是
通过指定有效事件来完成
hEvent 成员的句柄
OVERLAPPED 结构,并设置其
低位。有效的事件句柄
其低位被设置保持I/O
从排队到完成
完成端口。

It's possible to prevent a completion port from posting by setting the low bit of an OVERLAPPED structure's valid hEvent:

From documentation for GetQueuedCompletionStatus:

Even if you have passed the function a
file handle associated with a
completion port and a valid OVERLAPPED
structure, an application can prevent
completion port notification. This is
done by specifying a valid event
handle for the hEvent member of the
OVERLAPPED structure, and setting its
low-order bit. A valid event handle
whose low-order bit is set keeps I/O
completion from being queued to the
completion port.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文