Размер, потом сами данные, опять размер, сами данные

И все, хоть 100 файлов «за раз»

так или иначе придется что-то надстраивать, иначе у сервера не будет достаточно информации для интерпретации переданных байт

условиться о 4 или 8 байтах размера файла и следом самого файла — самый концептуально простой вариант

Да

Да он сейчас "рабочий"  просто ожидал что есть  идеи лутше.

Тем не менее Всем большое спасибо за помощь

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

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

Вопрос по boost::asio, а точнее по strand-ам.
Есть у меня функция

void Foo(const std::function<void(int i)>& cb);

, которая внутри делает некую асинхронную операцию, типа записи в сокет, и потом по завершении этой операции вызывает переданный калбэк.

Предположим, мне надо синхронизировать выполнение cb, используя strand. Насколько я понимаю, чтобы strand сработал, Foo должна сделать strand.post(std::bind(cb, v)). Исходя из этого, я должен помимо cb в Foo передавать ещё и strand, отдельным аргументом.

Так это и делается? или может есть способ при вызове Foo каким-то образом привязать cb к нужному стрэнду, чтобы потом этот калбэк вызвать/запостить где угодно, и strand сработал?

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

Да и как выяснилось в процессе посылатся пока будут сырые видео аудио, в который полно мусора.

Ну по сути да , 1 сокет на файл, это попытка переложить свои проблемы на протокол TCP ;

У вас shadowing привел к ошибке? Было бы любопытно посмотреть пример.

Второй путь и есть самый некостыльный

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

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

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

Стайлгайды не для нас (с)

Кстати в веб сокеты встроены эти разбелители уже в коробке

Егор Соколов has been warned (1/3)

Почему при сборке могут быть проблемы с SEH после оборачивания HANDLE из winapi в класс с деструктором?
Собираю через cmake, MinSizeRel с флагами, которые отключают runtime и оставляют только winapi.

lld-link : error : undefined symbol: __CxxFrameHandler3

Ну, так эта вот функция из рантайма наверняка.
Ты либо не используй SEH, либо используй рантайм (хотя бы в виде статики)

Код: https://pastebin.com/2KYuQSqs
Собираю через clang-cl
Флаги линкера:

/MANIFEST:NO
/MERGE:.rdata=.text
/MERGE:.pdata=.text
/NODEFAULTLIB
/DEBUG:NONE