Был ли сервер успешно получен запрос

Question

Я работаю над приложением C# mobile, которое требует значительного взаимодействия с веб-сервером PHP. Тем не менее, приложение также должно поддерживать «автономный режим», поскольку соединение будет осуществляться через cellular network. Эта сеть может отбрасывать запросы в случайное время. Проблема, с которой я столкнулась с предыдущими приложениями «Offline Mode», заключается в том, что когда запрос приводит к таймауту, сервер может или не мог обработать этот запрос. В случаях, когда отправка запроса более одного раза создавала дубликат, это проблема. Я прошел через это и придумал следующую идею.

• Мобильный телефон устанавливает значение заголовка, например UniqueRequestID: 1, которое будет отправлено с запросом.
• При получении запроса, сервер PHP добавляет UniqueRequestID к текущей сессии пользователя $_SESSION['RequestID'][] = $headers['UniqueRequestID'];
• Сервер реализует GetRequestByID, который возвращает истину, если id существует для текущего сеанса или ложным, если нет. В качестве альтернативы, это могло бы вернуть результат кэширования запроса.

Это, кажется, несколько надежный способ увидеть, успешно ли связался запрос с сервером. В мобильном устройстве, после повторного подключения к серверу, мы проверяем, был ли получен запрос. Если да, пропустите это, ожидая ответа offline message и перейдите к следующему.

Вопрос Я изобрел колесо здесь? Является ли этот метод склонным к неудаче (или я иду вниз по кроличьей дыре)? Есть ли лучший способ/альтернатива?

- Я сделал это для других разработчиков здесь, и мы подумали, что это кажется очень простым, подразумевая, что эта «система», скорее всего, уже существует где-то.

- Извинения, если мои навыки Google не позволяют мне сегодня.

Answer 1

Как вы правильно заявили, эта проблема не нова. Было несколько попыток решить ее на разных уровнях.

Уровень транспорта

HTTP, транспортный протокол сам по себе не обеспечивает никаких механизмов для надежной передачи данных. Одна из причин заключается в том, что HTTP является апатридом и не заботится о предыдущих запросах и ответах. Были попытки IBM сделать надежный транспортный протокол под названием HTTPR, основанный на HTTP, но он никогда не пользовался популярностью. Вы можете больше узнать об этом here.

уровня сообщений

Большинство веб-служб, там до сих пор использует HTTP в качестве протокола обмена сообщениями транспортного протокола и SOAP поверх него. SOAP через HTTP недостаточно, когда протокол обмена сообщениями уровня приложений также должен гарантировать определенный уровень надежности и безопасности. Вот почему WS-Reliability и WS-ReliableMessaging протоколы, где введены. Эти протоколы позволяют надежно передавать SOAP-сообщения между распределенными приложениями при наличии программных компонентов, системных или сетевых сбоев. В то же время они обеспечивают дополнительную безопасность. Вы можете узнать больше об этих протоколах here и here.

Ваше решение

Я предполагаю, что нет ничего плохого с вашим подходом, если вам нужен простой способ гарантировать, что сообщение не было уже обработано. Я бы рекомендовал использовать базу данных вместо сеанса для хранения результата обработки для каждого запроса. Если вы используете $_SESSION['RequestID'][], вы столкнетесь с проблемой, если сеанс будет потерян (пользователь отключен в течение определенного времени, сервер перезагружается или разбился и т. Д.). Кроме того, если вы используете базу данных вместо сеанса, вы можете упростить ее позже, просто добавив дополнительный веб-сервер.