FWAsyncSocket

• FWAsyncSocket uses the standard delegate paradigm,
• but executes all delegate callbacks on a given delegate dispatch queue.
• This allows for maximum concurrency, while at the same time providing easy thread safety.
• You MUST set a delegate AND delegate dispatch queue before attempting to
• use the socket, or you will get an error.
• The socket queue is optional.
• If you pass NULL, FWAsyncSocket will automatically create it’s own socket queue.
• If you choose to provide a socket queue, the socket queue must not be a concurrent queue.
• If you choose to provide a socket queue, and the socket queue has a configured target queue,
• then please see the discussion for the method markSocketQueueTargetQueue.
• The delegate queue and socket queue can optionally be the same.

Undocumented

Undocumented

Undocumented

• Create FWAsyncSocket from already connect BSD socket file descriptor

Undocumented

Undocumented

Undocumented

Undocumented

Undocumented

Undocumented

• If you are setting the delegate to nil within the delegate’s dealloc method,
• you may need to use the synchronous versions below.

Undocumented

Undocumented

• By default, both IPv4 and IPv6 are enabled.
• For accepting incoming connections, this means FWAsyncSocket automatically supports both protocols,
• and can simulataneously accept incoming connections on either protocol.
• For outgoing connections, this means FWAsyncSocket can connect to remote hosts running either protocol.
• If a DNS lookup returns only IPv4 results, FWAsyncSocket will automatically use IPv4.
• If a DNS lookup returns only IPv6 results, FWAsyncSocket will automatically use IPv6.
• If a DNS lookup returns both IPv4 and IPv6 results, the preferred protocol will be chosen.
• By default, the preferred protocol is IPv4, but may be configured as desired.

Undocumented

Undocumented

• When connecting to both IPv4 and IPv6 using Happy Eyeballs (RFC 6555) https://tools.ietf.org/html/rfc6555
• this is the delay between connecting to the preferred protocol and the fallback protocol. *
• Defaults to 300ms.

• User data allows you to associate arbitrary information with the socket.
• This data is not used internally by socket in any way.

• Tells the socket to begin listening and accepting connections on the given port.
• When a connection is accepted, a new instance of FWAsyncSocket will be spawned to handle it,
• and the socket:didAcceptNewSocket: delegate method will be invoked.
• The socket will listen on all available interfaces (e.g. wifi, ethernet, etc)

• This method is the same as acceptOnPort:error: with the
• additional option of specifying which interface to listen on.
• For example, you could specify that the socket should only accept connections over ethernet,
• and not other interfaces such as wifi.
• The interface may be specified by name (e.g. “en1” or “lo0”) or by IP address (e.g. “192.168.4.34”).
• You may also use the special strings “localhost” or “loopback” to specify that
• the socket only accept connections from the local machine.
• You can see the list of interfaces via the command line utility “ifconfig”,
• or programmatically via the getifaddrs() function.
• To accept connections on any interface pass nil, or simply use the acceptOnPort:error: method.

Tells the socket to begin listening and accepting connections on the unix domain at the given url. When a connection is accepted, a new instance of FWAsyncSocket will be spawned to handle it, and the socket:didAcceptNewSocket: delegate method will be invoked.

The socket will listen on all available interfaces (e.g. wifi, ethernet, etc)

• Connects to the given host and port.
• This method invokes connectToHost:onPort:viaInterface:withTimeout:error:
• and uses the default interface, and no timeout.

• Connects to the given host and port with an optional timeout.
• This method invokes connectToHost:onPort:viaInterface:withTimeout:error: and uses the default interface.

• Connects to the given host & port, via the optional interface, with an optional timeout.
• The host may be a domain name (e.g. “deusty.com”) or an IP address string (e.g. “192.168.0.2”).
• The host may also be the special strings “localhost” or “loopback” to specify connecting
• to a service on the local machine.
• The interface may be a name (e.g. “en1” or “lo0”) or the corresponding IP address (e.g. “192.168.4.35”).
• The interface may also be used to specify the local port (see below).
• To not time out use a negative time interval.
• This method will return NO if an error is detected, and set the error pointer (if one was given).
• Possible errors would be a nil host, invalid interface, or socket is already connected.
• If no errors are detected, this method will start a background connect operation and immediately return YES.
• The delegate callbacks are used to notify you when the socket connects, or if the host was unreachable.

