Чтение из NetworkStream. Что лучше ReadLine () по сравнению с Read в ByteArray?

Question

Я использую TcpClient для связи с сервером, который отправляет информацию в виде строк с разделителями "\ n".Поток данных довольно высок, и как только канал настроен, поток всегда будет иметь информацию для чтения.Сообщения могут иметь переменные размеры.

Мой вопрос сейчас таков: лучше ли использовать метод ReadLine () для чтения сообщений из потока, так как они уже разделены "\ n", или это будетжелательно читать byteArray некоторого фиксированного размера и собирать строки сообщений из них, используя Split ("\ n") или что-то подобное?(Да, я понимаю, что могут быть случаи, когда байтовый массив получает только часть сообщения, и мы должны были бы реализовать логику для этого тоже.)

Точки, которые необходимо учитывать здесь:

• Производительность.

• Потеря данных.Будут ли потеряны некоторые данные, если клиент не читает так быстро, как поступают данные?

• Многопоточная настройка.Что делать, если эту настройку необходимо реализовать в многопоточной среде, где каждый поток будет иметь отдельный канал связи, но при этом будет использовать одни и те же ресурсы на клиенте.

Answer 1

Если производительность является вашей основной задачей, то я бы предпочел метод Read вместо ReadLine. Ввод / вывод - это одна из самых медленных задач, которые может выполнять программа, поэтому вы хотите минимизировать время, затрачиваемое на процедуры ввода-вывода, читая как можно больше данных.

Потеря данных здесь не особо важна, если вы используете TCP. Протокол TCP гарантирует доставку и будет иметь дело с проблемами перегрузки, которые приводят к потерям пакетов.

Для той части вопроса, которая нужна для многопоточности, нам понадобится немного больше информации. Какими ресурсами делятся, они делятся TcpClient и т.д ...

Answer 2

Я бы прочитал в байтовом массиве .... единственный недостаток: ограниченный размер. Вам нужно будет знать определенный лимит количества байтов или иногда сбрасывать массив байтов в коллекцию байтов вручную, а затем преобразовывать коллекцию обратно в массив байтов, также преобразовывать ее в строку с помощью bitConverter и, наконец, разбивать его на реальные сообщения: p

У вас будет много накладных расходов на очистку массива в коллекцию ... НО, очистка строки потребует больше ресурсов, поскольку байты должны быть декодированы, поскольку вы сбрасываете их в строку .... для вас ... вы можете выбрать простоту со строкой или эффективность с байтами, в любом случае это не будет серьезным повышением производительности друг от друга, но я бы лично пошел с коллекцией байтов, чтобы избежать неявного преобразования байтов.

Важно: Это вытекает из личного опыта предыдущего использования TCP-сокета (Quake RCON), а не какой-либо книги или чего-либо еще :) Исправьте меня, если я ошибаюсь, пожалуйста.

Answer 3

Почему бы не использовать 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 не может быть и речи, и вы вернулись к манипуляциям с байтовым массивом.

Answer 4

Я бы сказал, что нужно идти с пулом буферов и выполнять чтение вручную (Read () в сокете), если вам нужна большая производительность. Объединение буферов позволит избежать генерации мусора, так как я считаю, что ReadLine () будет генерировать некоторые из них.

Поскольку вы используете TCP, потеря данных не должна быть проблемой.

В многопоточной настройке вам нужно быть конкретным, но в целом совместное использование ресурсов проблематично, так как может привести к гонке данных.