Потоковое /Chunked HTTP и зависание NSURLSession

У меня есть этот кусок кода, который я пытался портировать. Код работает на 100% в Windows, используя реализацию WinHTTP. На симуляторе IOS 7 я использую NSURLSession. Для обычного HTTPS get/post работает нормально.

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

У меня есть блокирующий синхронный вызов ниже, который будет ждать, пока текущий запрос не завершится. Когда я использую первую команду, синхронный цикл завершается после нажатия на делегата. Однако если я заменю на закомментированную вторую строку, синхронный цикл зависнет.

        [m_pDelegate.session invalidateAndCancel];
//      [m_pDelegate.session finishTasksAndInvalidate];
blockUntilOperationsComplete();

В конце концов он завершится, и я получу свои обратные вызовы данных. Я полагаю, что обратные вызовы, наконец, запускают МИНУТЫ позже, потому что небольшие сообщения поддержки активности (длиной 16 байтов) в конечном итоге переполняют буфер и инициируют вызов делегата. Есть ли способ уменьшить порог буферизации?

1 ответ

Потратив на это 2 дня, я оставлю это для следующей души. Нет никакого способа уменьшить этот буфер с помощью существующих классов NSURL*. Оказывается, что текущая реализация (на iOS7, и кажется, что так было всегда) для чанкированного кодирования буферизует входящие данные, ожидая сбора 512 байт полезной нагрузки, кодированной чанком, и только после этого будут выполняться обратные вызовы - важная часть следует - если Content-Type равен "text/html". После этого все последующие обратные вызовы, вызванные трафиком, будут происходить в режиме реального времени.

Однако если сервер изменит заголовок Content-Type на "application/json", он не будет буферизован, и ваши обратные вызовы сработают, как только что-то будет получено.

Другие вопросы по тегам