• All read/write operations will be queued, and upon socket connection,
• the operations will be dequeued and processed in order.
• The interface may optionally contain a port number at the end of the string, separated by a colon.
• This allows you to specify the local port that should be used for the outgoing connection. (read paragraph to end)
• To specify both interface and local port: “en1:8082” or “192.168.4.35:2424”.
• To specify only local port: “:8082”.
• Please note this is an advanced feature, and is somewhat hidden on purpose.
• You should understand that 99.999% of the time you should NOT specify the local port for an outgoing connection.
• If you think you need to, there is a very good chance you have a fundamental misunderstanding somewhere.
• Local ports do NOT need to match remote ports. In fact, they almost never do.
• This feature is here for networking professionals using very advanced techniques.

• Connects to the given address, specified as a sockaddr structure wrapped in a NSData object.
• For example, a NSData object returned from NSNetService’s addresses method.
• If you have an existing struct sockaddr you can convert it to a NSData object like so:
• struct sockaddr sa -> NSData *dsa = [NSData dataWithBytes:&remoteAddr length:remoteAddr.sa_len];
• struct sockaddr *sa -> NSData *dsa = [NSData dataWithBytes:remoteAddr length:remoteAddr->sa_len];
• This method invokes connectToAddress:remoteAddr viaInterface:nil withTimeout:-1 error:errPtr.

• This method is the same as connectToAddress:error: with an additional timeout option.
• To not time out use a negative time interval, or simply use the connectToAddress:error: method.

• Connects to the given address, using the specified interface and timeout.
• The address is specified as a sockaddr structure wrapped in a NSData object.
• For example, a NSData object returned from NSNetService’s addresses method.
• If you have an existing struct sockaddr you can convert it to a NSData object like so:
• struct sockaddr sa -> NSData *dsa = [NSData dataWithBytes:&remoteAddr length:remoteAddr.sa_len];
• struct sockaddr *sa -> NSData *dsa = [NSData dataWithBytes:remoteAddr length:remoteAddr->sa_len];
• The interface may be a name (e.g. “en1” or “lo0”) or the corresponding IP address (e.g. “192.168.4.35”).
• The interface may also be used to specify the local port (see below).
• The timeout is optional. To not time out use a negative time interval.
• This method will return NO if an error is detected, and set the error pointer (if one was given).
• Possible errors would be a nil host, invalid interface, or socket is already connected.
• If no errors are detected, this method will start a background connect operation and immediately return YES.
• The delegate callbacks are used to notify you when the socket connects, or if the host was unreachable.

• All read/write operations will be queued, and upon socket connection,
• the operations will be dequeued and processed in order.
• The interface may optionally contain a port number at the end of the string, separated by a colon.
• This allows you to specify the local port that should be used for the outgoing connection. (read paragraph to end)
• To specify both interface and local port: “en1:8082” or “192.168.4.35:2424”.
• To specify only local port: “:8082”.
• Please note this is an advanced feature, and is somewhat hidden on purpose.
• You should understand that 99.999% of the time you should NOT specify the local port for an outgoing connection.
• If you think you need to, there is a very good chance you have a fundamental misunderstanding somewhere.
• Local ports do NOT need to match remote ports. In fact, they almost never do.
• This feature is here for networking professionals using very advanced techniques.

Connects to the unix domain socket at the given url, using the specified timeout.

Iterates over the given NetService’s addresses in order, and invokes connectToAddress:error:. Stops at the first invocation that succeeds and returns YES; otherwise returns NO.

• Disconnects immediately (synchronously). Any pending reads or writes are dropped.
• If the socket is not already disconnected, an invocation to the socketDidDisconnect:withError: delegate method
• will be queued onto the delegateQueue asynchronously (behind any previously queued delegate methods).
• In other words, the disconnected delegate method will be invoked sometime shortly after this method returns.
• Please note the recommended way of releasing a FWAsyncSocket instance (e.g. in a dealloc method)
• [asyncSocket setDelegate:nil];
• [asyncSocket disconnect];
• [asyncSocket release];
• If you plan on disconnecting the socket, and then immediately asking it to connect again,
• you’ll likely want to do so like this:
• [asyncSocket setDelegate:nil];
• [asyncSocket disconnect];
• [asyncSocket setDelegate:self];
• [asyncSocket connect…];

