1

我从 QLocalSocket 读取超过 2048 个字节时遇到问题。这是我的服务器端代码：

clientConnection->flush();  // <-- clientConnection is a QLocalSocket

QByteArray block;
QDataStream out(&block, QIODevice::WriteOnly);

out.setVersion(QDataStream::Qt_5_0);
out << (quint16)message.size() << message;  // <--- message is a QString

qint64 c = clientConnection->write(block);
clientConnection->waitForBytesWritten();
if(c == -1)
    qDebug() << "ERROR:" << clientConnection->errorString();

clientConnection->flush();

这就是我在客户端读取数据的方式：

QDataStream in(sock);  // <--- sock is a QLocalSocket
in.setVersion(QDataStream::Qt_5_0);

while(sock->bytesAvailable() < (int)sizeof(quint16)){
    sock->waitForReadyRead();
}
in >> bytes_to_read; // <--- quint16

while(sock->bytesAvailable() < (int)bytes_to_read){
    sock->waitForReadyRead();
}

in >> received_message;

客户端代码连接到readyRead信号，并在第一次调用插槽后断开连接。

为什么我只能读取 2048 个字节？

==编辑==

回复后peppe我更新了我的代码。这是它现在的样子：

服务器端代码：

clientConnection->flush();

QByteArray block;
QDataStream out(&block, QIODevice::WriteOnly);

out.setVersion(QDataStream::Qt_5_0);

out << (quint16)0;
out << message;
out.device()->seek(0);
out << (quint16)(block.size() - sizeof(quint16));
qDebug() << "Bytes client should read" << (quint16)(block.size() - sizeof(quint16));

qint64 c = clientConnection->write(block);
clientConnection->waitForBytesWritten();

客户端代码：

QDataStream in(sock);
in.setVersion(QDataStream::Qt_5_0);

while(sock->bytesAvailable() < sizeof(quint16)){
    sock->waitForReadyRead();
}

quint16 btr;
in >> btr;

qDebug() << "Need to read" << btr << "and we have" << sock->bytesAvailable() << "in sock";
while(sock->bytesAvailable() < btr){
    sock->waitForReadyRead();
}

in >> received_message;

qDebug() << received_message;

我仍然无法读取更多数据。

4

1 回答 1

1 
out.setVersion(QDataStream::Qt_5_0);
out << (quint16)message.size() << message;  // <--- message is a QString

这是错误的。“消息”的序列化长度将是 message.size() * 2 + 4 个字节，因为 QString 将自己的长度作为 quint32 前置，并且每个 QString 字符实际上是一个 UTF-16 代码单元，因此它需要 2 个字节。仅期望在阅读器中读取 message.size() 字节将导致 QDataStream 短读取，这是未定义的行为。

请在这些行之后检查“块”的大小——它将是 2 + 4 + 2 * message.size() 字节。所以你需要修正数学。您可以放心地假设它不会改变，因为 Qt 数据类型的序列化格式是已知的并已记录在案。

不过，我确实认识到添加长度的“设计模式”。它可能来自 Qt 附带的财富网络示例。显着的区别是该示例没有在 UTF-16 代码单元中添加字符串的长度（这是没有意义的，因为它不是序列化的方式）——它预先添加了序列化QString 的长度。看看它做了什么：

    out << (quint16)0;
    out << fortunes.at(qrand() % fortunes.size());
    out.device()->seek(0);
    out << (quint16)(block.size() - sizeof(quint16));

首先，它在输出中保留一些空间，方法是写一个0. 然后它序列化一个QString。然后它回溯并0用序列化 QString 的长度覆盖 ——此时，恰好是 block.size() 减去说明长度的前置整数（我们知道quint16 的序列化长度是sizeof(quint16)）

重复我自己，实际上有两个原因说明为什么该示例以这种方式编码，并且它们在某种程度上是相关的：

  1. QDataStream 无法从短读取中恢复：当您使用反序列化对象时，它成功解码对象所需的所有数据都必须可用operator>>。因此，在确定收到所有数据之前，您不能使用它。这使我们：
  2. TCP 没有内置机制来分离“记录”中的数据。您不能只发送一些字节后跟一个“记录标记”，它告诉接收者他已收到与记录相关的所有数据。TCP 提供的是原始字节流。最终，您可以（半）关闭连接以向其他对等方发出传输结束的信号。

1+2 意味着您必须使用其他机制来了解（在接收方）您是否已经拥有所需的所有数据，或者您必须等待更多数据。例如，您可以引入带内标记\r\n（如 IRC 或 - 在一定程度上 - HTTP 做）。

财富示例中的解决方案是在“实际”数据（带有财富消息的序列化 QString）之前添加该数据的长度（以字节为单位）；然后它发送长度（作为 16 位整数），后跟数据本身。

接收端先读取长度；然后它读取了那么多字节，然后它知道它可以解码命运。如果没有足够的可用数据（无论是长度 - 即您收到少于 2 个字节 - 以及有效负载本身），客户端就什么也不做，等待更多。

注意：

  • 设计并不新鲜：这是所有大多数协议所做的。在“标准”TCP/IP 堆栈中，TCP、IP、以太网等在其“标头”中都有一个字段，用于指定有效负载（或整个“记录”）的长度；
  • “长度”的传输使用以特定字节顺序发送的 16 位无符号整数：它不是 memcpy()d 进入缓冲区，而是使用 QDataStream 来存储它并读回它。尽管看起来微不足道，但这实际上完成了您正在使用的协议的定义。
  • 如果 QDataStream 能够从短读取中恢复（通过抛出异常并将数据留在设备中），则您不需要发送有效负载的长度，因为 QDataStream已经发送了字符串的长度（作为32 位无符号 bigendian 整数）后跟 UTF-16 字符。
于 2013-02-12T15:33:16.010 回答