У меня возник такой вопрос:
Я отсылаю команду серверу (железке), в ответ (как я понял это шесть байт, 4*байт + 1*int16_t) она присылает мне свое состояние в соответствии с протоколом). Но нужно точно знать, что я правильно понял спецификацию и что протокол не изменен. Т.е. что мне передаются именно 6 байт и я именно их и считываю.

Интересуют подходы к тому как можно считать эти самые 6 байт, при этом чтобы гарантированно знать что ещё каких-то данных в сокете не осталось:
1. Попытаться считать количество байт данных, максимальное для протокола UDP и recvfrom возратит количество реальные данных.

2. Я считываю ровно 6 байт и потом смотрю, а остались ли в сокете ещё какие-то данные?

либо вариации на эту тему (кстати более оптимальный/правильный/кошерный код приветствуется).
Можно ли сделать как во втором случае?
Стивенс пишет по этому поводу (Unix. Разработка сетевых приложений, 3 издание, стр. 278)
"Для сокета на уровне UDP происходит неявная буферизация дейтаграмм в виде очереди. Действительно у каждого сокета UDP имеется буфер приема, и каждая дейтаграмма, приходящая на этот сокет, помещается в его буфер приема. Когда процесс вызывает функцию recvfrom, очередная дейтаграмма из буфера возвращается процессу в порядке FIFO..."
Т.е. если я считал 6 байт из 10 байт дейтаграммы и вызвал опять recvfrom, то я считаю оставшиеся 4 байта или получу данные с другой дейтаграммы?

нет
будет установлен MSG_TRUNC и 4 байта будут потеряны

в вашем случае нужно считывать PMTU - 20 - 8 байт (максимальный размер UDP сообщения) по сути первый случай

короче,смотри,
в функцие recvfrom есть поле флаги
он имеет 3 различных флага
я думаю, что в данном случае для тебя будет интересен флаг MSG_WAITALL
привожу описание из книги Рочкинда "программирование для Unix"
MSG_WAITALL используется только для сокетов с установленным соединением.
блокирует recvfrom до тех пор пока не будет получено запрошенное число байт, флаг MSG_PEEK сброшен вызов не был прерван сигналом....
единственный минус этого флага, что он работает только с TCP(((