• Disconnects after all pending reads have completed.
• After calling this, the read and write methods will do nothing.
• The socket will disconnect even if there are still pending writes.

• Disconnects after all pending writes have completed.
• After calling this, the read and write methods will do nothing.
• The socket will disconnect even if there are still pending reads.

• Disconnects after all pending reads and writes have completed.
• After calling this, the read and write methods will do nothing.

• A disconnected socket may be recycled.
• That is, it can be used again for connecting or listening.
• If a socket is in the process of connecting, it may be neither disconnected nor connected.

Undocumented

• The host will be an IP address.

Undocumented

Undocumented

Undocumented

Undocumented

• specified as a sockaddr structure wrapped in a NSData object.
• @seealso connectedHost
• @seealso connectedPort
• @seealso localHost
• @seealso localPort

Undocumented

• An accepting socket may be both.

Undocumented

• Reads the first available bytes that become available on the socket.
• If the timeout value is negative, the read operation will not use a timeout.

• Reads the first available bytes that become available on the socket.
• The bytes will be appended to the given byte buffer starting at the given offset.
• The given buffer will automatically be increased in size if needed.
• If the timeout value is negative, the read operation will not use a timeout.
• If the buffer is nil, the socket will create a buffer for you.
• If the bufferOffset is greater than the length of the given buffer,
• the method will do nothing, and the delegate will not be called.
• If you pass a buffer, you must not alter it in any way while the socket is using it.
• After completion, the data returned in socket:didReadData:withTag: will be a subset of the given buffer.
• That is, it will reference the bytes that were appended to the given buffer via
• the method [NSData dataWithBytesNoCopy:length:freeWhenDone:NO].

• Reads the first available bytes that become available on the socket.
• The bytes will be appended to the given byte buffer starting at the given offset.
• The given buffer will automatically be increased in size if needed.
• A maximum of length bytes will be read.
• If the timeout value is negative, the read operation will not use a timeout.
• If the buffer is nil, a buffer will automatically be created for you.
• If maxLength is zero, no length restriction is enforced.
• If the bufferOffset is greater than the length of the given buffer,
• the method will do nothing, and the delegate will not be called.
• If you pass a buffer, you must not alter it in any way while the socket is using it.
• After completion, the data returned in socket:didReadData:withTag: will be a subset of the given buffer.
• That is, it will reference the bytes that were appended to the given buffer via
• the method [NSData dataWithBytesNoCopy:length:freeWhenDone:NO].

• Reads the given number of bytes.
• If the timeout value is negative, the read operation will not use a timeout.
• If the length is 0, this method does nothing and the delegate is not called.

• Reads the given number of bytes.
• The bytes will be appended to the given byte buffer starting at the given offset.
• The given buffer will automatically be increased in size if needed.
• If the timeout value is negative, the read operation will not use a timeout.
• If the buffer is nil, a buffer will automatically be created for you.
• If the length is 0, this method does nothing and the delegate is not called.
• If the bufferOffset is greater than the length of the given buffer,
• the method will do nothing, and the delegate will not be called.
• If you pass a buffer, you must not alter it in any way while AsyncSocket is using it.
• After completion, the data returned in socket:didReadData:withTag: will be a subset of the given buffer.
• That is, it will reference the bytes that were appended to the given buffer via
• the method [NSData dataWithBytesNoCopy:length:freeWhenDone:NO].

