因此，我最近在.NET Core 2.1套接字服务器中实现了功能强大的System.IO.Pipelines功能。它可以很好地解决“长度问题”，其中必须确保缓冲区足够大以容纳套接字数据。
对我来说，这是一个明显的问题。在唯一的管道使用示例中，我发现\n终止了每条消息，因此PipeReader（一直循环直到找到0xa为止）才将缓冲区“切片”字节0xa。但是，如果我要发送UTF-8字符串，则很有可能0xa是该字符串的前面的长度。因此，该消息将在不完整的地方通过。
我的解决方案是设计协议时使用我所谓的“安全”字节（例如紧接之前/进行中的0x31），以指示真正的消息终止。
在Streams中，我敢说，常规的byte[]缓冲区中，您可以Peek()在下一个字节并检查下一个字节，而无需提前阅读器。但是我很确定System.IO.Pipelines没有这种能力。
我想一种补救方法是在检测到\n时将其切片，并评估结果缓冲区的第一个字节。但这感觉就像打败了很多管道的力量（尽管也许我错了）。