Передача по UDP числа и массива в одном пакете

@Sanuch89 · Регистрация: 04.08.2011

Студворк — интернет-сервис помощи студентам

Здравствуйте. Я в С++ новичок. Задача следующая: нужно передать по UDP пакет в котором первые 4 байта было бы число указывающие на кол-во записей в массиве (4 байта т. к. int), а потом шел массив структур.
Вот, например, есть у меня структура:

C++
1
2
3
4
struct DIAG_DATE
{   int Day;
    int Month;
    int Year;};

Создаю массив таких структур

C++
1
struct DIAG_DATE mas[10];

После заполнения массива, а хочу передать его по UDP:

C++
1
sendto(sSocket,(char *)mas, sizeof(mas), 0, (struct sockaddr *)&servaddr, sizeof(servaddr));

Как вместить в начало пакета число int?
Заранее спасибо.

@vxg · 07.08.2012, 16:59

Сообщение от villu

сериализацию

раз вспомнил - глаголь

g_u_e_s_t · 07.08.2012, 17:40

А еще почему-то никто не сказал, что это нафиг не нужно...
т.к. если дейтаграмма вылезет за размер MTU по дороге, ее порежут, а собрать обратно число элементов массива нам ни чем не поможет. А если доедет целиком/соберем c MSG_WAITALL, то размер массива тупо вычисляется по длине принятого пакета.
Или, что эту структуру нужно "паковать" в 1 int32_t

@vxg · 08.08.2012, 09:24

дейтаграмму не могут порезать (если у нее выставлен соответствующий флаг) - ее могут просто убить с возвратом кода ошибки "не могу фрагментировать".
http://www.soslan.ru/tcp/tcp11.html#t118000
поэтому ее размер не должен превышать разумных пределов зависящих от используемого программного и аппаратного обеспечения. однако даже если ее порежут (может даже и не раз по пути ее следования) сборка будет произведена автоматически в пункте назначения. безусловно чем сильнее режут тем больше вероятность того, что будет потерян кусок и дейтаграмма будет убита. поэтому не нужно слать дейтаграммы размером в терабайт. размер может быть вычислен, вы правы.

g_u_e_s_t · 08.08.2012, 09:41

Сообщение от vxg

дейтаграмму не могут порезать (если у нее выставлен соответствующий флаг) - ее могут просто убить с возвратом кода ошибки "не могу фрагментировать".

Выбирайте:
#cisco
access-list 111 remark clear df bit for this traffic
#pf
scrub in on em0 all no-df

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

@CheshireCat · 08.08.2012, 09:52

Сообщение от vxg

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

Совершенно верно.
В результате получится всего-навсего собственная реализация уже существующего протокола TCP. Этакий самодельный велосипед, только "с нестирающимися шинами из полиструктурного волокна с вырожденными аминными связями и неполными кислородными группами, и с регенерирующим реактором на субтепловых нейтронах." (с) Оно кому-нибудь надо?

@vxg · 08.08.2012, 11:25

CheshireCat, на самом деле нормальный велосипед. у меня через UDP крутилось получение данных от S7-400 на компьютер - наверх шло только обновление данных с отметками времени, потеря пакета (отсутствие подтверждающего пакета со стороны компьютера) приводила к тому что контроллер не ставил у себя отметку о том, что данные на компьютере обновлены. при запуске компьютер сбрасывал отметки обновления для всех тегов. каждый цикл данные без отметки обновления передавались на компьютер. в каждом пакете была информация по недробному количеству тегов, поэтому сборка не требовалась - компьютер просто писал группы "значение, качество, отметка времени" в ячейку с соответствующим индексом. UDP давал скорость и отсутствие проблем с соединением - программа могла не задумываться о разрывах и повторных коннектах - если был сбой (а он был бы и в TCP) просто не доходил пакет. когда магнитная буря проходила связь сама налаживалась без дополнительной обработки.

@CheshireCat · 08.08.2012, 11:35

О! Вот в этом-то и вся соль: "если был сбой - просто не доходил пакет". Если ситуация потери пакета не критична для приложения - то UDP самое то.