• Reads bytes until (and including) the passed “data” parameter, which acts as a separator.
• If the timeout value is negative, the read operation will not use a timeout.
• If you pass nil or zero-length data as the “data” parameter,
• the method will do nothing (except maybe print a warning), and the delegate will not be called.
• To read a line from the socket, use the line separator (e.g. CRLF for HTTP, see below) as the “data” parameter.
• If you’re developing your own custom protocol, be sure your separator can not occur naturally as
• part of the data between separators.
• For example, imagine you want to send several small documents over a socket.
• Using CRLF as a separator is likely unwise, as a CRLF could easily exist within the documents.
• In this particular example, it would be better to use a protocol similar to HTTP with
• a header that includes the length of the document.
• Also be careful that your separator cannot occur naturally as part of the encoding for a character.
• The given data (separator) parameter should be immutable.
• For performance reasons, the socket will retain it, not copy it.
• So if it is immutable, don’t modify it while the socket is using it.

• Reads bytes until (and including) the passed “data” parameter, which acts as a separator.
• The bytes will be appended to the given byte buffer starting at the given offset.
• The given buffer will automatically be increased in size if needed.
• If the timeout value is negative, the read operation will not use a timeout.
• If the buffer is nil, a buffer will automatically be created for you.
• If the bufferOffset is greater than the length of the given buffer,
• the method will do nothing (except maybe print a warning), and the delegate will not be called.
• If you pass a buffer, you must not alter it in any way while the socket is using it.
• After completion, the data returned in socket:didReadData:withTag: will be a subset of the given buffer.
• That is, it will reference the bytes that were appended to the given buffer via
• the method [NSData dataWithBytesNoCopy:length:freeWhenDone:NO].
• To read a line from the socket, use the line separator (e.g. CRLF for HTTP, see below) as the “data” parameter.
• If you’re developing your own custom protocol, be sure your separator can not occur naturally as
• part of the data between separators.
• For example, imagine you want to send several small documents over a socket.
• Using CRLF as a separator is likely unwise, as a CRLF could easily exist within the documents.
• In this particular example, it would be better to use a protocol similar to HTTP with
• a header that includes the length of the document.
• Also be careful that your separator cannot occur naturally as part of the encoding for a character.
• The given data (separator) parameter should be immutable.
• For performance reasons, the socket will retain it, not copy it.
• So if it is immutable, don’t modify it while the socket is using it.

• Reads bytes until (and including) the passed “data” parameter, which acts as a separator.
• If the timeout value is negative, the read operation will not use a timeout.
• If maxLength is zero, no length restriction is enforced.
• Otherwise if maxLength bytes are read without completing the read,
• it is treated similarly to a timeout - the socket is closed with a FWAsyncSocketReadMaxedOutError.
• The read will complete successfully if exactly maxLength bytes are read and the given data is found at the end.
• If you pass nil or zero-length data as the “data” parameter,
• the method will do nothing (except maybe print a warning), and the delegate will not be called.
• If you pass a maxLength parameter that is less than the length of the data parameter,
• the method will do nothing (except maybe print a warning), and the delegate will not be called.
• To read a line from the socket, use the line separator (e.g. CRLF for HTTP, see below) as the “data” parameter.
• If you’re developing your own custom protocol, be sure your separator can not occur naturally as
• part of the data between separators.
• For example, imagine you want to send several small documents over a socket.
• Using CRLF as a separator is likely unwise, as a CRLF could easily exist within the documents.
• In this particular example, it would be better to use a protocol similar to HTTP with
• a header that includes the length of the document.
• Also be careful that your separator cannot occur naturally as part of the encoding for a character.
• The given data (separator) parameter should be immutable.
• For performance reasons, the socket will retain it, not copy it.
• So if it is immutable, don’t modify it while the socket is using it.

