Альтернатива для QNetworkAccessManager

Question

Я рисую карту в BB10. Карта разделена на плитки. При запуске пользователь дает долготу, широту и масштаб, а карта отображается по этой координате. Я получаю одну плиту, выполняя http-запрос с QNetworkAccessManager. Сначала загружаются 7x5 фрагментов. Но проблема заключается в том, что пользователь начинает делать панорамирование на экране очень быстро и продолжает делать это иногда, после того как пользователь остановил панорамирование, плитки загружаются с большой задержкой. Каждый раз, когда пользователь делает панорамирование, некоторые новые фрагменты загружаются для отображения на экране. Теперь, поскольку пользователь продолжает панорамирование на некоторое время, существует так много ненужных сетевых запросов с QNetworkAccessManager. И я предполагаю, что загрузка этого файла происходит медленно. Я попытался прервать QNetoworkReply из QNetworkAccessManager, используя метод abort() для ненужных запросов. Но все же его очень медленно. Есть ли альтернативный способ достичь того, что я пытаюсь сделать? Благодарю.

Answer 1

Я лично считаю, что проблема в том, что вы делаете слишком много ненужных подключений.

Как правило, HTTP считается несколько тяжеловесным протоколом. Он построен на TCP, поэтому для установления связи с 3-сторонним рукопожатием необходимо установить и 4-стороннее рукопожатие для завершения, не считая времени для генерации и анализа этих HTTP-заголовков.

Также учитывайте нагрузку на сервер. Небольшой обычный веб-сервер обрабатывает ~ 100 запросов в секунду. Если ваш клиент выполняет такой частый запрос, я боюсь, что сервер не будет слишком рад приветствовать ваше приложение.

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