Передача UDP и поддержание порядка байтов в сети

0

Поэтому у меня возникли проблемы с отправкой и получением пользовательского пакета через клиент-серверную программу в C++. Я реализовал что-то подобное с использованием TCP, однако у меня возникают проблемы с преобразованием всего в единую дейтаграмму при использовании UDP.

В настоящее время у меня есть заголовок, состоящий из четного числа полей uint32_t. Каждый из них хранится в сетевом порядке, например, в структуре заголовка:

 uint32_t x = htonl (int y);

...

И я комбинирую заголовок с полезной нагрузкой в пакете следующим образом:

 typedef struct {
    450Header header; // 512 bytes consisting of the unint32_t like above
    char data[ BLOCKSIZE ];  // 3.5k
    // Total Packet Size = 4k
} Packet;

'

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

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

  2. Если все правильно упорядочено из вопроса 1, нужно ли его снова конвертировать на принимающей стороне обратно в адрес хоста?

  3. У меня есть функция mmap, которая загружает файл в буфер символов, могу ли я просто скопировать этот фрагмент в буфер данных в пакете, используя что-то вроде memcpy и увеличивая смещение? Или мне также нужно беспокоиться о сетевом порядке для данных полезной нагрузки?

  4. Нужно ли использовать контрольную сумму для полезной нагрузки? И как это сделать, если он не использует весь буфер и заканчивается нечетным количеством байтов?

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

Теги:
networking
sockets
udp

1 ответ

5

8-битные данные (включая 8-битные целые числа, строки Ansi/UTF-8 и т.д.) Не страдают от проблем с порядком байтов, поэтому вы можете отправлять/получать их как есть. Это всего лишь многобайтовые данные (например, 16 бит/32-битные целые числа, 16-битные строки UCS2/UTF-16 и т.д.), Которые вы должны иметь дело с порядком байтов. Например, целые числа всегда должны быть в сетевом порядке байтов, но строки UTF-16 могут использовать UTF-16LE или UTF-16BE по вашему усмотрению (хотя вместо этого вы должны использовать UTF-8).

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

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

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

Ещё вопросы

Сообщество Overcoder
Наверх
Меню