c++ - 微小的传输最终交织在一起，我真的需要解析缓冲区吗？

Question

我正在做一些套接字编程，但遇到了一些小问题。

作为扑克游戏的一部分，我已经为服务器和客户端之间的通信定义了一个协议(protocol)，所以当任何一方想要在远端触发某个 Action 时，它会创建一个整数数组(简单编码)，其中非常第一个 int 是“操作码”，一个简单的代码，详细说明了数据的使用方式以及传输的大小。任何后续的整数都可以被视为该操作的参数(如果适用)，模拟函数调用。

每当客户端连接时，服务器需要做的一件事是通知其他客户端有新玩家加入游戏，因此它会向所有其他客户端发送“新玩家已连接”消息，其中包括该新玩家的 table 号。

当服务尝试快速连续地通知客户端时，就会出现问题，正如我的伪代码将演示的那样。发生的情况是服务器发送两个 8 字节的传输，这些传输在远端作为单个 16 字节(4 个整数)接收。结果是客户端仅传递并使用前 8 个字节，忽略其余字节，导致稍后出现困惑(打印出大量垃圾列表)，例如，未列出的玩家在聊天中说了些什么。

由于我无法显示我的实际代码，请考虑服务器端相关部分的以下伪代码:

enum PROTOCOLENUMS
{
    NOTIFYPROTOCOL = //some number
}

//Reps is simple vector containing custom objects of type playerRepresentation.
for(auto player : Reps)
{
   if (player.getSocketNr() != newfiledescriptor)
   {

       int oldguyInfo[2] = 
       {NOTIFYPROTOCOL,player.getSocketNr() };
       send(newfd,oldguyInfo,sizeof(oldguyInfo),0);
       //the old players are simultaniously notified of the new player here.
   }
}

在客户端，负责接收传输并传递它的代码看起来像这样(省略了错误检查):

short bytecount
while (true)
{
    bytecount = recv(serverSocketDescriptor,buffer,sizeof(buffer),0);
    cout<<bytecount<<endl; //Bytecount should ready 8 every time, instead it will accumulate if recv doesn't get called between sends.
    InterfacePtr->processTransmission(buffer);
}

就像我说的，当接收端的缓冲区将两个(或更多)发送到内部缓存时，问题就出现了，即传输发生得如此之快以至于 recv() 没有及时解锁以刷新第一个在第二个消息到达之前从缓冲区中取出消息。因此只有第一个传输实际上被后续处理函数(即 processTransmission() )使用。

我猜也有可能是服务端出了问题，也就是说底层API认为可以通过将两个小传输打包成一个来节省一些带宽，而不是直接发送。不过这似乎不太可能。

现在，我真正想问的是:我真的必须在每次接收后解析缓冲区以确定是否有不止一组可用的传输吗？

Answer 1

这种事情的正常方法是定义一个协议(protocol)。协议(protocol)是将每条消息作为逻辑单元引入的形式化方式。

某些协议(protocol)(例如 HTTP)使用定界符(例如换行符)来分隔消息的各个部分(以及消息本身)。

在游戏中，使用二进制协议(protocol)更为正常，其中每条消息都以其长度开头。

例如，您可以采用的一种协议(protocol)是每条消息前面都有 4 个字节，对消息长度进行编码。

然后你的读者端看起来像这样:

while(running)
{
    int32_t wire_length = 0;
    recv(fd, &length, sizeof(length), 0);
    auto length = ntohl(wire_length);
    std::vector<uint8_t> buffer(length);
    recv(fd, &buffer[0], length, 0);
    // buffer now contains exactly one message
    // decode and dispatch here
 }