Контроль отправки данных по сети

Использовать только всякие uint32_t и подобные типы. Использовать упаковку структур. Иначе слишком много вариантов.

magicNumberBegin и magicNumberEnd uint32_t в программе.
Структура - большая строка (~60 килобайт).

Отправка/получение средствами Qt.

Если TCP то норм. Главное проверить, что реально ушло 60к и принято 60к. Ну и про выравнивание/упаковку уже сказали

magic нужен чтобы сразу завершить чтение не пытаясь как-то дальше интерпретировать структуру, ~ простая защита от неправильного клиента. Для проверки целостности пакета нужно использовать какую-нибудь контрольную сумму, закрывающий magicNumber бесполезен. Вместо простого magic есть смысл сделать хедер из {magic, version, size} и только потом уже гнать структуру размером size.

Посмотри как устроены IP пакеты (IP header format) . Если порядок байт значения не имеет, то можно применить pragma pack https://habrahabr.ru/post/142662/ и маппить через указатель просто. Вообще тебе не нужен magicNumberEnd, лучше вместо него добавить контрольную сумму в заголовок, если боишься проблем с потерей данных и т.п.

Можешь ещё Crc32 добавить

magicNumberBegin и magicNumberEnd uint32_t в программе.
Структура - большая строка (~60 килобайт).

Это всё круто, но что будет, если у тебя в данных встретится твоё magicNumberEnd? Большие мальчики и девочки передают размер перед собственно данными.

Там работает QDataStream. Я не вручную распаковываю.

Большие мальчики и девочки передают размер перед собственно данными.

Так нормально будет?

stream << magicNumberBegin << sizeof(struct) << struct;

//client

read(stream);
stream >> magicNumberBeginTmp >> sizeTMP>>  struct;
if (magicNumberBeginTmp == magicNumberBegin && sizeTMP == sizeof(struct) {
    // OK
} else { 
    //fail
}

Неправильно. Зачем надеяться на какие-то маркеры, когда достаточно использовать формат, не допускающий некорректного парсинга?

static uint32_t version = 2;
stream << version << struct;

uint32_t version;
stream >> version;
if (version == 2) {
    stream >> struct;
} else if (version == 1) {
    stream >> legacy_v1_struct;
    struct = struct::from_legacy_v1(legacy_v1_struct);
} else {
    throw std::runtime_error("Bad protocol version");
}

Или использовать протоколы которые сами заботятся о совместимости, типа protobuf.

Вопрос: правильно ли я делаю?

Нет.

Если нет, какие предложение будут?

Использовать CRC.

Лол, а если у тебя половину структуры обрежет, а в данных следующей структуры встретится твой маркер?

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

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

Ещё один. TCP-то тут причем, болезный? Он потоковый.

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

неа, не так, если получатель не отправит обратно пришедшую посылку, только так можно 100% гарантировать доставку инфы. можно полумерами, кидаться хешами

да, но вероятность коллизии контрольной достаточно суммы мала, и так сойдет

неа, не так, если получатель не отправит обратно пришедшую посылку, только так можно 100% гарантировать доставку инфы.

Обратная посылка тоже может испортиться сформировав правильные данные, 100%-го метода защиты не существует.

Передавай magic и size. Но от валидации данных это не избавляет.

Вопрос: правильно ли я делаю?

нет

какие предложение будут?

tcp + объявление длины если заранее не известна.

маловероятно, если данные включали crc

вообще я наступал в подобные вещи, очень неприятно когда происходит черти что, а доставка данных должна быть гарантированной

У меня доставка не гарантирована. Если данные не дошли или дошли поврежденными - ничего, клиент еще раз попросит отправить (отправляться актуальные данные, старые уже не будут отправляться).

А если клиент не в курсе, что данные повреждены. Хотя в твоей задаче возможно это не актуально.

Добавил контрольную сумму и размер. Вероятность коллизии небольшая.