为什么特定的UDP消息总是被丢弃到特定的缓冲区大小以下？

Question

3种不同的消息以不同的速率发送到同一端口：

消息 大小（字节）以 每种 传输速度发送
高 232 10 ms 100Hz
中 148 20ms 50Hz
低 20 60 ms 16.6Hz

我每〜6毫秒只能处理一条消息。
单线程。 阻止读取。

---

发生一种奇怪的情况，我对此没有任何解释。
当我将接收缓冲区设置为4,799字节时，所有低速消息都会被丢弃。
我看到可能要处理一两个，然后什么也没有。

当我将接收缓冲区设置为4,800 （或更高！）时，似乎所有低速消息都开始得到处理。 我看到大约每秒16/17。

---

一直观察到这一点。 发送数据包的应用程序始终在接收应用程序之前启动。 在创建套接字之后以及开始处理之前，接收应用程序始终会有很长的延迟。 因此，在处理开始时，缓冲区始终是满的，并且每次进行测试时，缓冲区都不相同。 这是因为套接字是在发送方已经发送完消息之后创建的，因此接收方可能会在发送周期的中间开始侦听。

为什么增加接收缓冲区的大小一个字节，导致低速消息处理发生巨大变化？

我建立了一个表格，以更好地可视化预期的处理过程：

随着这些消息中某些消息的处理，可能会有更多消息放入队列中而不是被丢弃。

尽管如此，我希望4,799字节的缓冲区的行为与4,800字节相同。

但是，那不是我所观察到的。

---

我认为问题与以下事实有关：低速消息与其他两个消息同时发送。 总是在高速/中速消息之后接收到它。 （这已通过Wireshark确认）。

例如，假设缓冲区从头开始是空的，很明显低速消息需要比其他消息更长的排队时间。
*每6ms 1条消息大约每30ms 5条消息。

这仍然不能解释缓冲区的大小。

我们正在运行VxWorks，并使用其sockLib（这是Berkeley套接字的实现）。 以下是我们的套接字创建内容的摘要：
SOCKET_BUFFER_SIZE是我要更改的内容。

struct sockaddr_in tSocketAddress;                          // Socket address
int     nSocketAddressSize = sizeof(struct sockaddr_in);    // Size of socket address structure
int     nSocketOption = 0;

// Already created
if (*ptParameters->m_pnIDReference != 0)
    return FALSE;

// Create UDP socket
if ((*ptParameters->m_pnIDReference = socket(AF_INET, SOCK_DGRAM, 0)) == ERROR)
{
    // Error
    CreateSocketMessage(ptParameters, "CreateSocket: Socket create failed with error.");

    // Not successful
    return FALSE;
}

// Valid local address
if (ptParameters->m_szLocalIPAddress != SOCKET_ADDRESS_NONE_STRING && ptParameters->m_usLocalPort != 0)
{
    // Set up the local parameters/port
    bzero((char*)&tSocketAddress, nSocketAddressSize);
    tSocketAddress.sin_len = (u_char)nSocketAddressSize;
    tSocketAddress.sin_family = AF_INET;
    tSocketAddress.sin_port = htons(ptParameters->m_usLocalPort);

    // Check for any address
    if (strcmp(ptParameters->m_szLocalIPAddress, SOCKET_ADDRESS_ANY_STRING) == 0)
        tSocketAddress.sin_addr.s_addr = htonl(INADDR_ANY);
    else
    {
        // Convert IP address for binding
        if ((tSocketAddress.sin_addr.s_addr = inet_addr(ptParameters->m_szLocalIPAddress)) == ERROR)
        {
            // Error
            CreateSocketMessage(ptParameters, "Unknown IP address.");

            // Cleanup socket
            close(*ptParameters->m_pnIDReference);
            *ptParameters->m_pnIDReference = ERROR;

            // Not successful
            return FALSE;
        }
    }

    // Bind the socket to the local address
    if (bind(*ptParameters->m_pnIDReference, (struct sockaddr *)&tSocketAddress, nSocketAddressSize) == ERROR)
    {
        // Error
        CreateSocketMessage(ptParameters, "Socket bind failed.");

        // Cleanup socket
        close(*ptParameters->m_pnIDReference);
        *ptParameters->m_pnIDReference = ERROR;

        // Not successful
        return FALSE;
    }
}

