2014-02-16 2 views
2

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

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

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

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

В конце концов он выйдет, и я получу свои обратные вызовы. Я верю, что обратные вызовы, наконец, запускают MINUTES позже, потому что небольшие сообщения keep-alive (длиной 16 байт) в конечном итоге переполняют буфер и вызывают вызов делегата. Есть ли способ уменьшить порог буферизации?

ответ

7

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

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

+0

К сожалению, это все еще верно в отношении NSURLSession ... очень грустно, что решение заключается в изменении службы. – Kekoa

Смежные вопросы