• Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

Ожидание ответа от сервера

Const

Member
Здравствуйте! Есть esp-01 на которой работает сервер выполняющий какие-то действия по http запросу, после чего возвращает ответ. Действия который он выполняет могут занимать до минуты времени, в связи с чем клиент в роли которого выступает браузер, отключается по timeout. Вопрос такой - как можно увеличить время ожидания ответа?
 

Юрий Ботов

Moderator
Команда форума
Мне кажется лучше сделать так:
- сразу после прихода запроса надо отдать ответ, пустую страницу или предупреждение "ждите" но в тексте этой страницы (в head) разместить: <meta http-equiv="Refresh" content="10" /> - автообновление раз (тут) в 10 секунд.
- спокойно обрабатываем данные. Если во время обработки приходит очередной автозапрос - послать обратно ту же страницу с автообновлением.
- когда все обработалось сохраняем данные. По следующему приходу запроса отдаем страницу с сохраненными данными и уже без тега автообновления...
Как то так.
 

nikolz

Well-known member
Здравствуйте! Есть esp-01 на которой работает сервер выполняющий какие-то действия по http запросу, после чего возвращает ответ. Действия который он выполняет могут занимать до минуты времени, в связи с чем клиент в роли которого выступает браузер, отключается по timeout. Вопрос такой - как можно увеличить время ожидания ответа?
можно сделать так:
На запрос сервер отправляет ответ в котором указывает время для исполнения запроса и номер данного запроса.
Через указанное время посылаем на сервер номер запроса и получаем ответ.
На сервере при получении запроса присваиваем ему номер
а при получении этого номера отсылаем подготовленный ответ
-------------
В итоге время исполнения может быть любым
и нет надобности забивать эфир постоянными запросами.
 

Const

Member
можно сделать так:
На запрос сервер отправляет ответ в котором указывает время для исполнения запроса и номер данного запроса.
Через указанное время посылаем на сервер номер запроса и получаем ответ.
На сервере при получении запроса присваиваем ему номер
а при получении этого номера отсылаем подготовленный ответ
-------------
В итоге время исполнения может быть любым
и нет надобности забивать эфир постоянными запросами.
Интересный подход. Я не сомневаюсь что такой алгоритм будет работать, но только в том случае если я буду знать какое время будет нужно на обработку.
 

Const

Member
Мне кажется лучше сделать так:
- сразу после прихода запроса надо отдать ответ, пустую страницу или предупреждение "ждите" но в тексте этой страницы (в head) разместить: <meta http-equiv="Refresh" content="10" /> - автообновление раз (тут) в 10 секунд.
- спокойно обрабатываем данные. Если во время обработки приходит очередной автозапрос - послать обратно ту же страницу с автообновлением.
- когда все обработалось сохраняем данные. По следующему приходу запроса отдаем страницу с сохраненными данными и уже без тега автообновления...
Как то так.
Мне кажется что таким образом мы будем заново изобретать велосипед.
Не ужели нет параметра timeout которое можно увеличить? Если писать приложение для андроида то нужно будет так же громоздить код.
 

CodeNameHawk

Moderator
Команда форума
Мне кажется что таким образом мы будем заново изобретать велосипед.
Не ужели нет параметра timeout которое можно увеличить? Если писать приложение для андроида то нужно будет так же громоздить код.
И пусть пользователь гадает на пустой странице то ли еще ждать, то ли просто, что то не работает.
На запрос пользователя должна сразу открыться "страница ожидания", а когда появятся данные обновиться или переключиться на другую страницу.
Смотрите в сторону XML, https://esp8266.ru/forum/threads/obnovlenie-dannyx-na-veb-stranice.1628/
 

Const

Member
И пусть пользователь гадает на пустой странице то ли еще ждать, то ли просто, что то не работает.
Зачем пользователя отправлять на пустую страницу? Все запросы отправляются во фрейм. Следовательно страница не перезагружается, а во время обработки запроса с помощью js выводим инфу типа: "ожидайте...", а после того как сервер вернет ответ обновляем данные.
На запрос пользователя должна сразу открыться "страница ожидания", а когда появятся данные обновиться или переключиться на другую страницу.
Смотрите в сторону XML, https://esp8266.ru/forum/threads/obnovlenie-dannyx-na-veb-stranice.1628/
Сейчас я использую именно такой подход с разницей что все запросы проходят через фрейм без перезагрузки страницы. Данный подход неудобен тем что сервер постоянно атакуется запросами, куда проще подождать ответ. Так же для других приложений нужно будет писать цикличные запросы или что то подобное. С точки зрения проектирования сетей это не лучшее решение. Такой подход лучше использовать например когда приложение в режиме ожидания с интервалом 3 минуты для того что бы выводить уведомления что что то изменилось. Wpf приложение к стати которое я написал для получения данных умеет ждать ответ по умолчанию. Скорей всего нужно просто отправить какие то заголовки.
 