// Receive socket
if (ptParameters->m_eType == SOCKTYPE_RECEIVE || ptParameters->m_eType == SOCKTYPE_RECEIVE_AND_TRANSMIT)
{
    // Set the receive buffer size
    nSocketOption = SOCKET_BUFFER_SIZE;
    if (setsockopt(*ptParameters->m_pnIDReference, SOL_SOCKET, SO_RCVBUF, (char *)&nSocketOption, sizeof(nSocketOption)) == ERROR)
    {
        // Error
        CreateSocketMessage(ptParameters, "Socket buffer size set failed.");

        // Cleanup socket
        close(*ptParameters->m_pnIDReference);
        *ptParameters->m_pnIDReference = ERROR;

        // Not successful
        return FALSE;
    }
}

然后套接字接收在无限循环中被调用的信息：
*缓冲区大小绝对足够大

int SocketReceive(int nSocketIndex, char *pBuffer, int nBufferLength)
{
    int nBytesReceived = 0;
    char szError[256];

    // Invalid index or socket
    if (nSocketIndex < 0 || nSocketIndex >= SOCKET_COUNT || g_pnSocketIDs[nSocketIndex] == 0)
    {
        sprintf(szError,"SocketReceive: Invalid socket (%d) or ID (%d)", nSocketIndex, g_pnSocketIDs[nSocketIndex]);
        perror(szError);
        return -1;
    }

    // Invalid buffer length
    if (nBufferLength == 0)
    {
        perror("SocketReceive: zero buffer length");
        return 0;
    }

    // Send data
    nBytesReceived = recv(g_pnSocketIDs[nSocketIndex], pBuffer, nBufferLength, 0);

    // Error in receiving
    if (nBytesReceived == ERROR)
    {
        // Create error string
        sprintf(szError, "SocketReceive: Data Receive Failure: <%d> ", errno);

        // Set error message
        perror(szError);

        // Return error
        return ERROR;
    }

    // Bytes received
    return nBytesReceived;
}

关于为什么将缓冲区大小增加到4,800会导致成功且一致地读取低速消息的任何线索？

Answer 1

为什么SO_RCVBUF大小为4799会导致丢失低速消息而大小为4800的问题的基本答案是，在UDP数据包混合进来，它们进入的速率， vxWorks内核中的mbuff和群集号的大小mbuff来处理传入的数据包，并具有足够的网络堆栈吞吐量，从而不会丢弃较大尺寸的低速消息。

上面注释中提到的URL http://www.vxdev.com/docs/vx55man/vxworks/ref/sockLib.html#setsockopt中的setsockopt()手册页中的SO_SNDBUF选项说明中，此内容涉及指定的大小以及对mbuff使用的影响：

设置缓冲区的最大大小（对于SO_SNDBUF和SO_RCVBUF，如下所述）的影响实际上并不是从mbuf池中分配mbuf。 相反，其效果是在协议数据结构中设置了高水位标记，稍后将其用于限制mbuf分配量。

UDP数据包是离散单元。 如果您发送10个大小为232的数据包，则该数据包不被视为连续内存中的2320字节数据。 相反，它是网络堆栈中的10个内存缓冲区，因为UDP是离散数据包，而TCP是连续的字节流。

请参阅如何在VxWorks 5.4中调整网络缓冲？ 在DDS社区网站上，该站点讨论了mbuff大小和网络群集混合的相互依赖性。

请参阅如何解决VxWorks缓冲区问题？ 在DDS社区网站上。

请参阅此幻灯片演示文稿的PDF，这是2004年以来VxWorks中研究网络堆栈耗尽的新工具 ， 该工具讨论了使用mBufShow和inetStatShow等各种工具来查看网络堆栈中发生的情况。

Answer 2

如果不对发送UDP消息的路径上的每个网络堆栈实现进行详细分析，则几乎不可能说明所产生的行为。

允许UDP实现自行决定丢弃任何数据包。 通常，当堆栈得出以下结论时，就会发生这种情况：必须丢弃数据包才能接收新数据包。 没有正式的要求，丢弃的数据包是最旧的或最新的。 也可能是由于内部内存管理策略影响了某个大小的类。

从涉及的IP堆栈中，最有趣的是接收计算机上的一个。

当然，如果将接收方更改为一个接收缓冲区，它将花费几秒钟的预期消息，从而获得更好的接收体验。 我将从至少1万开始。

从4799变为4800时，观察到的行为“变化”可能是由于后者只是允许小消息之一在需要再次丢弃之前被接收而引起的，而较小的大小只是导致它稍早被丢弃。 如果接收应用程序足够快地读取未决消息，则在一种情况下，您将收到小消息，而在另一种情况下，您将收到小消息。