Согласно http://cumulocity.com/guides/reference/real-time-notifications/ клиент, который инициирует рукопожатие для получения уведомлений в реальном времени, может включить рекомендацию в тело запроса. Этот совет может иметь тайм-аут ("Максимальное время в миллисекундах между отправкой сообщения о подключении и ответом от сервера") и интервал ("Период, после которого сервер закрыть сеанс, если не получено следующее сообщение о подключении от клиента.»). Я не понимаю эти параметры и то, как они применяются к моим длительным соединениям с опросом.
- зачем серверу интересоваться тайм-аутом, который клиент использует для своего соединения? Предполагается немедленно отправлять уведомления по мере их поступления (т.е. «в режиме реального времени»). И это действительно так, как и ожидалось. Даже когда я указываю очень короткий тайм-аут, но на самом деле использую гораздо более длительный тайм-аут для моего подключения, я все равно получаю уведомления, которые происходят между этими двумя моментами времени без каких-либо проблем. И когда я указываю большой тайм-аут, я все равно сразу получаю уведомления. Это имело бы смысл для ленивых уведомлений, но я не вижу упоминания о них в документации. Так в чем смысл этого значения?
- в чем смысл интервала? Если я укажу короткий интервал, но буду ждать гораздо дольше между двумя последовательными вызовами подключения, тогда сервер не "закрывает сеанс", если это будет означать, что мой clientID становится недействительным, и мне нужно сделать новое рукопожатие. Может быть, это просто гарантированное минимальное время, в течение которого сервер должен поддерживать сеанс? т.е. максимальное время, в течение которого клиент хочет, чтобы ему было разрешено ждать между подключениями [и ожидание дольше может работать или не работать, на усмотрение серверов]? Это также не время, после которого очереди фактически очищаются, потому что, если я запускаю уведомление, когда я не подключен, и повторно подключаюсь по истечении интервала времени, то это уведомление все еще доставляется нормально.
Если мы сравним это с уведомлениями SmartREST, то увидим, что там должно работать наоборот, что, ИМХО, имеет больше смысла: сервер отправляет совет клиенту, чтобы сказать ему, как он должен настроить себя. Значение в этом случае все еще может быть несколько двусмысленным, но, по крайней мере, обработка может быть более прямой (= просто делайте так, как советует сервер):
- тайм-аут: не используйте более длительные тайм-ауты, потому что сервер не хочет держать соединения открытыми дольше, чем X. Не используйте более короткие тайм-ауты, потому что серверу может потребоваться время X для создания всех уведомлений для ответа.
- интервал: не переподключайтесь быстрее, чем Y, потому что внутренняя рассылка уведомлений сервера даже не работает так быстро. Не ждите дольше, чем Y, прежде чем переподключаться, потому что внутренние очереди не буферизуют уведомления дольше, чем Y. (В справочнике CometD эти два параметра называются interval и maxInterval, так что ясно, что они независимы.)
Почему «направление совета» меняется на противоположное в двух сценариях? Как (если вообще) я должен использовать совет для регулярных рукопожатий с уведомлением в реальном времени?
Большое спасибо за любые разъяснения по этому поводу.
