NetworkStream.DataAvailable 是否看到缓冲数据?

发布于 2024-07-07 05:10:30 字数 403 浏览 9 评论 0原文

NetworkStream.DataAvailable 是否知道发送方的发送缓冲区是否为空? 或者只是表明接收方的读缓冲区是否有数据? 我的假设是后者......

具体来说,对于涉及正在进行的对话的某些套接字工作,我目前使用长度前缀,以便接收者确切地知道当前批次中有多少数据; 但是,我收到了一个 .patch,建议我使用 NetworkStream.DataAvailable 代替。 我担心的是,这只会告诉我接收者收到了什么 - 而不是发送者最初发送的内容 - 但我不是套接字专家。

我错了吗? 或者长度前缀是正确的方法?

(请注意,我不能简单地 Read() 直到流关闭,因为在同一个连接上发送多个批次,并且将每个批次视为单独的至关重要;如果我在一个批次中读取太多内容(即使它被缓冲并丢弃)然后对话就会中断)。

Does NetworkStream.DataAvailable know whether the sender's send buffer is empty? Or does it simply indicate whether the receiver's read buffer has data? My assumption is the latter...

Specifically, for some socket work involving an ongoing conversation, I currently use a length-prefix so the the receiver knows exactly how much data is in the current batch; however, I've been sent a .patch suggesting I use NetworkStream.DataAvailable instead. My concern is that this will just tell me what the receiver has got - not what the sender originally sent - but I'm not a sockets expert.

Am I wrong? Or is length-prefix the way to go?

(note I can't simply Read() until the stream is closed, since multiple batches are sent on the same connection, and it is vital that I treat each batch as separate; if I read too much in one batch (even if it gets buffered and discarded) then the conversation will break).

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

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

发布评论

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

评论(2

迷爱 2024-07-14 05:10:30

连接的一侧不会知道另一侧的发送缓冲区是否为空。

DataAvailable仅指示是否有传入数据可供读取。 您可以在 Read() 之前使用它,但它本身并不能提供您想要的信息。 它不会告诉您每批的开始和结束。

我之前已经对来回对话进行了编码,并且在数据中使用了长度前缀。 我所做的就是编写辅助函数来读取确切数量的字节(一次读取块),而不再读取更多字节。

流中批次长度值的唯一替代方法是检查传入数据并识别批次的开始和结束的某种方式。

One side of a connection is not going to know whether the other side's send buffer is empty.

DataAvailable only indicates whether there is incoming data to be read. You could use that prior to Read(), but it alone doesn't give you the information you want. It doesn't tell you the beginning and ending of each batch.

I've coded back-and-forth conversation before, and I used length-prefixes in the data. What I did was write helper functions that read an exact number of bytes (chunks at a time) and no more.

The only alternative to length-of-batch values in the stream is some way of examining the incoming data and recognizing the beginnings and endings of batches.

笨死的猪 2024-07-14 05:10:30

如果您需要知道接收者何时收到特定消息的所有数据,那么您肯定需要长度前缀。

我通常定义一个与此类似的结构,该结构出现在我发送的任何二进制消息的前面。

struct Header
{
  int packetIdentifier;
  int protocolVersion;
  int messageType;
  int payloadSize;
}

该标识符可让您确定您的协议类型是否具有有效的消息。 该版本允许您修改协议。 消息类型是消息的类型(即:CommsOnline)。 有效负载大小是消息正文的大小。

If you are needing to know when the receiver has received all of the data for a particular message then you definitely need to length prefix.

I typically define a struct similar to this that goes out at the front of any binary messages i send.

struct Header
{
  int packetIdentifier;
  int protocolVersion;
  int messageType;
  int payloadSize;
}

The identifier lets you determine if you have a valid message of your protocol type. The version lets you revision your protocol. The message type is the type of message (ie: CommsOnline). The payload size is the size of the body of the message.

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