CodeNameHawk

Moderator
Команда форума
Сейчас я использую именно такой подход с разницей что все запросы проходят через фрейм без перезагрузки страницы.
Для начала покажите код.
Перезагрузки страницы нет, есть только обновление данных.
Вы знаете максимальное время подготовки данных сервером, поставьте время повторения выше времени подготовки и получите практически один запрос, ну или всегда актуальную информацию с минимальными запросами по сети.
Так же для других приложений нужно будет писать цикличные запросы или что то подобное.
Если приложение поддерживает браузер ничего писать не придется.
 
Последнее редактирование:

nikolz

Well-known member
Интересный подход. Я не сомневаюсь что такой алгоритм будет работать, но только в том случае если я буду знать какое время будет нужно на обработку.
Не знаю что Вы считаете.
Но можно сделать примерно так.
Если у Вас может быть различное время на подготовку ответов на различные вопросы то делаете таблицу таймов в зависимости от вопроса сообщаете тайм.
если на самом деле надо больше времени то на запрос отвечаете "ответ не готов" - например посылаете пустую строку или нулевой байт.
Клиент ждет еще тайм и опять спрашивает.
 

nikolz

Well-known member
еще можно открыть второй канал для обмена сообщениями.
либо обмениваться короткими сообщениями по протоколу UDP.
 

Const

Member
еще можно открыть второй канал для обмена сообщениями.
либо обмениваться короткими сообщениями по протоколу UDP.
Верно. И почему я сразу не додумался... Только лучше не UDP а TCP. Для таких нужд придуман реалтайм обмен данными WebSocket. И не нужно никаких ответов ждать.
 

nikolz

Well-known member
Верно. И почему я сразу не додумался... Только лучше не UDP а TCP. Для таких нужд придуман реалтайм обмен данными WebSocket. И не нужно никаких ответов ждать.
а чем по-вашему TCP будет лучше. Только не рассказывайте про гарантированную доставку.
Для коротких сообщений и в локальной сети UDP тоже все гарантирует и превосходит TCP особенно для таких устройств как ESP.
Удивите меня рассказом про достоинства TCP в данном случае.
 

Const

Member
а чем по-вашему TCP будет лучше. Только не рассказывайте про гарантированную доставку.
Для коротких сообщений и в локальной сети UDP тоже все гарантирует и превосходит TCP особенно для таких устройств как ESP.
Удивите меня рассказом про достоинства TCP в данном случае.
Есть отличная шутка про UDP, но есть шанс что она может до вас не дойти, а еще есть шутка про TCP и если она не дойдет до вас то я её повторю. ;)
Я использую удаленное управление. Пусть я жертвую скоростью, зато точно буду знать что моя команда выполнится. По сравнению с GET или POST запросами TCP в скорости будет в разы быстрее.
 

nikolz

Well-known member
Есть отличная шутка про UDP, но есть шанс что она может до вас не дойти, а еще есть шутка про TCP и если она не дойдет до вас то я её повторю. ;)
Я использую удаленное управление. Пусть я жертвую скоростью, зато точно буду знать что моя команда выполнится. По сравнению с GET или POST запросами TCP в скорости будет в разы быстрее.
полагаю что вы заблуждаетесь. ТСР решает проблему гарантированной доставки когда такая проблема существует.
В случае локально сети либо в случае коротких пакетов такой проблемы фактически нет.
Но применительно к ESP и подобным ей примитивным модулям wifi Есть проблема ограниченного числа одновременно поддерживаемых соединений.
А у UDP этот проблемы нет.
Кроме того, у UDP объем трафика минимум в два раза меньше.
В таких системах как умный дом нет проблемы с негарантированной доставкой сообщения.
Негарантированная доставка как правила возникает если сервер не работает. В этом случае протокол не имеет значение.
В остальных случаях проблем на протоколе UDP при коротких сообщениях не существует.
Более того, удивлю вас, что UDP позволяет решить проблему доставки огромных сообщений (десятки и сотни ГБ) , которая на TCP в случае потери пакета и плохих каналов приводит к огромным потерям трафика и времени доставки.
 
Сверху Снизу