• Reads bytes until (and including) the passed “data” parameter, which acts as a separator.
• The bytes will be appended to the given byte buffer starting at the given offset.
• The given buffer will automatically be increased in size if needed.
• If the timeout value is negative, the read operation will not use a timeout.
• If the buffer is nil, a buffer will automatically be created for you.
• If maxLength is zero, no length restriction is enforced.
• Otherwise if maxLength bytes are read without completing the read,
• it is treated similarly to a timeout - the socket is closed with a FWAsyncSocketReadMaxedOutError.
• The read will complete successfully if exactly maxLength bytes are read and the given data is found at the end.
• If you pass a maxLength parameter that is less than the length of the data (separator) parameter,
• the method will do nothing (except maybe print a warning), and the delegate will not be called.
• If the bufferOffset is greater than the length of the given buffer,
• the method will do nothing (except maybe print a warning), and the delegate will not be called.
• If you pass a buffer, you must not alter it in any way while the socket is using it.
• After completion, the data returned in socket:didReadData:withTag: will be a subset of the given buffer.
• That is, it will reference the bytes that were appended to the given buffer via
• the method [NSData dataWithBytesNoCopy:length:freeWhenDone:NO].
• To read a line from the socket, use the line separator (e.g. CRLF for HTTP, see below) as the “data” parameter.
• If you’re developing your own custom protocol, be sure your separator can not occur naturally as
• part of the data between separators.
• For example, imagine you want to send several small documents over a socket.
• Using CRLF as a separator is likely unwise, as a CRLF could easily exist within the documents.
• In this particular example, it would be better to use a protocol similar to HTTP with
• a header that includes the length of the document.
• Also be careful that your separator cannot occur naturally as part of the encoding for a character.
• The given data (separator) parameter should be immutable.
• For performance reasons, the socket will retain it, not copy it.
• So if it is immutable, don’t modify it while the socket is using it.

• The parameters “tag”, “done” and “total” will be filled in if they aren’t NULL.

• Writes data to the socket, and calls the delegate when finished.
• If you pass in nil or zero-length data, this method does nothing and the delegate will not be called.
• If the timeout value is negative, the write operation will not use a timeout.
• Thread-Safety Note:
• If the given data parameter is mutable (NSMutableData) then you MUST NOT alter the data while
• the socket is writing it. In other words, it’s not safe to alter the data until after the delegate method
• socket:didWriteDataWithTag: is invoked signifying that this particular write operation has completed.
• This is due to the fact that FWAsyncSocket does NOT copy the data. It simply retains it.
• This is for performance reasons. Often times, if NSMutableData is passed, it is because
• a request/response was built up in memory. Copying this data adds an unwanted/unneeded overhead.
• If you need to write data from an immutable buffer, and you need to alter the buffer before the socket
• completes writing the bytes (which is NOT immediately after this method returns, but rather at a later time
• when the delegate method notifies you), then you should first copy the bytes, and pass the copy to this method.

• The parameters “tag”, “done” and “total” will be filled in if they aren’t NULL.

• Secures the connection using SSL/TLS.
• This method may be called at any time, and the TLS handshake will occur after all pending reads and writes
• are finished. This allows one the option of sending a protocol dependent StartTLS message, and queuing
• the upgrade to TLS at the same time, without having to wait for the write to finish.
• Any reads or writes scheduled after this method is called will occur over the secured connection. *
• ==== The available TOP-LEVEL KEYS are:
• - FWAsyncSocketManuallyEvaluateTrust
• The value must be of type NSNumber, encapsulating a BOOL value.
• If you set this to YES, then the underlying SecureTransport system will not evaluate the SecTrustRef of the peer.
• Instead it will pause at the moment evaulation would typically occur,
• and allow us to handle the security evaluation however we see fit.
• So FWAsyncSocket will invoke the delegate method socket:shouldTrustPeer: passing the SecTrustRef. *

• Evaluation will be completely up to you during the socket:didReceiveTrust:completionHandler: delegate method. *
• For more information on trust evaluation see:
• Apple’s Technical Note TN2232 - HTTPS Server Trust Evaluation
• https://developer.apple.com/library/ios/technotes/tn2232/_index.html
• 
  
• If unspecified, the default value is NO. *
• - FWAsyncSocketUseCFStreamForTLS (iOS only)
• The value must be of type NSNumber, encapsulating a BOOL value.
• By default FWAsyncSocket will use the SecureTransport layer to perform encryption.
• This gives us more control over the security protocol (many more configuration options),
• plus it allows us to optimize things like sys calls and buffer allocation.
• 
  
• However, if you absolutely must, you can instruct FWAsyncSocket to use the old-fashioned encryption
• technique by going through the CFStream instead. So instead of using SecureTransport, FWAsyncSocket
• will instead setup a CFRead/CFWriteStream. And then set the kCFStreamPropertySSLSettings property
• (via CFReadStreamSetProperty / CFWriteStreamSetProperty) and will pass the given options to this method.
• 
  
