我有点困惑，我应该如何使用TCP数据流在.NET。 现在，当我想写可以说40bytes我把它写入一个MemoryStream然后调用的ToArray（）和写入的MemoryStream到的NetworkStream +齐平。

I am a little confused as to how i should use tcp streams in .net. Right now when i want to write lets say 40bytes i write it to a memorystream then call ToArray() and write the memorystream to networkstream + flush.

在服务器端我用读（BUF，0，len个），并检查长度正好是如我所料。我这样做的愚蠢的方式吗？我可以写，因为我希望尽可能少的字节，当二是随时阅读只是冲水？

On serverside i use Read(buf, 0, len) and check if the length is exactly as i expect. Am i doing this in a silly way? Can i write as little bytes as i want and just flush when i i am ready to read?

当我阅读（）将我总是得到的长度我期待？ （假设程序是正确的，并没有发生错误），它会阻塞，直到我的尺寸是准备好了？我不需要循环读取和建立我的缓冲区是吧？可以说，我很期待大尺寸像10k或更高，我会再需要建立我的缓冲？

When i Read() will i ALWAYS get the length i expect? (assuming the app is correct and no error has occured) Will it block until my size is ready? I dont need to loop over read and build my buffer do i? lets say i am expecting a large size like 10k or higher would i then need to build my buffer?.

推荐答案

我知道，无论previous答案告诉你，但我会重复他们，并添加一些雷：如果有足够的时间之间的后续发，它的工作就像你期望的那样，这可能会导致你相信它确实工作方式。但事实并非如此。

I know that both previous answers are telling you that, but I'll repeat them and add something mine: if there is enough time between subsequent sends, it will work just as you expect, that might lead you to believe that it really DOES work that way. But it doesn't.

TCP很容易想象为水管，你是用杯水一端填补。加水新的玻璃不告诉你它的大小事情，只是增加了更多的水管道。

TCP is easily visualized as a WATER PIPE that you are filling with glasses of water on one end. Adding new glass of water doesn't tell you anything about it's size, just adds more water to the pipe.

所以，你需要实现自己的消息或打包的激流。

So, you'll need to implement your own 'messaging' or 'packeting' in the stream.

不过，这并不坏。流是稳健，所以如果你preFIX您的数据，其长度，你就可以得到它的工作 - 只是创建了接收端的某种包收集机制 - 有一些缓冲，将持有的部分分组数据直到你得到你需要的一切。

However, it's not that bad. Stream is ROBUST so if you prefix your data with its length, you'll be able to get it working - just create some kind of 'packet gathering mechanism' on the receiving end - have some buffer that will hold partial packet data until you get everything you need.

编辑：

要通过你的问题：

同花顺（）在这里无关紧要。 您不会得到你所期望的大小。你会得到什么在0范围内无论是留在中转 也不会封锁，直到你的尺寸已准备就绪。因为它有它会让你尽可能多（0是可能） - 我认为，这种行为是可以改变的，但它不会再次字节数写（） N于另一端 您需要建立你的缓冲区 是的，你确实需要手动构建的缓冲区，由$ P $其长度pfixing数据 Flush() is irrelevant here. you will NOT get the size you expect. You will get anything in range of 0 to whatever is left in the transit it won't block until your size is ready. It will get you as much as it has (0 is possibility) - I think that that behavior can be changed, but it doesn't again have anything with number of bytes Write()n on other end you need to build your buffer and yes, you really need to build your buffer manually, by prefixing your data with its length

在这里，你对如何读缓冲的一些想法：.NET阻塞读取插槽，直至X字节可用？

Here, you have some ideas on how to read the buffer: .NET blocking socket read until X bytes are available?