Обработка потоков TCP

Question

Наш сервер работает на пакетной основе.Это адаптация от старой последовательной системы.Он был добавлен, изменен, перестроен и т. Д. За эти годы.Поскольку TCP является потоковым протоколом, а не пакетным протоколом, иногда пакеты разбиваются.ServerSocket разработан таким образом, что когда Клиент отправляет данные, часть данных содержит размер нашего сообщения, например 55.Иногда эти пакеты делятся на несколько частей.Они поступают по порядку, но поскольку мы не знаем, как сообщения будут разделены, наш сервер иногда не знает, как определить разделенное сообщение.

Итак, предоставив вам справочную информацию.Каков наилучший метод для восстановления пакетов по мере их поступления, если они разделены?Мы используем C ++ Builder 5 (да, я знаю, старая IDE, но это все, с чем мы можем работать в данный момент. МНОГО работы по редизайну в .NET или более новой технологии).

Answer 1

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

При этом вы можете просто добавить все входящие данные в буфер. Затем проверьте, содержит ли ваш буфер один или несколько пакетов, и удалите их из буфера, сохранив все оставшиеся данные в буфере для последующей проверки.

Это, конечно, предполагает, что ваши пакеты имеют некоторый заголовок, который указывает размер следующих данных.

Давайте рассмотрим пакеты, имеющие следующую структуру:

[LEN] X X X...

Где LEN - размер данных, а каждый X - байт.

Если вы получаете:

4 X X X
[--1--]

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

4 X X X X 3 X X X
        [---2---]

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

Если вы это сделаете, не забудьте отправить любую длину в независимой от хоста форме (ntohs и ntohl могут помочь).

Answer 2

Это часто достигается путем добавления к сообщениям префикса длиной в один или два байта, которые, как вы сказали, дают длину оставшихся данных. Если я вас правильно понял, вы отправляете это в виде обычного текста (то есть «5», «5»), и это может быть разбито на части. Поскольку вы не знаете длину десятичного числа, это несколько двусмысленно. Если вам абсолютно необходимо , чтобы использовать простой текст, , возможно, вы могли бы закодировать длину как 16-битное шестнадцатеричное значение, т.е.

00ff <255 байтов данных> 000a <10 байтов данных>

Таким образом, длина заголовка размера фиксируется на 4 байта и может использоваться как минимальная длина чтения при получении на сокете.

---

Редактировать: Возможно, я неправильно понял - если чтение значения длины не является проблемой, справьтесь с разбиениями, объединяя входящие данные в строку, байтовый буфер или что-то еще, пока его длина не станет равной значению, которое вы прочитали в начале , TCP позаботится обо всем остальном.

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

Answer 3

Я хотел бы иметь функцию readBytes или что-то, что принимает буфер и параметр длины и читает до тех пор, пока не будет прочитано столько байтов.Вам нужно будет зафиксировать количество фактически прочитанных байтов, и, если оно меньше ожидаемого, увеличьте указатель буфера и прочитайте остальные.Продолжайте зацикливаться, пока не прочитаете их все.

Затем вызовите эту функцию один раз для заголовка (содержащего длину), предполагая, что заголовок имеет фиксированную длину.Получив длину фактических данных, снова вызовите эту функцию.