• Thus all the other keys in the given dictionary will be ignored by FWAsyncSocket,
• and will passed directly CFReadStreamSetProperty / CFWriteStreamSetProperty.
• For more infomation on these keys, please see the documentation for kCFStreamPropertySSLSettings. *
• If unspecified, the default value is NO. *
• ==== The available CONFIGURATION KEYS are: *
• - kCFStreamSSLPeerName
• The value must be of type NSString.
• It should match the name in the X.509 certificate given by the remote party.

• - kCFStreamSSLCertificates
• The value must be of type NSArray.

• - kCFStreamSSLIsServer
• The value must be of type NSNumber, encapsulationg a BOOL value.

• This is optional for iOS. If not supplied, a NO value is the default.
• This is not needed for Mac OS X, and the value is ignored. *
• - FWAsyncSocketSSLPeerID
• The value must be of type NSData.
• You must set this value if you want to use TLS session resumption.

• - FWAsyncSocketSSLProtocolVersionMin
• - FWAsyncSocketSSLProtocolVersionMax
• The value(s) must be of type NSNumber, encapsulting a SSLProtocol value.

• - FWAsyncSocketSSLSessionOptionFalseStart
• The value must be of type NSNumber, encapsulating a BOOL value.

• - FWAsyncSocketSSLSessionOptionSendOneByteRecord
• The value must be of type NSNumber, encapsulating a BOOL value.

• - FWAsyncSocketSSLCipherSuites
• The values must be of type NSArray.
• Each item within the array must be a NSNumber, encapsulating an SSLCipherSuite.

• - FWAsyncSocketSSLDiffieHellmanParameters (Mac OS X only)
• The value must be of type NSData.

• ==== The following UNAVAILABLE KEYS are: (with throw an exception)
• - kCFStreamSSLAllowsAnyRoot (UNAVAILABLE)
• You MUST use manual trust evaluation instead (see FWAsyncSocketManuallyEvaluateTrust).
• Corresponding deprecated method: SSLSetAllowsAnyRoot
• - kCFStreamSSLAllowsExpiredRoots (UNAVAILABLE)
• You MUST use manual trust evaluation instead (see FWAsyncSocketManuallyEvaluateTrust).
• Corresponding deprecated method: SSLSetAllowsExpiredRoots *
• - kCFStreamSSLAllowsExpiredCertificates (UNAVAILABLE)
• You MUST use manual trust evaluation instead (see FWAsyncSocketManuallyEvaluateTrust).
• Corresponding deprecated method: SSLSetAllowsExpiredCerts *
• - kCFStreamSSLValidatesCertificateChain (UNAVAILABLE)
• You MUST use manual trust evaluation instead (see FWAsyncSocketManuallyEvaluateTrust).
• Corresponding deprecated method: SSLSetEnableCertVerify *
• - kCFStreamSSLLevel (UNAVAILABLE)
• You MUST use FWAsyncSocketSSLProtocolVersionMin & FWAsyncSocketSSLProtocolVersionMin instead.
• Corresponding deprecated method: SSLSetProtocolVersionEnabled *
• Please refer to Apple’s documentation for corresponding SSLFunctions. *
• If you pass in nil or an empty dictionary, the default settings will be used.

• The default settings will check to make sure the remote party’s certificate is signed by a
• trusted 3rd party certificate agency (e.g. verisign) and that the certificate is not expired.
• However it will not verify the name on the certificate unless you
• give it a name to verify against via the kCFStreamSSLPeerName key.
• The security implications of this are important to understand.
• Imagine you are attempting to create a secure connection to MySecureServer.com,
• but your socket gets directed to MaliciousServer.com because of a hacked DNS server.
• If you simply use the default settings, and MaliciousServer.com has a valid certificate,
• the default settings will not detect any problems since the certificate is valid.
• To properly secure your connection in this particular scenario you
• should set the kCFStreamSSLPeerName property to “MySecureServer.com”.
• You can also perform additional validation in socketDidSecure.

