NSURLConnection ограничивается одним подключением одновременно?

Question

ОК - давайте перефразируем весь этот вопрос, не так ли?

Есть ли способ узнать, удерживает ли iOS NSURLConnection после того, как он завершил и вернул свои данные?

У меня естьполучил 2 NSURLConnections Я создаю экземпляр и звоню на сервер с.Первый инициирует соединение с сервером, а затем переходит в долгое ожидание в стиле COMET, пока другой пользователь взаимодействует с запросом.Второй заходит на сервер и запускает механизм отмены, который безопасно завершает первый запрос и заставляет оба успешно вернуться с сообщением «Отменено вами».

В случае «счастливого пути» кнопка «Отмена» никогда не будетщелкнул.Но можно щелкнуть по нему и выйти из текущего действия.

Весь этот сценарий работает БОЛЬШОЙ раз.И затем никогда не работает снова (до тех пор, пока приложение не будет перезагружено).

Как будто первый раз через одно из соединений никогда не освобождается, и с тех пор мы ограничены только одним соединением, потому что одно из них являетсязаблокирован.

---

Кстати, я пробовал NSURLConnection, AFNetwork, MKNetworkKit, ASIHTTPRequest - не повезло, что вообще когда-либо с другими платформами.NSURLConnection должен делать то, что я хочу.Просто ... не отпускаю одно из моих соединений.

Answer 1

Я подозреваю, что запрос отмены на шаге 2 оставляет HTTP-соединение открытым.

Я не знаю точно, как классы NS * работают в отношении рекомендации HTTP / 1.1 для максимум двух одновременных соединений , но давайте предположим, что они обеспечивают не более двух соединений. Предположим, что код запуска в экземпляре A (шаги 1 и 3 вашего примера) очищается после себя, но код отмены в экземпляре B (шаги 2 и 4) оставляет соединение открытым. Это может объяснить то, что вы наблюдаете.

На вашем месте я бы сравнил код, который выполняется на шаге 1, с кодом, который выполняется на шаге 2. Могу поспорить, что между ними есть разница в том, как они убирают после себя.

Answer 2

Если я не ошибаюсь, iOS / Mac поддерживает NSURLConnection до тех пор, пока заголовок «Keep-Alive» предписывает его.

Но, как разработчик iOS, вы не должны беспокоиться. любая причина, почему вы хотели бы знать это?

Answer 3

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

То, к чему это приводит, это API для отправки команды и помещения ее в очередь на сервере, а затем с помощью NSTimer на клиенте для проверки состояния элемента в очередичерез регулярные промежутки времени.

Пока я не смогу выяснить, как сделать несколько подключений на iOS с длительным опросом, это единственное рабочее решение.Как только у меня будет приличное количество баллов, я с радостью отдам их за решение этой проблемы: (