Спору нет, hsh очень непроработан http://caxapa.ru/pyramid/
к сожалению (для развития hsh), мы уже отказались от wake. Но не потому что он плох, нет, это хороший протокол, и хорошо документированный. Но есть два "но":
1. Нет квитирования - слейв должен знать, что его ответ дошел до мастера. Ваша мысль о переносе битов квитирования в байт команды очень хороша и "в духе wake"!
2. Так уж есть, что wake описывает Data Link и Network уровни протокола (OSI). В этом его сила (все уже сделано) и его слабость (надо постараться, чтобы положить его, например, на modbus RTU или ASCII, или даже на SLIP). Недавно тут обсуждалась Пирамида - вот пример независимости от Data Link уровня (ссылка на обсуждение с автором
http://caxapa.ru/m …wwwboard.html?id=11961).
Повторю, wake - хороший протокол для сферы, где он предназначен изначально, но его развитие несколько затруднено (особенно п.2.).
Теперь о ваших замечаниях/комментариях:
1. "Квитирование реализуется на командном уровне."
Можно делать и так (реализовывать ack на уровне приложения), но ведь мы хотим по максимуму делать на более низком уровне.
2. "Не совсем понимаю, зачем нужна команда «запрос разъединения»."
Ее передают и мастер, и слейв после рестарта. Мастеру, может быть, интересно знать, что слейв ресетнулся.
Вот от "закрытия соединения" я бы отказался легко :).
3. "Не понял, как это у Вас приемник второй раз передает подтверждение пакета 1, не приняв пакет 2 от передатчика?"
Вы правы, это надо убрать.
4. "Получается, у Вас приемник всегда после рестарта по собственной инициативе передаёт пакет с кодом команды «нет соединения»?"
Еще раз правы, это я тоже выдрал "и другой оперы" и для обсуждаемой темы это не годится..