从 NetworkStream 读取。 ReadLine() 与读入 ByteArray 哪个更好?
我正在使用 TcpClient 与以“\n”分隔字符串形式发送信息的服务器进行通信。数据流非常高,一旦设置了通道,流将始终有信息可供读取。消息的大小可以是可变的。
我现在的问题是,使用 ReadLine() 方法从流中读取消息是否更好,因为它们已经用“\n”分隔,或者建议读取某个固定大小的 byteArray 并从中获取消息字符串他们使用 Split("\n") 之类的? (是的,我确实理解,在某些情况下,字节数组可能只获取消息的一部分,我们也必须为此实现逻辑。)
这里需要考虑的点是:
-
性能。< /p>
-
数据丢失。如果客户端读取速度不如数据传入速度,是否会丢失一些数据?数据
- 多线程设置。如果此设置必须在多线程环境中实现,其中每个线程都有单独的通信通道,但会在客户端上共享相同的资源,该怎么办?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
如果性能是您主要关心的问题,那么我更喜欢使用
Read
而不是ReadLine
方法。 I/O 是程序执行速度较慢的事情之一,因此您希望通过预先读取尽可能多的数据来最大限度地减少 I/O 例程的时间。如果您使用 TCP,则数据丢失实际上并不是一个问题。 TCP 协议保证传送并处理导致数据包丢失的拥塞问题。
对于问题的线程部分,我们需要更多信息。共享哪些资源,它们是否共享
TcpClient
等......If Performance is your main concern then I would prefer the
Read
overReadLine
method. I/O is one of the slower things a program can do so you want to minimize the amount of time in I/O routines by reading as much data up front.Data loss is not really a concern here if you are using TCP. The TCP protocol guarantees delivery and will deal with congestion issues that result in lost packets.
For the threading portion of the question we're going to need a bit more information. What resources are shared, are they sharing
TcpClient
's, etc ...如果您需要大量性能,我会说使用缓冲区池并手动进行读取(在套接字上读取())。池化缓冲区将避免生成垃圾,因为我相信 ReadLine() 会生成一些垃圾。
由于您使用的是 TCP,因此数据丢失应该不是问题。
在多线程设置中,您必须具体化,但一般来说,资源共享很麻烦,因为它可能会产生数据竞争。
I would say to go with a pool of buffers and doing reads manually (Read() on the socket), if you need a lot of performance. Pooling the buffers would avoid generating garbage, as I believe ReadLine() will generate some.
Since you're usint TCP, data loss should not be a problem.
In the multi-threaded setup, you will have to be specific, but in general, resource sharing is troublesome as it might generate a data race.
为什么不使用 BufferedStream 确保您以最佳方式从流中读取:
当然,如果您希望扩展,则必须采用异步。因此,
ReadLine
是不可能的,您将回到字节数组操作。Why not use a BufferedStream to ensure you are reading optimally out of the stream:
Of course, if you're looking to scale, going async would be a necessity. As such,
ReadLine
is out of the question and you're back to byte array manipulations.我会读入一个字节数组......唯一的缺点:大小有限。您需要知道某个字节量限制,或者有时手动将字节数组刷新到字节集合中,然后将集合转换回字节数组,还使用 bitConverter 将其转换为字符串,最后将其拆分为真实消息:p
将数组刷新到集合中会产生大量开销...但是,刷新到字符串中将需要更多资源,因为在将字节刷新到字符串中时必须对字节进行解码...所以它是由你决定...你可以选择字符串的简单性或字节的效率,无论哪种方式,它都不会完全提高彼此的性能,但我个人会选择字节集合以避免隐式字节转换。
重要提示:这来自以前的 TCP 套接字使用(Quake RCON 的东西)的个人经验,而不是任何书籍或任何东西:) 如果我错了,请纠正我。
I would read into a byte array.... only downside: limited size. You'd need to know a certain byte amount limit, or flush the byte array into a byte collection manually sometimes, and then transform the collection back into an array of bytes, also transforming it to a string using bitConverter and finally splitting it into the real messages :p
You will have a lot of overhead flushing the array into a collection... BUT, flushing into a string would require more resources, as bytes have to be decoded AS you flush them into the string.... so it's up to you... you can choose simplicity with string or efficiency with bytes, either way it wouldnt exactly be a serious performance boost from each other, but i'd personally go with the byte collection to avoid the implicit byte conversion.
Important: This comes from personal experience from previous TCP socket usage (Quake RCON stuff), not any book or anything :) Correct me if im mistaken please.