Tcp xml связь C#

Question

Мне нужно установить двустороннюю связь по TCP, используя сообщения xml. Каков наилучший способ воспрепятствовать этому? Я не уверен, что сообщения будут заканчиваться на \n. Я подумал об использовании TcpClient.GetStream(), чтении потока byte после byte и проверке, пришло ли полное сообщение xml. Но это звучит так, как будто это можно было бы сделать лучше.

Важно знать:

• Это обычное tcp-общение, без http или вообще без него.
• Связь один на один не похожа на веб-сервер, соединяющийся со многими клиентами
• Как я уже говорил, я не могу быть уверен, что другая сторона завершит сообщение \n

Answer 1

Если я правильно понимаю, вы получили spe c, который указывает, что:

• xml отправляется по TCP, без заголовка или индикатора конца сообщения
• несколько сообщений отправляются по одному и тому же соединению

В этом случае единственный способ выяснить, где заканчивается (действительное) xml сообщение, - это проанализировать его структуру и найти закрывающий элемент узла root. Обработка объявления xml <?xml ...?> как разделителя сообщений не будет надежной, если только гарантированно не будет включен в каждое сообщение xml.

На вашем месте я бы попытайтесь убедить другую сторону в том, что это ненадежный протокол сообщений - все, что требуется, это один поврежденный файл xml (например, без закрывающего элемента), и ваша программа не сможет обработать любое последующее сообщение по этому соединению.

В противном случае я бы использовал XmlReader с ConformanceLevel.Fragment для чтения следующего элемента запуска и использовал его функциональность ReadSubtree() для получения отдельных сообщений. Этот «считыватель поддеревьев» затем может быть передан в XmlDocument.Load() для дальнейшей обработки. XmlReader будет нарушать xml объявлений (<?xml ...?>) для всех сообщений, кроме первого, поэтому вам понадобится TextReader между XmlReader и потоком для их удаления.

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