То, что я напишу ниже, мне лично очевидно. Но когда начинаешь писать прошивки для микроконтроллеров -- это может быть ещё не очевидно. Так, на днях я обнаружил эту ошибку в прошивке у начинающего микроконтроллерщика. А за пару недель до этого -- у себя.
Воспользуемся классической терминологией -- Алиса отправляет Бобу сообщение. Сообщения. Одинакового формата, одно за другим.
Вариант первый -- в соответствии с договорённостью Боб ожидает получить сообщение длиной 8 байт. Однако после третьего байта Алиса внезапно умирает.
Когда Алиса воскресает, она, конечно, не помнит, что и кому она передавала, поэтому начинает передавать сообщение заново. Однако Боб об этом не знает. Получив первый байт нового сообщения, он записывает его как четвёртый байт старого сообщения! Фейл! Границы сообщений "сползают", в итоге Боб будет всё время получать неправильные сообщения и удивляться, почему не совпадает контрольная сумма.
Второй вариант -- Боб и Алиса договорились, что первым байтом сообщения будет 0x55. Однако либо Алиса сошла с ума -- и начала присылать неправильные сообщения, либо Боб подошёл к передатчику в середине сообщения, поэтому первым принятым байтом оказалось не 0x55, а, скажем, 0xAA. Если Боб не будет игнорировать ошибочное начало сообщения, а будет писать байты подряд, то он опять никогда не синхронизирует границы сообщений, как и в первом случае. Все сообщения будут признаны ошибочными из-за неправильной сигнатуры.
Действия тут очевидны:
1. В первом случае: если возникает пауза при передаче, то необходимо "забывать" недополученное сообщение и начинать приём заново. На практике это означает, что надо обнулять буфер приёма, если очередной байт (бит) был принят после паузы на линии.
2. Во втором случае сложнее. Если первый ожидаемый байт оказался неправильным, то буфер, конечно же, должен быть сразу обнулён. Однако, если сообщения сыпятся потоком, на восстановление синхронизации может уйти какое-то время, если сигнатура в сообщении присутствует не только в начале, но и в середине (может же случайно оказаться, что мы хотим передать сообщение 0x55 55 55 55 55 55 55 55?). Полностью эту ситуацию не побороть, можно только уменьшить количество потерянных сообщений, если, к примеру, увеличить длину сигнатуры, либо запретить её применение в остальной части сообщения.
Воспользуемся классической терминологией -- Алиса отправляет Бобу сообщение. Сообщения. Одинакового формата, одно за другим.
Вариант первый -- в соответствии с договорённостью Боб ожидает получить сообщение длиной 8 байт. Однако после третьего байта Алиса внезапно умирает.
Когда Алиса воскресает, она, конечно, не помнит, что и кому она передавала, поэтому начинает передавать сообщение заново. Однако Боб об этом не знает. Получив первый байт нового сообщения, он записывает его как четвёртый байт старого сообщения! Фейл! Границы сообщений "сползают", в итоге Боб будет всё время получать неправильные сообщения и удивляться, почему не совпадает контрольная сумма.
Второй вариант -- Боб и Алиса договорились, что первым байтом сообщения будет 0x55. Однако либо Алиса сошла с ума -- и начала присылать неправильные сообщения, либо Боб подошёл к передатчику в середине сообщения, поэтому первым принятым байтом оказалось не 0x55, а, скажем, 0xAA. Если Боб не будет игнорировать ошибочное начало сообщения, а будет писать байты подряд, то он опять никогда не синхронизирует границы сообщений, как и в первом случае. Все сообщения будут признаны ошибочными из-за неправильной сигнатуры.
Действия тут очевидны:
1. В первом случае: если возникает пауза при передаче, то необходимо "забывать" недополученное сообщение и начинать приём заново. На практике это означает, что надо обнулять буфер приёма, если очередной байт (бит) был принят после паузы на линии.
2. Во втором случае сложнее. Если первый ожидаемый байт оказался неправильным, то буфер, конечно же, должен быть сразу обнулён. Однако, если сообщения сыпятся потоком, на восстановление синхронизации может уйти какое-то время, если сигнатура в сообщении присутствует не только в начале, но и в середине (может же случайно оказаться, что мы хотим передать сообщение 0x55 55 55 55 55 55 55 55?). Полностью эту ситуацию не побороть, можно только уменьшить количество потерянных сообщений, если, к примеру, увеличить длину сигнатуры, либо запретить её применение в остальной части сообщения.
13.02.2019 в 12:43
13.02.2019 в 13:02
13.02.2019 в 23:43
Под подобную проблему "слушающего и говорящего" можно "подогнать" банальную репликацию master-slave. Соответственно из-за каких-то проблем (сеть, нагрузка, смерть участников) репликация может нарушиться.
На такой случай нормальные люди настраивают автоматический failover и автоматическое восстановление репликации после восстановления сервера/канала/чего-угодно.
В том числе еще более умные и нормальные люди сделали так, чтобы все это происходило "само автоматически из коробки" - придумали raft, потом прилепили его к базам данных и теперь если где-то что-то отвалится - система справится с проблемой сама.
Но есть люди, которые на событие "репликация развалилась" грубо говоря ставят действие "убить все, я приду, разберусь, что случилось и починю"
14.02.2019 в 01:10
14.02.2019 в 13:51
cs-cs.net/pravila-bezopasnosti-v-shhitax-i-avto... п. 5
>>И вот пропадает напряжение питания прям в тот момент, когда вы работаете. Станок встал, вы полезли ковыряться и соображать, чего это там такое с ним случилось, и тут напряжение появляется. И, как выражается Дима Бербраер, «после этого вас телепортирует на другую сторону станка, но только уже в несколько изменённом (перемолотом) виде». А если подъёмный кран будет? Или насос какой-нибудь?
14.02.2019 в 18:22
Но один фиг проблемы репликации вида мастер-слейв к этому не относятся
14.02.2019 в 18:35
Мы же говорим о домашних и бытовых приборах, а не о заводском цехе. Свет не будет "гореть", если только его не оставят. А оставить его могут по самым разным причинам в том числе умышленно.
Соответственно есть большой ряд приборов, которые должны включаться сами автоматически при восстановлении питания: начиная от холодильников-морозильников-водонагревателей (особенно зимой в загородном доме!) и заканчивая моим компом, если я оставил его включенным (и соответственно роутер с интернетом туда же - иначе нафиг мне работающий дома комп, если я к нему подключиться не могу?) или любимым аквариумом / террариумом, где если пропадет электричество и по совету этого человека оно не восстановится - могут вполне погибнуть или пострадать любимые рыбки, ящерки или насекомые.
Видео с лифтом он зря воткнул, там вообще про другое. Там про перемычку на цепях безопасности, а не про "невыключившиеся контакторы". У лифта фактически отсутствовала цепь безопасности дверей и он думал, что двери всегда закрыты и соответственно мог поехать с открытыми дверьми.