• Traditionally sockets are not closed until the conversation is over.
• However, it is technically possible for the remote enpoint to close its write stream.
• Our socket would then be notified that there is no more data to be read,
• but our socket would still be writeable and the remote endpoint could continue to receive our data.
• The argument for this confusing functionality stems from the idea that a client could shut down its
• write stream after sending a request to the server, thus notifying the server there are to be no further requests.
• In practice, however, this technique did little to help server developers.
• To make matters worse, from a TCP perspective there is no way to tell the difference from a read stream close
• and a full socket close. They both result in the TCP stack receiving a FIN packet. The only way to tell
• is by continuing to write to the socket. If it was only a read stream close, then writes will continue to work.
• Otherwise an error will be occur shortly (when the remote end sends us a RST packet).
• In addition to the technical challenges and confusion, many high level socket/stream API’s provide
• no support for dealing with the problem. If the read stream is closed, the API immediately declares the
• socket to be closed, and shuts down the write stream as well. In fact, this is what Apple’s CFStream API does.
• It might sound like poor design at first, but in fact it simplifies development.
• The vast majority of the time if the read stream is closed it’s because the remote endpoint closed its socket.
• Thus it actually makes sense to close the socket at this point.
• And in fact this is what most networking developers want and expect to happen.
• However, if you are writing a server that interacts with a plethora of clients,
• you might encounter a client that uses the discouraged technique of shutting down its write stream.
• If this is the case, you can set this property to NO,
• and make use of the socketDidCloseReadStream delegate method.
• The default value is YES.

• FWAsyncSocket maintains thread safety by using an internal serial dispatch_queue.
• In most cases, the instance creates this queue itself.
• However, to allow for maximum flexibility, the internal queue may be passed in the init method.
• This allows for some advanced options such as controlling socket priority via target queues.
• However, when one begins to use target queues like this, they open the door to some specific deadlock issues.
• For example, imagine there are 2 queues:
• dispatch_queue_t socketQueue;
• dispatch_queue_t socketTargetQueue;
• If you do this (pseudo-code):
• socketQueue.targetQueue = socketTargetQueue;
• Then all socketQueue operations will actually get run on the given socketTargetQueue.
• This is fine and works great in most situations.
• But if you run code directly from within the socketTargetQueue that accesses the socket,
• you could potentially get deadlock. Imagine the following code:
• - (BOOL)socketHasSomething
• {
• __block BOOL result = NO;
• dispatch_block_t block = ^{
• result = [self someInternalMethodToBeRunOnlyOnSocketQueue];
• }
• if (is_executing_on_queue(socketQueue))
• block();
• else
• dispatch_sync(socketQueue, block);
• 
  
• return result;
• }
• What happens if you call this method from the socketTargetQueue? The result is deadlock.
• This is because the FW API offers no mechanism to discover a queue’s targetQueue.
• Thus we have no idea if our socketQueue is configured with a targetQueue.
• If we had this information, we could easily avoid deadlock.
• But, since these API’s are missing or unfeasible, you’ll have to explicitly set it.
• IF you pass a socketQueue via the init method,
• AND you’ve configured the passed socketQueue with a targetQueue,
• THEN you should pass the end queue in the target hierarchy.
• For example, consider the following queue hierarchy:
• socketQueue -> ipQueue -> moduleQueue *
• This example demonstrates priority shaping within some server.
• All incoming client connections from the same IP address are executed on the same target queue.
• And all connections for a particular module are executed on the same target queue.
• Thus, the priority of all networking for the entire module can be changed on the fly.
• Additionally, networking traffic from a single IP cannot monopolize the module.
• Here’s how you would accomplish something like that:
• - (dispatch_queue_t)newSocketQueueForConnectionFromAddress:(NSData *)address onSocket:(FWAsyncSocket *)sock
• {
• dispatch_queue_t socketQueue = dispatch_queue_create(“”, NULL);
• dispatch_queue_t ipQueue = [self ipQueueForAddress:address];
• 
  
• dispatch_set_target_queue(socketQueue, ipQueue);
• dispatch_set_target_queue(iqQueue, moduleQueue);
• 
  
• return socketQueue;
• }
• - (void)socket:(FWAsyncSocket *)sock didAcceptNewSocket:(FWAsyncSocket *)newSocket
• {
• [clientConnections addObject:newSocket];
• [newSocket markSocketQueueTargetQueue:moduleQueue];
• }

