#498 closed баг (fixed)
Определение состояния "нет связи с сервером" может длиться более 10сек.
Reported by: | san | Owned by: | dimag |
---|---|---|---|
Priority: | critical | Milestone: | 1 очередь |
Component: | ПО MC04-Dispatcher. Пульт диспетчера/техника | Keywords: | algorithm |
Cc: |
Description
что противоречит исходному заданию
Наблюдал в r506
Change History (22)
comment:1 by , 8 years ago
comment:2 by , 8 years ago
Точно не знаю, я таскал ползунок во время проигрывания звукозаписи, и при этом разорвал связь с сервером.
comment:4 by , 8 years ago
Как ты узнал что определение связи не было больше 10 секунд, таская ползунок, в данном окне, где находятся ползунки, невозможно посылать команды и просматривать список пользователей и лог?
comment:5 by , 8 years ago
Replying to dimag:
В этот момент программа связывалась с сервером по Wi-Fi?
Нет. А какая разница?
Как ты узнал что определение связи не было больше 10 секунд
Выдернул шнур Eth - посмотрел на счётчик секунд на часах, когда значение счётчика секунд увеличилось более чем на 10 секунд после выдёргивания шнура, сделал вывод что прошло более 10 секунд.
Добавлю что красный баннер и звуковой сигнал появились примерно через секунд 18 после выдёргивания шнура.
comment:6 by , 8 years ago
Пробовал на своём компьютере и на ноутбуке, ничего подобного не происходило, может всё было зависаниями сети в связи с работой Анатолия?
comment:7 by , 8 years ago
И какая разница что в сети происходило? я шнур ETH выдернул из компьютера, а программа заметила это только через 18 секунд.
comment:9 by , 8 years ago
Довольно легко воспроизводится:
- Запускаю проигрывание звукозаписи
- Выдёргиваю шнур Ethernet
- Сразу же начинаю кликать мышкой по "полоске" проигрывателя - даю команду "перемотать немного вперёд" / назад
- Продолжаю кликать до истечения 10 секунд - Готово
comment:10 by , 8 years ago
Того же самого можно добиться тыкая по кнопке "mute/unmute" сразу после отключения сети.
follow-up: 12 comment:11 by , 8 years ago
Keywords: | algorithm added |
---|---|
Resolution: | → fixed |
Status: | new → closed |
r515
Переписал подсчёт времени между проверками на наличие соединения, теперь использую секундный таймер вместо подсчитывания событий, запросы на позиционирования, включения/выключения микрофона выполняются с временем ожидания 600 мс.
Теперь задержка между потерей соединения и появлением окна с информацией об ошибке укладывается в 5 секундный интервал.
follow-up: 13 comment:12 by , 8 years ago
Replying to dimag:
запросы на позиционирования, включения/выключения микрофона выполняются с временем ожидания 600 мс.
Ожидания чего?
Теперь задержка между потерей соединения и появлением окна с информацией об ошибке укладывается в 5 секундный интервал.
Почему 5-секундный, если по условию задачи требуется 10-секундный?
follow-up: 14 comment:13 by , 8 years ago
Почему 5-секундный, если по условию задачи требуется 10-секундный?
Если точнее по условию: "Чем быстрее, тем лучше, но не более 10 сек.".
Естественно "быстрее" должно быть в разумных пределах.
follow-up: 15 comment:14 by , 8 years ago
Replying to san:
Естественно "быстрее" должно быть в разумных пределах.
Мне кажется, 10 - это уже на "разумном пределе". Разумность я понимаю следующим образом. Что будет делать диспетчер, когда увидит, что у него пропала связь? Наверное обратится к кому-то, кто пойдет искать и устранять неисправность. И эти поиски и устранение займут уж наверняка много больше 10 секунд. Поэтому появится ли сообщение на пять (или даже десять) секунд раньше или на пять секунд позже, вряд ли может иметь какое-то существенное значение. Это во-первых.
Во-вторых, и это даже, пожалуй, главное, как мы знаем, для контроля наличия связи пульт посылает запрос status коммутатору с периодом 5 секунд. А раз так, то при таймауте отсутствия связи тоже 5 секунд не остается никакого временнОго запаса на задержку выполнения запроса и/или передачу данных по сети. Следовательно, будет большое число ложных срабатываний: стоит придти очередному ответу на 10 мс позже, и получится уже 5010 мс без обмена, что приведен к выдаче аварийного сообщения...
comment:15 by , 8 years ago
Теперь задержка между потерей соединения и появлением окна с информацией об ошибке укладывается в 5 секундный интервал.
Replying to alx:
Во-вторых, и это даже, пожалуй, главное, как мы знаем, для контроля наличия связи пульт посылает запрос status коммутатору с периодом 5 секунд.
А вот тут есть какой-то парадокс.
comment:16 by , 8 years ago
5 секунд в худшем случае, если прошлая проверка завершилась успешно и сразу после этого разорвалась связь, тогда задержка 5 секунд, если соединение разорвалось непосредственно перед проверкой, то менее чем за секунду.
comment:17 by , 8 years ago
...какие-то временные аномалии
5сек. + "таймаут"=5 секунд
"таймаут" = 0 ???
follow-up: 20 comment:18 by , 8 years ago
Например 3 секунды соединение было, сейчас, в секунду 0, соединение разорвалось, через 2 секунды проходи проверка, которая примерно в течение 1 секунды определит, что соединение разорванно. Время реакции на потерю соединения 2-3 секунды.
follow-up: 22 comment:19 by , 8 years ago
Дмитрий, у вас альтернативная арифметика :)
Пульт посылает запрос status коммутатору с периодом 5 секунд
проверка, которая примерно в течение 1 секунды
5 секунд в худшем случае
5+1=5 ?
comment:20 by , 8 years ago
Replying to dimag:
Например 3 секунды соединение было...
Это был пример чего или к чему? Что он поясняет?
comment:22 by , 8 years ago
Replying to san:
Дмитрий, у вас альтернативная арифметика :)
5+1=5 ?
Это квантовая арифметика. Там может быть несколько разных правильных ответов одновременно. :)
Как это воспроизвести?