Составление приложения для использования в высокорадиоактивных средах
этот работал для меня
app.use(express.static(path.join(__dirname, 'public')));
app.use('/img',express.static(path.join(__dirname, 'public/images')));
app.use('/shopping-cart/javascripts',express.static(path.join(__dirname, 'public/javascripts')));
app.use('/shopping-cart/stylesheets',express.static(path.join(__dirname, 'public/stylesheets')));
app.use('/user/stylesheets',express.static(path.join(__dirname, 'public/stylesheets')));
app.use('/user/javascripts',express.static(path.join(__dirname, 'public/javascripts')));
1 ответ
Вы хотите 3+ подчиненные машины с хозяином вне радиационной обстановки. Все операции ввода / вывода проходят через мастер, который содержит механизм голосования и / или повторных попыток. У ведомых устройств должен быть аппаратный сторожевой таймер, и вызов для их повышения должен быть окружен CRC или чем-то подобным, чтобы уменьшить вероятность непроизвольного столкновения. Удар должен контролироваться ведущим, поэтому потерянное соединение с главным равняется перезагрузке в течение нескольких секунд.
Одним из преимуществ этого решения является то, что вы можете использовать тот же API для ведущего устройства, что и для подчиненных, поэтому избыточность становится прозрачной функцией.
Редактировать: Из комментариев я чувствую необходимость прояснить «идею CRC». Вероятность того, что ведомое устройство ударит свой собственный сторожевой таймер, близка к нулю, если вы окружите удар с помощью CRC или дайджест-проверок случайных данных от мастера. Эти случайные данные отправляются только от ведущего, когда подчиненное устройство находится под контролем других. Случайные данные и CRC / дайджест немедленно очищаются после каждого удара. Частота удара ведущий-ведомый должна быть более чем вдвое тайм-аутом сторожевого устройства. Данные, отправляемые мастером, генерируются уникальным образом каждый раз.