Тестовое задание позволяет определить в том числе и Вам, потяните ли вы эту работу. Если возникают нерешаемые проблемы на уровне тестового задания, я бы задумался, стоит ли в целом на данном этапе идти на вакансию
Хотел докопаться до ISO, но оказывается, можно и так. Но это, я даже не знаю кто еще так говорит. Сейчас и OSI нечасто можно услышать, хотя база вроде как
Чет не вижу ни в одном из случаев где мог бы передаваться какой-либо токен. Не работал с urllib, работал с requests. Навскидку - отключите обработку переадресаций и выводите не просто status code и еще и тело ответа. Так будет понятнее
Альберт, это настраивается через вашего провайдера ip телефонии, есть ли у вас вообще выход в город и если да, то как именно он производится (нужен ли какой-то префикс). Сама программа просто передает вызов провайдеру, не более. Возможно в ЛК телефонии есть что-то на этот счет
Akina, понял, спасибо за пояснения. К сожалению доки не содержат ответов на некоторые вопросы. В том числе про failover выборы мастера я также слышу впервые, хотя перечитывал мануал как в оригинале так и в переводе.
Akina, 1. Прочитайте мое сообщение еще раз, там не это написано. Обрыв поделит кольцо на 2 ветки, в каждом транзит обнаружит обрыв и отправит через оставшийся интерфейс линкдаун
2. То есть всё же есть разница в направлении первичного и вторичного портов для быстрого перестроения топологии? Вэтом и заключается мой вопрос
3. Как я уже упомянул, этими цифрами можно принебречь, главное чтобы линкдаун сообщение было доставлено, потому что FAIL TIMER = HELLO TIMER x3 что значительно больше чем пара милисекунд
Akina, просто если это делает ЛЮБОЙ транзит, значит при обрыве будет сгенерировано 2 сообщения по разные от обрыва стороны. Я подозреваю, что мастер нормально этот момент обработает, но всё же
Akina, я изучал и доки от Huawei и от H3C. Вот как раз в H3C указано, что линкдаун шлет только тот узел, который обнаружил падение ВТОРИЧНОГО линка. От этого, по большому счету, зависит только то, в каком направление от разрыва будет сгенерировано данное сообщение, так что, наверное, большой роли не сыграет на маленьком кольце. Однако, чем больше кольцо, тем принципиальнее с какой стороны от разрыва будет сгенерирован linkdown. claude мне озвучил принцип "транизт должен смотреть первичным портом в сторону мастера по кратчайшему пути", видимо, как раз в соответствии с доками Н3С. Таким образом, можно сделать вывод что в каждом полукольце первичные порты будут направлены в свою сторону, а соединение secondary-secondary будет на ровно противоположной мастеру стороне.
из вашего ответа я понял, что при нормальной работе кольца это неважно, но мне нужна высокая доступность, чтобы linkdown пришел корректно, а не ждать 30 сек fail timer
Спасибо за ответ! Не могли бы вы немного объяснить логику пересылки health транизтами - они видят, в какой порт он пришел и пересылают в противоположный? Или шлют сразу в оба порта и пакет (при собранном кольце) приходит в два порта мастера одновременно? Также, в доках h3c написано, что linkdown сообщение шлет только тот транзит, чей ВТОРИЧНЫЙ порт упал. Это значит, что при некорректном их расположении время детекта аварии увеличивается до FAIL TIMER мастера.