Новые блоги и статьи Все статьи Все блоги /
Запустил конкурс "тем и промптов для текстовых квестов созданных почти чисто ИИ" Adler 06.10.2026 Всем привет! За последние три-четыре дня я создал более 16 текстовых квестовых игр используя преимущественно по одному запросу к ИИ на игру. Мне так понравилось смотреть все ветки/ сцены во всех. . .	ИИ не может найти нужный язык в списке Supersumestria 05.10.2026 Я ему даю вот такое изображение и прошу найти и подчеркнуть немецкий язык. Возвращает он вот это: https:/ / i. **********/ vqBWLe2. png Нужную строчку в 3й колонке просто выдумал. . Это. . .	Новая последняя моя музыка в SUNO zorxor 05.10.2026 Здравствуйте, дорогие мои друзья! С большой радостью я хотел бы представить вам свою новую последнею музыку, которую сгенерировала мне по моей просьбе нейросеть SUNO. С уважением, zorxor. Это. . .	Nekobox - outbounds[0].transport: unknown transport type: raw damix 01.10.2026 Фикс ошибки Правым кликом по серверу -> отладочная информация -> edit Заменить "net": "raw", на "net": "tcp", Нажать кнопку reload.
Программный домашний кинотеатр russiannick 27.09.2026 Сподобился на программный домашний кинотеатр. В качестве ЯВУ по традиции выбрал js. В помощники взял Яндекс-Алису. Было создано три зала на разные интересы. исторические и ретро сериал Хичкок. . .	Беседа с ИИ о программистах, недопускающих к созданию и правке кода генеративные ИИ и причины этого zorxor 21.09.2026 Раньше я радовался или получал некоторые эмоции, пусть небольшие, но всё же, от самого процесса написания кода, рекомпиляции и запуска, видя постепенное развитие программы и прочее. А теперь лень. . .	Мобильное приложение ColorStep pavlinmavlin 17.09.2026 Реализовал приложение Красный, Зеленый, Синий в Unity3d + c#. Название изменил на ColorStep. Приложение прошло модерацию и теперь доступно для скачивания. Делал его сам, шаг за шагом — и вот,. . .	Запрет дублирования строк в табличной части Maks 13.09.2026 Реализация из решения ниже выполнена на нетиповом справочнике "Нормы ТО" с табличной часть "Виды ТО", разработанного в КА2, со следующими реквизитами: - ВидТО (СправочникСсылка. ВидыТО); - ВидГСМ. . .

g_u_e_s_t 1259 / 650 / 44 Регистрация: 06.02.2011 Сообщений: 1,654
	07.08.2012, 17:40
	А еще почему-то никто не сказал, что это нафиг не нужно... т.к. если дейтаграмма вылезет за размер MTU по дороге, ее порежут, а собрать обратно число элементов массива нам ни чем не поможет. А если доедет целиком/соберем c MSG_WAITALL, то размер массива тупо вычисляется по длине принятого пакета. Или, что эту структуру нужно "паковать" в 1 int32_t 1

@vxg Модератор 3410 / 2182 / 354 Регистрация: 13.01.2012 Сообщений: 8,476
	08.08.2012, 09:24
	дейтаграмму не могут порезать (если у нее выставлен соответствующий флаг) - ее могут просто убить с возвратом кода ошибки "не могу фрагментировать". http://www.soslan.ru/tcp/tcp11.html#t118000 поэтому ее размер не должен превышать разумных пределов зависящих от используемого программного и аппаратного обеспечения. однако даже если ее порежут (может даже и не раз по пути ее следования) сборка будет произведена автоматически в пункте назначения. безусловно чем сильнее режут тем больше вероятность того, что будет потерян кусок и дейтаграмма будет убита. поэтому не нужно слать дейтаграммы размером в терабайт. размер может быть вычислен, вы правы. 0

@vxg Модератор 3410 / 2182 / 354 Регистрация: 13.01.2012 Сообщений: 8,476
	08.08.2012, 11:25
	CheshireCat, на самом деле нормальный велосипед. у меня через UDP крутилось получение данных от S7-400 на компьютер - наверх шло только обновление данных с отметками времени, потеря пакета (отсутствие подтверждающего пакета со стороны компьютера) приводила к тому что контроллер не ставил у себя отметку о том, что данные на компьютере обновлены. при запуске компьютер сбрасывал отметки обновления для всех тегов. каждый цикл данные без отметки обновления передавались на компьютер. в каждом пакете была информация по недробному количеству тегов, поэтому сборка не требовалась - компьютер просто писал группы "значение, качество, отметка времени" в ячейку с соответствующим индексом. UDP давал скорость и отсутствие проблем с соединением - программа могла не задумываться о разрывах и повторных коннектах - если был сбой (а он был бы и в TCP) просто не доходил пакет. когда магнитная буря проходила связь сама налаживалась без дополнительной обработки. 0

@CheshireCat 2924 / 1274 / 114 Регистрация: 27.05.2008 Сообщений: 3,465
	08.08.2012, 11:35
	О! Вот в этом-то и вся соль: "если был сбой - просто не доходил пакет". Если ситуация потери пакета не критична для приложения - то UDP самое то. 0