BlackGnomeГуест...с серийного порта на IP...

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

удачи вам
(круглый)
ЗЫ
Либо квитировать (как уже было сказано выше) данные началом посылки и длиной.
Начало посылки можно детектить так-же временным интервалом, либо заголовком, либо изменением статуса канала связи (разрыв/соединение)

Basil A. Sidorov...У асинхронных есть стартовый бит, настройка на количество бит данных и необязательный бит контроля чётности. Плюс ограничение на максимальную длину слова.

уважаемый! идёт речь не о слове(в большинстве случаев это байт), а о пакете!

пример...
слово (макс) = 9 бит.
пакет макс = сикока хошь...

прочуствуйте разницу...

в USARTах есть "механизация" 9 бита. которую можно заюзать для адресации при образщении по последовательной шине. Но это Вас не спасёт, если неизвестна длина данных.

Basil A. Sidorov...асинхронных портов можете ознакомиться с "flow-control"...

не отвлекайтесь от темы...
вы в один байт решили запаковать служебную инфу и данные? круто... а признак конца как? или вам разрядности байта хватает чтоб передать всю длину так-же?

вы только, что говорили про старт-стопы... как вы решили опознавать конец-начало пачки? расскажите на пальцах хотя-бы.

а то бедные эмбедеры даже не ведают..мутят какие то длины, заголовки, црц..а тут оказывается всё украли до нас давно уже :)

весь во внимании
(круглый)

Basil A. Sidorov...не приписывайте...

стоп уважаемый...
это ваше?

"есть стартовый бит, настройка на количество бит данных и необязательный бит контроля чётности. Плюс ограничение на максимальную длину слова"

А ТС спрашивает о синхронизации данных. Которая раньше шла последовательно.

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

"HDLC-кадры", "flow-control"

и как в лучших традициях "нападение - лучшая защита":

"не приписывайте мне собственные заблуждения"

молодца...
чтоб не разводить воду...по Вашим мотивам...

тут популярно, на русском.
flow-control
если коротко...
два метода - аппаратный и программный. программный - подмешиваем в поток старт-стоповые символы....(заметьте идёт речь о потоке данных! а не порте, старт-стоп битах и иже)
второй метод - аппаратный. Это когда вы дёргаете доп. линиями у последовательного порта CTS/RTS. Во первых я не видел упоминаний в вашем постинге об этих вещах, что касаемо порта. во вторых попробуйте это сделать под современными форточками - а я погляжу сколько вы будете тратить времени на ожидании так-же тут нет речи о старт-стопах, чётности и иже..

второй ваш эээээ...
HDLC
если коротко...
хоть и обзывают его битоориентированный... но это кадр данных. кратный 8 битам. с заголовками, црц, длиной и полезными данными. (заметьте идёт речь о кадре данных! а не о порте, старт-стоп битах и иже)


итого...
итог не утешителен. если ваш счётчик постингов достигается за счёт вот такой вот "полезной инфы" - то плохо...очень плохо...


удачи усем
(круглый)
ЗЫ
(вздыхая)
ох уж эти пионэры...
или троли? хрен их разберёт...