Long polling with NSURLConnection

Question

I'm working on an iPhone application which will use long-polling to send event notifications from the server to the client over HTTP. After opening a connection on the server I'm sending small bits of JSON that represent events, as they occur. I am finding that -[NSURLConnectionDelegate connection:didReceiveData] is not being called until after I close the connection, regardless of the cache settings I use when creating the NSURLRequest. I've verified that the server end is working as expected - the first JSON event will be sent immediately, and subsequent events will be sent over the wire as they occur. Is there a way to use NSURLConnection to receive these events as they occur, or will I need to instead drop down to the CFSocket API?

I'm starting to work on integrating CocoaAsyncSocket, but would prefer to continue using NSURLConnection if possible as it fits much better with the rest of my REST/JSON-based web service structure.

Madid

Hey, I saw that you used asyncsocket to get the desired result. Any chance I could pick your brains about this sometime? I'm @suprfrends on twitter. It would be GREATLY appreciated! – Gayl

I was able to figure this out .... check out: #1293526 – Aventine

I found a solution for it, see my reply here: #1293526 – Aventine

Here's a workaround that I found after a lot of pain :) #1293526 – Aventine

Answer 1

NSURLConnection will buffer the data while it is downloading and give it all back to you in one chunk with the didReceiveData method. The NSURLConnection class can't tell the difference between network lag and an intentional split in the data.

You would either need to use a lower-level network API like CFSocket as you mention (you would have access to each byte as it comes in from the network interface, and could distinguish the two parts of your payload), or you could take a look at a library like CURL and see what types of output buffering/non-buffering there is there.

Ceyx

This is what I was afraid of. I think I'll go with CocoaAsyncSocket rather than deal with CFSocket myself. – Madid

For the record, CocoaAsyncSocket ended up working great, though it took an extra hour or two to get everything working properly. – Madid

The easiest fix is to make the response have text/json as content-type, see https://mcmap.net/q/901587/-http-connection-with-nsurlconnection-in-iphone – Pall

For anyone hitting this thread while trying to listen to the CouchDB _changes feed: just send the accept header with Accept: application/json ([request addValue:@"application/json" forHTTPHeaderField:@"Accept"]) and you will get documents back as soon as they're posted to the stream. – Golliner

Answer 2

I ran into this today. I wrote my own class to handle this, which mimics the basic functionality of NSURLConnection.

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

Latashialatch

Answer 3

It sounds as if you need to flush the socket on the server-side, although it's really difficult to say for sure. If you can't easily change the server to do that, then it may help to sniff the network connection to see when stuff is actually getting sent from the server.

You can use a tool like Wireshark to sniff your network.

Another option for seeing what's getting sent/received to/from the phone is described in the following article:

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

Good luck!

Bord

I can connect via telnet and verify that the data is coming down incrementally, as expected. It sounds like NSURLConnection always buffers the data as Matt mentioned. – Madid

Answer 4

We're currently doing some R&D to port our StreamLink comet libraries to the iPhone.

I have found that in the emulator you will start to get didReceiveData callbacks once 1KB of data is received. So you can send a junk 1KB block to start getting callbacks. It seems that on the device, however, this doesn't happen. In safari (on device) you need to send 2KB, but using NSURLConnection I too am getting no callbacks. Looks like I may have to take the same approach.

I might also play with multipart-replace and some other more novel headers and mime types to see if it helps stimulate NSURLConnection.

Breadthways

I'd really recommend using CocoaAsyncSocket instead - it's simple enough to implement the basic HTTP commands yourself if you need them. Who knows how Apple might change NSURLConnection in the future... – Madid

Answer 5

There is another HTTP API Implementation named ASIHttpRequest. It doesn't have the problem stated above and provides a complete toolkit for almost every HTTP feature, including File Uploads, Cookies, Authentication, ...

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

Clarabelle

And unlike rolling it yourself ASIHttpRequest seems to handle HTTP proxies, authentication, etc, all of which you lose if you decide "hey, it's just a socket connection plus sending a few headers, how hard can it be?" :)One of the main reasons to use COMET over TCP or UDP is that it goes through fascist corporate firewalls. – Snyder