从 NetworkStream 读取。 ReadLine() 与读入 ByteArray 哪个更好?

发布于 2024-10-05 23:04:39 字数 434 浏览 5 评论 0 原文

我正在使用 TcpClient 与以“\n”分隔字符串形式发送信息的服务器进行通信。数据流非常高,一旦设置了通道,流将始终有信息可供读取。消息的大小可以是可变的。

我现在的问题是,使用 ReadLine() 方法从流中读取消息是否更好,因为它们已经用“\n”分隔,或者建议读取某个固定大小的 byteArray 并从中获取消息字符串他们使用 Split("\n") 之类的? (是的,我确实理解,在某些情况下,字节数组可能只获取消息的一部分,我们也必须为此实现逻辑。)

这里需要考虑的点是:

  • 性能。< /p>

  • 数据丢失。如果客户端读取速度不如数据传入速度,是否会丢失一些数据?数据

  • 多线程设置。如果此设置必须在多线程环境中实现,其中每个线程都有单独的通信通道,但会在客户端上共享相同的资源,该怎么办?

I am using TcpClient to communicate with a server that sends information in form of "\n" delimited strings. The data flow is pretty high and once the channel is set, the stream would always have information to read from. The messages can be of variable sizes.

My question now is, would it be better to use ReadLine() method to read the messages from the stream as they are already "\n" delimited, or will it be advisable to read byteArray of some fixed size and pick up message strings from them using Split("\n") or such? (Yes, I do understand that there may be cases when the byte array gets only a part of the message, and we would have to implement logic for that too.)

Points that need to be considered here are:

  • Performance.

  • Data Loss. Will some data be lost if the client isn't reading as fast as the data is coming in?

  • Multi-Threaded setup. What if this setup has to be implemented in a multi-threaded environment, where each thread would have a separate communication channel, however would share the same resources on the client.

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

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

发布评论

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

评论(4

物价感观 2024-10-12 23:04:40

如果性能是您主要关心的问题,那么我更喜欢使用 Read 而不是 ReadLine 方法。 I/O 是程序执行速度较慢的事情之一,因此您希望通过预先读取尽可能多的数据来最大限度地减少 I/O 例程的时间。

如果您使用 TCP,则数据丢失实际上并不是一个问题。 TCP 协议保证传送并处理导致数据包丢失的拥塞问题。

对于问题的线程部分,我们需要更多信息。共享哪些资源,它们是否共享 TcpClient 等......

If Performance is your main concern then I would prefer the Read over ReadLine 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 ...

绮烟 2024-10-12 23:04:40

如果您需要大量性能,我会说使用缓冲区池并手动进行读取(在套接字上读取())。池化缓冲区将避免生成垃圾,因为我相信 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.

世态炎凉 2024-10-12 23:04:40

为什么不使用 BufferedStream 确保您以最佳方式从流中读取:

var req = (HttpWebRequest)WebRequest.Create("http://www.stackoverflow.com");
using(var resp = (HttpWebResponse)req.GetResponse())
using(var stream = resp.GetResponseStream())
using(var bufferedStream = new BufferedStream(stream))
using(var streamReader = new StreamReader(bufferedStream))
{
    while(!streamReader.EndOfStream)
    {
        string currentLine = streamReader.ReadLine();
        Console.WriteLine(currentLine);
    }
}

当然,如果您希望扩展,则必须采用异步。因此,ReadLine 是不可能的,您将回到字节数组操作。

Why not use a BufferedStream to ensure you are reading optimally out of the stream:

var req = (HttpWebRequest)WebRequest.Create("http://www.stackoverflow.com");
using(var resp = (HttpWebResponse)req.GetResponse())
using(var stream = resp.GetResponseStream())
using(var bufferedStream = new BufferedStream(stream))
using(var streamReader = new StreamReader(bufferedStream))
{
    while(!streamReader.EndOfStream)
    {
        string currentLine = streamReader.ReadLine();
        Console.WriteLine(currentLine);
    }
}

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.

蒲公英的约定 2024-10-12 23:04:40

我会读入一个字节数组......唯一的缺点:大小有限。您需要知道某个字节量限制,或者有时手动将字节数组刷新到字节集合中,然后将集合转换回字节数组,还使用 ​​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.

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