Z_h_e писал(а):Преимущество в том, что нет привязки ко времени.
Это не преимущество, а недостаток. Допустим, у Вас сеть с одним мастером и несколькими слейвами.
В процессе передачи пакета мастер прервал передачу (питание пропало, завис, не суть важно). Слейвы будут "висеть" в ожидании продолжения бесконечно, ибо время, отведенное на передачу байта в частности и пакета в целом, никак не контролируется. Когда мастер "придет в себя" и начнет передавать пакет заново, эти первые три байта 0xAA не будут распознаны как начало нового пакета, а будут приняты за продолжение байт данных предыдущего пакета. Даже если Вы в теле пакета передаете его длину, это ничего не значит - передача может остановиться сразу после передачи трех префиксных байт, при этом в качестве длины пакета может быть взят первый (или второй) префиксный байт. В итоге сеть восстановит работоспособность только тогда, когда:
1. счетчик принятых байт досчитает до нуля, при этом, скорее всего, текущий принимаемый пакет будет будет где-нибудь на середине. Ваш алгоритм остановит прием пакета по длине пакета (в качестве которой был взят "мусор", как мы помним). Ваш алгоритм должен будет отбросить этот пакет, поскольку длина исчерпана, а завершающих постфиксных байт не было, и перейти в ожидание следующего пакета
2. Но текущий-то передаваемый пакет продолжает приниматься, поэтому вместо трех префиксных байт Вы получите продолжение тела пакета. Этот пакет Вы тоже отбросите, потому что префикса не было.
3. И только после этого сеть восстановит работу. Если же Вы, надеясь только на свои префиксные и постфиксные байты не используете длину пакета вообще, то сеть никогда не восстановит работу после описанного мной сбоя. Вам придется перегружать всех - и мастера, и слейвов.
Понятно, что описанный мной случай может возникнуть нечасто, а "на лабораторном столе" так и вообще практически никогда. Но коль скоро механизм возникновения сбоя так легко просчитывается, то я бы не стал закладывать такую мину в алгоритм.
Кроме того, как быть, если помеха исказит один из постфиксных байтов 0x55? Конец пакета уже не будет распознан, и сбой начнет развиваться по описанному выше сценарию.
При передаче бинарных данных недопустимы любые пре- и постфиксы, потому что нет механизма, позволяющего отличить их от данных.
Если же делать жесткий контроль длины пакета на уровне алгоритма приема, то это (ничуть не упростив программу) лишает протокол обмена гибкости - возможности использовать пакеты переменной длины.
Z_h_e писал(а):Это упрощает программу, как для передатчика, так и для приемника.
Это тот случай, когда простота хуже воровства. Кроме того, как я уже писал, включить таймер и обнулить переменную в обработчике прерывания по переполнению этого таймера проще, чем программно отлавливать три байта в начале и три байта в конце. Так что не вижу я никакого упрощения программы.
Контроль времени, отведенного на прием, вкупе с передачей длины пакета позволяет сделать возможной переменную длину пакетов в протоколе.
Кстати, например, в протоколе TCP/IP делается контроль времени приема в виде параметра "время жизни дейтаграмм".
!!!
, исходя из прочитанного выше.