1

Let's say we have an app that displays some kind of dashboard. This dashboard however should be updated extremely often(say at every 500ms). I'm familiar with long pull requests and know how I could implement them with NSURLConnection in some background thread. However it seems this will lead to two big problems - request/response concurrency and overhead of long pull requests at such short time intervals. Although first problem can be solved with some techniques, I think such frequent requests to a server is a general problem.

So after some research I found NSStream class, and it's descedants NSInputStream & NSOutputStream. My idea is to make connection to server and keep it alive for the whole time. And just at 500ms intervals to send GET request at output stream and read data from the input stream.

So here are my questions:

  1. Am I on the right track for implementing this?
  2. Should the server be prepared on some special way of dealing with this kind of connections(I mean won't it drop the connection after some timeout)?
  3. Is there real benefit of skipping connection establishing to improve app performance and to lower refresh time at the dashboard?

UPDATE

I've implemented classic way. When I hit the method for requesting if previous request not yet finished I'm cancelling it. So basically I've only one active connection at a time to prevent concurrency. Also if I didn't receive response for 500ms I do not need this response at all, as it will be outdated anyway. I'm accomplishing pretty neat results in both Wi-Fi and 3G. As I expected on edge there is dropped response every 3 to 4 requests.

Still wondering however about the streams. I did try to follow this apple ref, but when I send HTPP GET via output stream, my input stream return 403 Forbidden from the server. This could be entirely server problem, however I'm not sure if this is the right track and whether it's worthy to change server side.

hris.to
  • 6,235
  • 3
  • 46
  • 55
  • 1
    My hunch is that you are overestimating the overhead, if I were you I would benchmark repeated HTTP requests via NSURLConnection. If you're concerned with bandwidth look at the network traffic with a deep packet sniffer to see how much waste there really is. – nmr Mar 28 '15 at 21:02
  • I agree I could be on the wrong track. Could you please advise me how to run the actual tests? When I just use repeated HTTP requests(500ms interval) on both Wi-Fi and 3G I cannot see dropped response which suites me. However I'm eager to know if there is better alternative :) – hris.to Mar 29 '15 at 17:05
  • 1
    You could use e..g `mach_absolute_time` to measure time inside the app. Network Activity Monitor Instrument (https://developer.apple.com/library/ios/documentation/AnalysisTools/Reference/Instruments_User_Reference/NetworkActivityMonitorInstrument/NetworkActivityMonitorInstrument.html) can show you what traffic looks like. Wireshark can show you what the packet traffic looks like, which will help you reason about how efficient you're being. You might also want to acquaint yourself with "Nagling" and tcp_nodelay – nmr Mar 29 '15 at 20:37

2 Answers2

1

Q1) Am I on the right track for implementing this?

A) I'd suggest WebSockets

Q2)Should the server be prepared on some special way of dealing with this kind of connections(I mean won't it drop the connection after some timeout)?

A)Even though you could try Configuring Persistent(Keep-Alive)Connections on webserver to do it easily I'd suggest WebSockets

Q3)Is there real benefit of skipping connection establishing to improve app performance and to lower refresh time at the dashboard?

A)Yes,Connection opening and closing are costly process that's why there are Keep-alive connection and Google also introduced SPDY for Webapps.so Sockets would solve this problem for you.

WebSockets

is good way to go. Frequent polling is not a way to go because you contact the server very frequently 0.5 seconds

WebSocket provides full-duplex communication.Additionally, WebSocket enables streams of messages on top of TCP. TCP alone deals with streams of bytes with no inherent concept of a message

The WebSocket protocol was standardized by the IETF as RFC 6455 in 2011, and the WebSocket API in Web IDL is being standardized by the W3C

WebSocket is designed to be implemented in web browsers and web servers, but it can be used by any client or server application. The WebSocket Protocol is an independent TCP-based protocol. Its only relationship to HTTP is that its handshake is interpreted by HTTP servers as an Upgrade request. The WebSocket protocol makes more interaction between a browser and a website possible, facilitating live content and the creation of real-time games. This is made possible by providing a standardized way for the server to send content to the browser without being solicited by the client, and allowing for messages to be passed back and forth while keeping the connection open. In this way a two-way (bi-directional) ongoing conversation can take place between a browser and the server

You can find more about WebSockets here

Here are some good WebSocket client libraries on Objective C SocketRocket and UnittWebSocketClient

Note:

These libraries use NSStream

Hope this helps

Durai Amuthan.H
  • 31,670
  • 10
  • 160
  • 241
  • Feel free to ask me If you have any doubts...I am willing to assist you accomplishing this. – Durai Amuthan.H Mar 31 '15 at 06:57
  • I'll try implementing and benchmarking this solution and will write back here with the results. – hris.to Apr 02 '15 at 06:42
  • @hris.to - If you are going to implement in server side For asp.net then SingalR is a good choice for Java atmosphere is a good choice for php php-websocket is a good choice – Durai Amuthan.H Apr 17 '15 at 10:37
-1

As long as your server is HTTP server, server disconnect you after returning result. So, if you want to keep connection alive long enough, you must implement your own protocol based on NSStream/Socket both iOS and Server. You may choose famous socket based protocol like WebSocket, Square's SocketRocket is famous library for iOS based on NSStream.

If your dashboard needs real time update, I think it's worth deploying NSStream/Socket based protocol.

Satachito
  • 5,838
  • 36
  • 43
  • NSURLConnection supports HTTP keep-alive http://stackoverflow.com/a/20250970/580677 (and therefore may not close the socket after the request is complete) – nmr Mar 28 '15 at 20:58