iOS and OS X Network Programming Cookbook: If you want to develop network applications for iOS and OS X, this is one of the few books written specifically for those systems. With over 50 recipes and in-depth explanations, it's an essential guide.

The primary API behind Apple's low-level networking is the CFNetwork API.

The simplest way to describe CFNetworking is to say that it is an Apple-specific extension to the BSD socket API. The CFNetworking stack is based on and relies on the BSD socket API that was discussed in Chapter 1, BSD Socket Library. It is recommended that the reader understands the concepts discussed in Chapter 1, BSD Socket Library, prior to going through this chapter. While this chapter will focus primarily on CFNetworking for most of the recipes, we will also use NSHost and the system configuration framework for retrieving network address information and checking the network status recipes. The biggest advantage that BSD sockets have over CFNetwork is the compatibility with other forms of Unix. This is a pretty big advantage when you think of all the BSD socket code on the Internet that you can use. However, if your application is Apple-specific, it is recommended that you use CFNetwork wherever you...

Most applications that communicate over a network will eventually need to know the information from the available network interfaces of the device they are running on. This recipe will show you how to retrieve the network addresses for all the active network interfaces on the device.

This recipe will use the NSHost class to retrieve a list of addresses on your local device. While NSHost is available on iOS, it is a private (undocumented) class. It is also noted on a number of forum posts that Apple has rejected iOS apps for using NSHost. If you need to retrieve network address information within an iOS application, it is recommended that you use the Retrieving network address information recipe from Chapter 1, BSD Socket Library, in this book, and not the NSHost class described in this recipe.

Most applications that use the Internet to communicate will eventually need to convert a hostname to an IP address or an IP address to a hostname. This recipe will encapsulate the network address resolution functionality into a standalone Objective-C class. You will notice in this recipe that most of the CFNetworking API calls are made up of C functions, and use a structure similar to the addrinfo structure that the BSD API uses.

#import <Foundation/Foundation.h>

typedef NS_ENUM(NSUInteger, CFNetworkingSelf.errorCode) {
  NOERROR,
  HOSTRESOLUTIONERROR,
  ADDRESSRESOLUTIONERROR
};
@interface CFNetworkUtilities : NSObject

@property int (nonatomic) self.errorCode;

-(NSArray *)addressesForHostname...

In this recipe, we will be creating an echo server that will listen on a specified port. Once a connection is established, the server will echo any text received back by the client.

There are several ways to create a CFSocket. For this recipe, we will create a BSD socket and then use the CFSocketCreateWithNative() method to create the CFSocket from the native BSD socket.

To create a BSD socket, you must first create a socket using the socket() function. This function returns an integer descriptor that can be used to identify the socket for all future function calls. Once we have the socket descriptor, we need to bind the network interfaces and port to the socket. We create a sockaddr structure with the IP address version, IP address, and the port number to bind the socket. We will then call the bind() function to bind the sockaddr structure and the socket together. Finally, we will need to listen on the socket for new connections. This can be done with the listen()...

In the Creating an echo server recipe of this chapter, we created an echo server using CFNetworking and tested it with the telnet command. In this recipe, we will create an echo client that can be used to test the echo server. Also note that the echo client and server applications created in Chapter 1, BSD Socket Library, can be used interchangeably with the echo client and server applications created in this chapter.

#import <Foundation/Foundation.h>

typedef NS_ENUM(NSUInteger, CFNetworkServerErrorCode) {
  NOERROR,
  SOCKETERROR,
  CONNECTERROR,
  READERROR,
  WRITEERROR
};

#define MAXLINE 4096

@interface CFSocketClient : NSObject  

@property (nonatomic) int errorCode;
@property (nonatomic) CFSocketRef sockfd...

In the Creating an echo server recipe of this chapter, we created an echo server using Apple's CFNetwork API. This server accepted incoming text and echoed it back to the client. That recipe demonstrated how to send and receive text through a socket connection.

This following recipe will demonstrate how to send and receive datafiles such as images through a socket connection. Sending and receiving data over a socket connection with CFNetworking is not that different from sending and receiving text. You basically go through all the same steps to set up the socket, but you finally receive CFData rather than a character array.

We will be updating the CFSocketServer class from the Creating an echo server recipe of this chapter, to handle both our echo and data servers depending on the flag you set.

In the Creating a data server recipe from Chapter 1, BSD Socket Library, we created a server that can receive incoming data. In this recipe, we will create a client application that will send images to that server.

Also note that the data client and server applications created in Chapter 1, BSD Socket Library, can be used interchangeably with the data client and server applications created in this chapter.

We will be expanding the CFSocketClient class that we wrote in the Creating a data client recipe from Chapter 1, BSD Socket Library, to handle both the echo client and the data client.

#import <Foundation/Foundation.h>

typedef NS_ENUM(NSUInteger, CFNetworkClientErrorCode) {
  NOERRROR,
  SOCKETERROR,
  CONNECTERROR...

Any time you create an iOS application that communicates to other devices over the Internet, you will eventually need to verify that you have a connection prior to making your network calls. This can be done pretty easily by verifying that the address we are trying to connect is reachable, but only lets you know if you have a network connection or not.

When you write applications that communicate with mobile devices over the Internet, one of the things you need to keep in mind is that your users probably have a data plan that limits the amount of data they can send in a month. If they exceed that limit, they may have to pay an extra fee. If your application sends large amounts of data, it would be good to know what type of network connection the user currently has; if it is a mobile connection (as opposed to a Wi-Fi connection), warn the user prior to sending the data.

This recipe will check the type of network connection our device has. For this project, we will...