Автор Тема: Z5R WEB - web-json и отвратительная работа по нему[РЕШЕНО]  (Прочитано 21118 раз)

astashov

  • Пользователь
  • *****
  • Сообщений: 72
https://learn.javascript.ru/xhr-longpoll
А, ну понятно. Окей, это вариант реализации. Согласен. НО!

Во первых для ленивых опишу словами то что описано по ссылке простыми словами:
1) контроллер пингует сервер раз в 15 секунд
2) сервер получив запрос от контроллера держит его N секунд, в ожидании команд от оператора(например открытия двери с веб интерфейса).
3) дождавшись любой команды, отвечает на пинг(или любой другой запрос) с командой.
3) если за N секунд никаких команд не появилось, то отвечаем пустым понг ответом и go to 2

Что имеем в реале:
Абсолютно не важно какой интервал пингования установлен в контроллере или передан через параметр Interval. Контроллер в любом случае посылает команду power_on, если нет ответа на пинг в течении 4-х секунд. Есть предположение что проверяется отсутствия пинга более 4.99... секунд.
Т.е. по факту отложить можно максимум на 4 секунды :)

Но и это еще не все. Следующий пинг контроллер посылает только тогда, когда получит ответ на предыдущий пинг :) Т.е. ни о какой асинхронности даже и речи нет :)
И в итоге, данный подход для реализации на этом контроллере полностью бесполезен. Ладно бы новый пинг от понга не зависел бы, еще можно было бы выставить время интервала в 5 секунд, отвечать не позднее чем в 4 секунды и можно было бы говорить что почти что реалтайм(конечно с оговорками что если произошло событие, то новое событие может произойти только в течении interval секунд)

Цитировать
2018-06-20 13:35:53 - Z5RWEB446405b2a03d94816e - ...ping
2018-06-20 13:35:57 - Z5RWEB446405b2a03d94816e - ...pong
2018-06-20 13:36:12 - Z5RWEB446405b2a03ec1a205 - ...ping
2018-06-20 13:36:16 - Z5RWEB446405b2a03ec1a205 - ...pong
Интервал пингования 15 секунд, сон между пинг и понг 4 секунды. По таймингу видно как ведет себя контроллер.

murat351

  • Пользователь
  • *****
  • Сообщений: 70
я перечислял варианты на которых  это могло бы быть реализовано - какие варианты бывают (типовые)
"вариантов реализации  "двустороннего вызова" много, например веб сокет или задержанный ответ,"
- они не реализованы в этим контроллере.

astashov

  • Пользователь
  • *****
  • Сообщений: 72
а, если те варианты на которых могло бы быть реализовано, тогда да. Это приемлемый вариант.


murat351

  • Пользователь
  • *****
  • Сообщений: 70
"Следующий пинг контроллер посылает только тогда, когда получит ответ на предыдущий пинг  Т.е. ни о какой асинхронности даже и речи нет "
- я не понял проблемы
1) на  пинг отвечаем не позднее 4 сек
2) интервал между пингами ставим 1 сек

наверное, хорошо бы иметь возможность регулировать допустимое время задержки до 15-30 сек
но в остальном я проблем не вижу

astashov

  • Пользователь
  • *****
  • Сообщений: 72
"Следующий пинг контроллер посылает только тогда, когда получит ответ на предыдущий пинг  Т.е. ни о какой асинхронности даже и речи нет "
- я не понял проблемы
1) на  пинг отвечаем не позднее 4 сек
2) интервал между пингами ставим 1 сек

наверное, хорошо бы иметь возможность регулировать допустимое время задержки до 15-30 сек
но в остальном я проблем не вижу

В таком варианте я согласен. будет оптимально. Даже думаю что можно использовать как конечное решение.

astashov

  • Пользователь
  • *****
  • Сообщений: 72
1) на  пинг отвечаем не позднее 4 сек
2) интервал между пингами ставим 1 сек

но в остальном я проблем не вижу
На самом деле проблемы есть! Так как режим работы синхронный, то запрос check_access приходит только тогда, когда я отсылаю понг ответ

И что происходит.... Прикладываю карту. приемник моргает желтым и потом сразу красным. И только когда подносишь карту в момент когда пришел понг ответ, сервер получает запрос от контроллера и может авторизовать тебя.
И что то мне подсказывает, именно с этим связано поведение с картой 555555555555.

В общем этот вариант работы не подходит. Остается только выжигать все напалмом - т.е. ставить пинг интервал 1 секунды. Иначе никак.
« Последнее редактирование: 20 Июня 2018, 13:47 от astashov »

murat351

  • Пользователь
  • *****
  • Сообщений: 70
да согласен, не получается

astashov

  • Пользователь
  • *****
  • Сообщений: 72
Кстати из за того, что выставляется пинг задержка в 1 секунду, то время аутентификации может быть в пределах 0-1.х секунды. Т.е. иногда подносишь карту, и сервер моментально авторизует тебя, а иногда подносишь карту, и задержка в секунду точно присутствует(визуально дискомфортно, когда приготовился тянуть дверь, а она зараза закрыта :) ). Раньше я не понимал почему. В автономном режиме все моментально, не успеваешь поднести как дверь открылась, а тут задержка. Грешил на запрос-ответ, сетевые издержки и т.д.. Ну не секунда ведь..... Теперь понятно почему.
Если честно, то не комфортно конечно.

Вот бы убрать зависимость... Было бы хорошо.

п.с.: неплохо было бы описать эту особенность в протоколе. А то вдруг еще кто ни будь захочет так же как я заморочиться. Что бы меньше сюрпризов было....
« Последнее редактирование: 20 Июня 2018, 16:00 от astashov »

dimpase

  • Пользователь
  • *****
  • Сообщений: 1
Люди! прошло столько времени а проблемы не решены! это минусы нашего Российского "подхода"!
Контроллер шлет постоянно power_on в режиме online:1 . В режиме online:0 контроллер отвечает на пинг корректно но время от времени присылает все-же power_on
Даже разработчики мне прислали свой скрипт которым они тестируют свои железки, там все так же.
Использовать режим онлайн возможно только при long_pool запросах. На сервере нужно ставить цикл и смотреть когда появятся новые события, если события появились, то отдаем json контроллеру, если не появились то отдаем пустое сообщение.

Такой подход избавит вас от задержек.

В режиме онлайн нужно постоянно отправлять active 1 active 1
Видимо это недоработка их программистов .
Хочу так же пожаловаться на очень скудную документацию по протоколу. Нет четкого описания параметров, входных/выходных данных, так же не указаны обязательные парметры на те или иные действия.

murat351

  • Пользователь
  • *****
  • Сообщений: 70
"Контроллер шлет постоянно power_on в режиме online:1 . В режиме online:0 контроллер отвечает на пинг корректно но время от времени присылает все-же power_on"
- тут ошибка на сервере. Как правило ошибаются при отправке на пинг.
правильный ответ {"date":"2019-08-21 12:55:20","interval":8,"messages":[]}
обратите внимание !!!  "messages":[] - таким должен быть пустой ответ.
эта ошибка приводит к  "В режиме online:0 контроллер отвечает на пинг корректно но время от времени присылает все-же power_on"

"Контроллер шлет постоянно power_on в режиме online:1"
- это просто ошибка на сервере, видимо, логическая

Правильное оформление запросов и ответов можно посмотреть на тестовом сервере
http://json5.il78.com/5/
это веб интерфейс администратора
сервер написан на PHP