История изменений

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

Тут мы решаем ряд проблем:

• Данные фрейма могут приходить кусочками по несколько байт. Кольцевой буфер собирает их.
• При операции чтения можно достать конец одного фрейма и начало другого. Или битый фрейм или ещё какой-то мусор. Если такая ситуация возникла, можно выкинуть из начала очереди один байт и снова попробовать распарсить. Это дает возможность всегда вычленять из байтого потока фреймы, даже если процесс разбора сбился из-за битых данных.
• Унифицированный подход к разбору пакетов позволяет легче ориентироваться в своем коде. Когда у тебя будет много всякого кода разбора разных протоколов, то легче в куче этого кода ориентироваться. В голове все не удержишь.

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

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

Тут мы решаем ряд проблем:

• Данные фрейма могут приходить кусочками по несколько байт. Кольцевой буфер собирает их.
• При операции чтения можно достать конец одного фрейма и начало другого. Или битый фрейм или ещё какой-то мусор. Если такая ситуация возникла, можно выкинуть из начала очереди один байт и снова попробовать распарсить. Это дает возможность всегда вычленять из байтого потока фреймы, даже если процесс разбора сбился из-за битых данных.
• Унифицированный подход к разбору пакетов позволяет легче ориентироваться в своем коде. Когда у тебя будет много всякого кода разбора разных протоколов, то легче в куче этого кода ориентироваться. В голове все не удержишь.

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