• This is often NOT the case, as such queues are used solely for execution shaping.

Undocumented

• It’s not thread-safe to access certain variables from outside the socket’s internal queue.
• For example, the socket file descriptor.
• File descriptors are simply integers which reference an index in the per-process file table.
• However, when one requests a new file descriptor (by opening a file or socket),
• the file descriptor returned is guaranteed to be the lowest numbered unused descriptor.
• So if we’re not careful, the following could be possible:
• - Thread A invokes a method which returns the socket’s file descriptor.
• - The socket is closed via the socket’s internal queue on thread B.
• - Thread C opens a file, and subsequently receives the file descriptor that was previously the socket’s FD.
• - Thread A is now accessing/altering the file instead of the socket.
• In addition to this, other variables are not actually objects,
• and thus cannot be retained/released or even autoreleased.
• An example is the sslContext, of type SSLContextRef, which is actually a malloc’d struct.
• Although there are internal variables that make it difficult to maintain thread-safety,
• it is important to provide access to these variables
• to ensure this class can be used in a wide array of environments.
• This method helps to accomplish this by invoking the current block on the socket’s internal queue.
• The methods below can be invoked from within the block to access
• those generally thread-unsafe internal variables in a thread-safe manner.
• The given block will be invoked synchronously on the socket’s internal queue.
• If you save references to any protected variables and use them outside the block, you do so at your own peril.

• These methods are only available from within the context of a performBlock: invocation.

• Provides access to the socket’s file descriptor(s).
• If the socket is a server socket (is accepting incoming connections),
• it might actually have multiple internal socket file descriptors - one for IPv4 and one for IPv6.

Undocumented

Undocumented

• These methods are only available from within the context of a performBlock: invocation.

• Provides access to the socket’s internal CFReadStream/CFWriteStream.
• These streams are only used as workarounds for specific iOS shortcomings:
• - Apple has decided to keep the SecureTransport framework private is iOS.
• This means the only supplied way to do SSL/TLS is via CFStream or some other API layered on top of it.
• Thus, in order to provide SSL/TLS support on iOS we are forced to rely on CFStream,
• instead of the preferred and faster and more powerful SecureTransport.
• - If a socket doesn’t have backgrounding enabled, and that socket is closed while the app is backgrounded,
• Apple only bothers to notify us via the CFStream API.
• The faster and more powerful FW API isn’t notified properly in this case.

Undocumented

• This method is only available from within the context of a performBlock: invocation.

• Configures the socket to allow it to operate when the iOS application has been backgrounded.
• In other words, this method creates a read & write stream, and invokes:
• CFReadStreamSetProperty(readStream, kCFStreamNetworkServiceType, kCFStreamNetworkServiceTypeVoIP);
• CFWriteStreamSetProperty(writeStream, kCFStreamNetworkServiceType, kCFStreamNetworkServiceTypeVoIP);

• That is, if your socket is accepting incoming connections, Apple does not officially support
• allowing iOS applications to accept incoming connections while an app is backgrounded.
• Example usage:
• - (void)socket:(FWAsyncSocket *)sock didConnectToHost:(NSString *)host port:(uint16_t)port
• {
• [asyncSocket performBlock:^{
• [asyncSocket enableBackgroundingOnSocket];
• }];
• }

• This method is only available from within the context of a performBlock: invocation.

• Provides access to the socket’s SSLContext, if SSL/TLS has been started on the socket.

• The address lookup utility used by the class.
• This method is synchronous, so it’s recommended you use it on a background thread/queue.
• The special strings “localhost” and “loopback” return the loopback address for IPv4 and IPv6.
• @returns
• A mutable array with all IPv4 and IPv6 addresses returned by getaddrinfo.
• The addresses are specifically for TCP connections.
• You can filter the addresses, if needed, using the other utility methods provided by the class.

• Extracting host and port information from raw address data.

Undocumented

Undocumented

Undocumented

Undocumented

Undocumented

• A few common line separators, for use with the readDataToData:… methods.

Undocumented

Undocumented

Undocumented