C++ 非阻塞套接字选择发送太慢？

Question

我有一个维护“流式”套接字列表的程序。这些套接字被配置为非阻塞套接字。

目前，我已经使用一个列表来存储这些流式套接字。我有一些数据需要发送到所有这些流式套接字，因此我使用迭代器循环遍历这个流式套接字列表并调用下面的 send_TCP_NB 函数:

问题是在发送到此 send_TCP_NB 函数之前存储数据的我自己的程序缓冲区的可用大小缓慢减小，表明发送速度慢于将数据放入程序缓冲区的速率。程序缓冲区的速率约为每秒 1000 个数据。每个数据很小，大约100字节。

因此，我不确定我的 send_TCP_NB 函数是否有效或正确地工作？

int send_TCP_NB(int cs, char data[], int data_length) {

    bool sent = false;
    FD_ZERO(&write_flags);      // initialize the writer socket set
    FD_SET(cs, &write_flags);   // set the write notification for the socket based on the current state of the buffer
    int status;
    int err;

    struct timeval waitd;       // set the time limit for waiting
    waitd.tv_sec = 0;
    waitd.tv_usec = 1000;

    err = select(cs+1, NULL, &write_flags, NULL, &waitd);
    if(err==0)
    {
        // time limit expired
        printf("Time limit expired!\n");
        return 0;   // send failed
    }
    else
    {
        while(!sent)
        {
                if(FD_ISSET(cs, &write_flags))
                {
                     FD_CLR(cs, &write_flags);
                     status = send(cs, data, data_length, 0);
                     sent = true;
                }
         }

         int nError = WSAGetLastError();
         if(nError != WSAEWOULDBLOCK && nError != 0)
         {      
              printf("Error sending non blocking data\n");
              return 0;
         }
         else
         {
              if(nError == WSAEWOULDBLOCK)
              {
                    printf("%d\n", nError);
              }
              return 1;
          }
       }
}

Answer 1

如果您确切地想出了这个函数应该做什么，那将会有所帮助。它实际做的可能不是您想要的，并且有一些不好的特性。

我注意到它的主要功能是:

1. 修改一些全局状态
2. 等待(最多 1 毫秒)写入缓冲区有一些空闲空间
3. 如果缓冲区仍然满则中止
4. 在套接字上发送 1 个或多个字节(忽略发送了多少)
5. 如果有错误(包括发送决定它会阻止尽管早期检查)，获取它的值。否则，获取随机误差值
6. 可能会打印一些东西到屏幕上，这取决于获得的值(value)
7. 返回 0 或 1，具体取决于错误值。

对这些要点的评论:

1. 为什么 write_flags 是全局的？
2. 您真的打算阻止此功能吗？
3. 这可能没问题
4. 您肯定关心有多少的数据被发送了吗？
5. 我在文档中没有看到任何内容表明如果 send 成功
这将为零

如果您弄清楚此函数的实际意图是什么，则可能更容易确保此函数实际实现该意图。

说的是

I have some data that I need to send to all these streaming sockets

您的需求确切是什么？

如果您的需求是必须在继续之前发送数据，那么使用非阻塞写入是不合适的*，因为您将不得不等到可以写入数据为止。

如果您的需求是数据必须在未来的某个时候发送，那么您的解决方案缺少一个非常关键的部分:您需要为每个套接字创建一个缓冲区来保存需要发送的数据，然后您周期性地需要调用一个检查套接字的函数来尝试写入任何它能写的东西。如果您为后一个目的生成一个新线程，这就是 select 非常有用的事情，因为您可以使该新线程阻塞直到它能够写入一些东西。但是，如果您不生成新线程而只是定期从主线程调用一个函数来检查，那么您就不需要费心了。 (只写你能写的一切，即使它是零字节)

*:至少，这是一个非常不成熟的优化。在某些边缘情况下，您可以通过智能地使用非阻塞写入来获得稍微更高的性能，但是如果您不了解这些边缘情况是什么以及非阻塞写入将如何提供帮助，那么猜测它是不太可能的取得良好的效果。

编辑:正如另一个答案所暗示的，这是操作系统无论如何都擅长的事情。与其尝试编写自己的代码来管理它，不如在发现套接字缓冲区已满时增大系统缓冲区。如果它们仍然填满，你应该真的认真考虑你的程序无论如何都需要阻塞的想法，这样它就可以比另一个更快地停止发送数据end 可以处理它。即，只需对所有数据使用普通的阻塞 send。