Длинный опрос с NSURLConnection

Я работаю над приложением для iPhone, которое будет использовать длительный опрос для отправки уведомлений о событиях с сервера клиенту через HTTP. После открытия соединения на сервере я отправляю небольшие биты JSON, которые представляют события по мере их возникновения. Я нахожу это-[NSURLConnectionDelegate connection:didReceiveData] вызывается только после закрытия соединения, независимо от настроек кеша, которые я использую при созданииNSURLRequest, Я проверил, что серверный конец работает должным образом - первое событие JSON будет отправлено немедленно, а последующие события будут отправлены по проводной связи по мере их возникновения. Есть ли способ использоватьNSURLConnection чтобы получать эти события по мере их возникновения, или мне нужно будет вместо этого перейти к API CFSocket?

Я начинаю работать над интеграцией CocoaAsyncSocket, но предпочел бы продолжать использоватьNSURLConnection если возможно, так как он намного лучше соответствует остальной части моей структуры веб-сервисов на основе REST / JSON.

 wakkus12 февр. 2013 г., 09:53
Я был в состоянии понять это .... проверить:stackoverflow.com/questions/1293026/…
 wakkus12 февр. 2013 г., 09:54
Я нашел решение для этого, смотрите мой ответ здесь:stackoverflow.com/questions/1293026/…
 Alec Sloman07 апр. 2011 г., 06:57
Эй, я видел, что вы использовали asyncsocket, чтобы получить желаемый результат. Есть ли шанс, что я когда-нибудь смогу разобраться с этим? Я @ msuprfrends в твиттере. Было бы очень признательно!
 wakkus12 февр. 2013 г., 09:58
Вот обходной путь, который я нашел после большой боли :)stackoverflow.com/questions/1293026/…

Ответы на вопрос(5)

Решение Вопроса

NSURLConnection буферизует данные во время загрузки и возвращает их вам одним куском сdidReceiveData метод.NSURLConnection класс не может сказать разницу между задержкой в сети и преднамеренным разделением данных.

Вам может понадобиться использовать сетевой API более низкого уровня, такой как CFSocket, как вы упомянули (у вас будет доступ к каждому байту, который поступает из сетевого интерфейса, и вы можете различить две части вашей полезной нагрузки), или вы можете взять посмотрите на библиотеку какCURL и посмотрите, какие существуют типы буферизации / небуферизации вывода.

 15 июл. 2009 г., 19:54
Рад, что в итоге получилось!
 pix0r13 июл. 2009 г., 19:01
Это то, чего я боялся. Я думаю, что я пойду с CocoaAsyncSocket, а не имею дело с CFSocket самостоятельно.
 18 апр. 2013 г., 01:14
Самое простое решение - сделать текст / json ответом в виде содержимого, см.stackoverflow.com/a/14828690/371793
 pix0r15 июл. 2009 г., 19:36
Для справки, CocoaAsyncSocket прекрасно работал, хотя потребовался дополнительный час или два, чтобы все работало правильно.
 23 мая 2013 г., 14:11
Для тех, кто нажимает на эту тему, пытаясь слушать CouchDB_changes feed: просто отправьте заголовок accept сAccept: application/json ([request addValue:@"application/json" forHTTPHeaderField:@"Accept"]) и вы получите документы обратно, как только они будут опубликованы в ленте.

Существует еще одна реализация HTTP API с именем ASIHttpRequest. Он не имеет проблемы, указанной выше, и предоставляет полный набор инструментов практически для каждой функции HTTP, включая загрузку файлов, файлы cookie, аутентификацию и т. Д.

http://allseeing-i.com/ASIHTTPRequest/

 28 окт. 2010 г., 08:00
И в отличие от прокрутки, ASIHttpRequest, похоже, обрабатывает прокси-серверы HTTP, аутентификацию и т. Д., Которые вы теряете, если решите "эй, это просто сокетное соединение плюс отправка нескольких заголовков, насколько это может быть сложно" :) Одна из основных причин использования COMET поверх TCP или UDP заключается в том, что он проходит через фашистские корпоративные брандмауэры.

Я столкнулся с этим сегодня. Я написал свой собственный класс для обработки этого, который имитирует основные функциональные возможности NSURLConnection.

http://github.com/nall/SZUtilities/blob/master/SZURLConnection.h

В настоящее время мы проводим некоторые исследования и разработки для переноса наших кометных библиотек StreamLink на iPhone.

Я обнаружил, что в эмуляторе вы начнете получать обратные вызовы didReceiveData после получения 1 КБ данных. Таким образом, вы можете отправить ненужный блок размером 1 КБ, чтобы начать получать обратные вызовы. Похоже, что на устройстве этого не происходит. В сафари (на устройстве) вам нужно отправить 2 КБ, но с помощью NSURLConnection я тоже не получаю обратных вызовов. Похоже, мне, возможно, придется принять тот же подход.

Я мог бы также поиграть с multipart-replace и некоторыми другими, более новыми заголовками и типами mime, чтобы посмотреть, поможет ли это стимулировать NSURLConnection.

 pix0r22 июл. 2009 г., 23:26
Я действительно рекомендую вместо этого использовать CocoaAsyncSocket - достаточно просто реализовать основные HTTP-команды самостоятельно, если они вам нужны. Кто знает, как Apple может изменить NSURLConnection в будущем ...

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

Вы можете использовать такой инструмент, как Wireshark, чтобы понюхать вашу сеть.

Другой вариант просмотра того, что отправляется / принимается на телефон или с него, описан в следующей статье:

http://blog.jerodsanto.net/2009/06/sniff-your-iphones-network-traffic/

Удачи!

 pix0r13 июл. 2009 г., 19:00
Я могу подключиться через telnet и убедиться, что данные поступают постепенно, как и ожидалось. Похоже, NSURLConnection всегда буферизует данные, как упоминал Мэтт.

Ваш ответ на вопрос