Instance Methods
(instancetype)	- init
	FMLiveSwitchAsyncSocket uses the standard delegate paradigm, but executes all delegate callbacks on a given delegate dispatch queue. More...

(instancetype)	- initWithSocketQueue:

(instancetype)	- initWithDelegate:delegateQueue:

(instancetype)	- initWithDelegate:delegateQueue:socketQueue:

(void)	- getDelegate:delegateQueue:

(void)	- setDelegate:delegateQueue:

(void)	- synchronouslySetDelegate:
	If you are setting the delegate to nil within the delegate's dealloc method, you may need to use the synchronous versions below. More...

(void)	- synchronouslySetDelegateQueue:

(void)	- synchronouslySetDelegate:delegateQueue:

(BOOL)	- acceptOnPort:error:
	Tells the socket to begin listening and accepting connections on the given port. More...

(BOOL)	- acceptOnInterface:port:error:
	This method is the same as acceptOnPort:error: with the additional option of specifying which interface to listen on. More...

(BOOL)	- acceptOnUrl:error:
	Tells the socket to begin listening and accepting connections on the unix domain at the given url. More...

(BOOL)	- connectToHost:onPort:error:
	Connects to the given host and port. More...

(BOOL)	- connectToHost:onPort:withTimeout:error:
	Connects to the given host and port with an optional timeout. More...

(BOOL)	- connectToHost:onPort:viaInterface:withTimeout:error:
	Connects to the given host & port, via the optional interface, with an optional timeout. More...

(BOOL)	- connectToAddress:error:
	Connects to the given address, specified as a sockaddr structure wrapped in a NSData object. More...

(BOOL)	- connectToAddress:withTimeout:error:
	This method is the same as connectToAddress:error: with an additional timeout option. More...

(BOOL)	- connectToAddress:viaInterface:withTimeout:error:
	Connects to the given address, using the specified interface and timeout. More...

(BOOL)	- connectToUrl:withTimeout:error:
	Connects to the unix domain socket at the given url, using the specified timeout. More...

(void)	- disconnect
	Disconnects immediately (synchronously). More...

(void)	- disconnectAfterReading
	Disconnects after all pending reads have completed. More...

(void)	- disconnectAfterWriting
	Disconnects after all pending writes have completed. More...

(void)	- disconnectAfterReadingAndWriting
	Disconnects after all pending reads and writes have completed. More...

(void)	- readDataWithTimeout:tag:
	Reads the first available bytes that become available on the socket. More...

(void)	- readDataWithTimeout:buffer:bufferOffset:tag:
	Reads the first available bytes that become available on the socket. More...

(void)	- readDataWithTimeout:buffer:bufferOffset:maxLength:tag:
	Reads the first available bytes that become available on the socket. More...

(void)	- readDataToLength:withTimeout:tag:
	Reads the given number of bytes. More...

(void)	- readDataToLength:withTimeout:buffer:bufferOffset:tag:
	Reads the given number of bytes. More...

(void)	- readDataToData:withTimeout:tag:
	Reads bytes until (and including) the passed "data" parameter, which acts as a separator. More...

(void)	- readDataToData:withTimeout:buffer:bufferOffset:tag:
	Reads bytes until (and including) the passed "data" parameter, which acts as a separator. More...

(void)	- readDataToData:withTimeout:maxLength:tag:
	Reads bytes until (and including) the passed "data" parameter, which acts as a separator. More...

(void)	- readDataToData:withTimeout:buffer:bufferOffset:maxLength:tag:
	Reads bytes until (and including) the passed "data" parameter, which acts as a separator. More...

(float)	- progressOfReadReturningTag:bytesDone:total:
	Returns progress of the current read, from 0.0 to 1.0, or NaN if no current read (use isnan() to check). More...

(void)	- writeData:withTimeout:tag:
	Writes data to the socket, and calls the delegate when finished. More...

(float)	- progressOfWriteReturningTag:bytesDone:total:
	Returns progress of the current write, from 0.0 to 1.0, or NaN if no current write (use isnan() to check). More...

(void)	- startTLS:
	Secures the connection using SSL/TLS. More...

(void)	- markSocketQueueTargetQueue:
	FMLiveSwitchAsyncSocket maintains thread safety by using an internal serial dispatch_queue. More...

(void)	- unmarkSocketQueueTargetQueue:
	See header file for big discussion of this method. More...

(void)	- performBlock:
	It's not thread-safe to access certain variables from outside the socket's internal queue. More...

(int)	- socketFD
	These methods are only available from within the context of a performBlock: invocation. More...

(int)	- socket4FD
	Questions? Have you read the header file? More...

(int)	- socket6FD
	Questions? Have you read the header file? More...

(nullable CFReadStreamRef)	- readStream
	These methods are only available from within the context of a performBlock: invocation. More...

(nullable CFWriteStreamRef)	- writeStream
	Questions? Have you read the header file? More...

(nullable SSLContextRef)	- sslContext
	This method is only available from within the context of a performBlock: invocation. More...

Class Methods
(bool)	+ attemptDscp
	Class level getter/setter for static _attemptDscp member. More...

(void)	+ setAttemptDscp:

(nullable NSMutableArray *)	+ lookupHost:port:error:
	The address lookup utility used by the class. More...

(nullable NSString *)	+ hostFromAddress:
	Extracting host and port information from raw address data. More...

(uint16_t)	+ portFromAddress:

(BOOL)	+ isIPv4Address:

(BOOL)	+ isIPv6Address:

(BOOL)	+ getHost:port:fromAddress:

(BOOL)	+ getHost:port:family:fromAddress:

(NSData *)	+ CRLFData
	A few common line separators, for use with the readDataToData:... More...

(NSData *)	+ CRData

(NSData *)	+ LFData

(NSData *)	+ ZeroData

Properties
id< FMLiveSwitchAsyncSocketDelegate >	delegate

dispatch_queue_t	delegateQueue

BOOL	IPv4Enabled
	By default, both IPv4 and IPv6 are enabled. More...

BOOL	IPv6Enabled

BOOL	IPv4PreferredOverIPv6

NSTimeInterval	alternateAddressDelay
	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. More...

id	userData
	User data allows you to associate arbitrary information with the socket. More...

BOOL	isDisconnected
	Returns whether the socket is disconnected or connected. More...

BOOL	isConnected

NSString *	connectedHost
	Returns the local or remote host and port to which this socket is connected, or nil and 0 if not connected. More...

uint16_t	connectedPort

NSURL *	connectedUrl

NSString *	localHost

uint16_t	localPort

NSData *	connectedAddress
	Returns the local or remote address to which this socket is connected, specified as a sockaddr structure wrapped in a NSData object. More...

NSData *	localAddress

BOOL	isIPv4
	Returns whether the socket is IPv4 or IPv6. More...

BOOL	isIPv6

BOOL	isSecure
	Returns whether or not the socket has been secured via SSL/TLS. More...

BOOL	autoDisconnectOnClosedReadStream
	Traditionally sockets are not closed until the conversation is over. More...

Method Documentation

◆ acceptOnInterface:port:error:

- (BOOL) acceptOnInterface:	(nullable NSString *)	interface
port:	(uint16_t)	port
error:	(NSError **)	errPtr

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.

◆ acceptOnPort:error:

- (BOOL) acceptOnPort:	(uint16_t)	port
error:	(NSError **)	errPtr

Tells the socket to begin listening and accepting connections on the given port.

When a connection is accepted, a new instance of FMLiveSwitchAsyncSocket 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)

◆ acceptOnUrl:error:

- (BOOL) acceptOnUrl:	(NSURL *)	url
error:	(NSError **)	errPtr

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 FMLiveSwitchAsyncSocket 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)

◆ attemptDscp

+ (bool) attemptDscp

Class level getter/setter for static _attemptDscp member.

◆ connectToAddress:error:

- (BOOL) connectToAddress:	(NSData *)	remoteAddr
error:	(NSError **)	errPtr

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 connectToAdd

◆ connectToAddress:viaInterface:withTimeout:error:

- (BOOL) connectToAddress:	(NSData *)	remoteAddr
viaInterface:	(nullable NSString *)	interface
withTimeout:	(NSTimeInterval)	timeout
error:	(NSError **)	errPtr

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.

Since this class supports queued reads and writes, you can immediately start reading and/or writing. 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.

◆ connectToAddress:withTimeout:error:

- (BOOL) connectToAddress:	(NSData *)	remoteAddr
withTimeout:	(NSTimeInterval)	timeout
error:	(NSError **)	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.

◆ connectToHost:onPort:error:

- (BOOL) connectToHost:	(NSString *)	host
onPort:	(uint16_t)	port
error:	(NSError **)	errPtr

Connects to the given host and port.

This method invokes connectToHost:onPort:viaInterface:withTimeout:error: and uses the default interface, and no timeout.

◆ connectToHost:onPort:viaInterface:withTimeout:error:

- (BOOL) connectToHost:	(NSString *)	host
onPort:	(uint16_t)	port
viaInterface:	(nullable NSString *)	interface
withTimeout:	(NSTimeInterval)	timeout
error:	(NSError **)	errPtr

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.

Since this class supports queued reads and writes, you can immediately start reading and/or writing. 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.

◆ connectToHost:onPort:withTimeout:error:

- (BOOL) connectToHost:	(NSString *)	host
onPort:	(uint16_t)	port
withTimeout:	(NSTimeInterval)	timeout
error:	(NSError **)	errPtr

Connects to the given host and port with an optional timeout.

This method invokes connectToHost:onPort:viaInterface:withTimeout:error: and uses the default interface.

◆ connectToUrl:withTimeout:error:

- (BOOL) connectToUrl:	(NSURL *)	url
withTimeout:	(NSTimeInterval)	timeout
error:	(NSError **)	errPtr

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

◆ CRData

+ (NSData *) CRData

◆ CRLFData

+ (NSData *) CRLFData

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

methods.

◆ disconnect

- (void) disconnect

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 FMLiveSwitchAsyncSocket 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...];

◆ disconnectAfterReading

- (void) disconnectAfterReading

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.

◆ disconnectAfterReadingAndWriting

- (void) disconnectAfterReadingAndWriting

Disconnects after all pending reads and writes have completed.

After calling this, the read and write methods will do nothing.

◆ disconnectAfterWriting

- (void) disconnectAfterWriting

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.

◆ getDelegate:delegateQueue:

- (void) getDelegate:	(id< FMLiveSwitchAsyncSocketDelegate > __nullable *__nullable)	delegatePtr
delegateQueue:	(dispatch_queue_t __nullable *__nullable)	delegateQueuePtr

◆ getHost:port:family:fromAddress:

+ (BOOL) getHost:	(NSString __nullable __nullable)	hostPtr
port:	(nullable uint16_t *)	portPtr
family:	(nullable sa_family_t *)	afPtr
fromAddress:	(NSData *)	address

◆ getHost:port:fromAddress:

+ (BOOL) getHost:	(NSString __nullable __nullable)	hostPtr
port:	(nullable uint16_t *)	portPtr
fromAddress:	(NSData *)	address

◆ hostFromAddress:

+ (NSString *) hostFromAddress: (NSData *) address

Extracting host and port information from raw address data.

◆ init

- (id) init

FMLiveSwitchAsyncSocket 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, FMLiveSwitchAsyncSocket 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.

◆ initWithDelegate:delegateQueue:

- (instancetype) initWithDelegate:	(nullable id< FMLiveSwitchAsyncSocketDelegate >)	aDelegate
delegateQueue:	(nullable dispatch_queue_t)	dq

◆ initWithDelegate:delegateQueue:socketQueue:

- (instancetype) initWithDelegate:	(nullable id< FMLiveSwitchAsyncSocketDelegate >)	aDelegate
delegateQueue:	(nullable dispatch_queue_t)	dq
socketQueue:	(nullable dispatch_queue_t)	sq

◆ initWithSocketQueue:

- (instancetype) initWithSocketQueue: (nullable dispatch_queue_t) sq

◆ isIPv4Address:

+ (BOOL) isIPv4Address: (NSData *) address

◆ isIPv6Address:

+ (BOOL) isIPv6Address: (NSData *) address

◆ LFData

+ (NSData *) LFData

◆ lookupHost:port:error:

+ (NSMutableArray *) lookupHost:	(NSString *)	host
port:	(uint16_t)	port
error:	(NSError **)	errPtr

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.

◆ markSocketQueueTargetQueue:

- (void) markSocketQueueTargetQueue: (dispatch_queue_t) socketQueuesPreConfiguredTargetQueue

FMLiveSwitchAsyncSocket maintains thread safety by using an internal serial dispatch_queue.

See header file for big discussion of this method.

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 FMLiveSwitch 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:(FMLiveSwitchAsyncSocket *)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:(FMLiveSwitchAsyncSocket *)sock didAcceptNewSocket:(FMLiveSwitchAsyncSocket *)newSocket { [clientConnections addObject:newSocket]; [newSocket markSocketQueueTargetQueue:moduleQueue]; }

Note: This workaround is ONLY needed if you intend to execute code directly on the ipQueue or moduleQueue. This is often NOT the case, as such queues are used solely for execution shaping.

◆ performBlock:

- (void) performBlock: (dispatch_block_t) block

It's not thread-safe to access certain variables from outside the socket's internal queue.

See header file for big discussion of this method.

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.

◆ portFromAddress:

+ (uint16_t) portFromAddress: (NSData *) address

◆ progressOfReadReturningTag:bytesDone:total:

- (float) progressOfReadReturningTag:	(nullable long *)	tagPtr
bytesDone:	(nullable NSUInteger *)	donePtr
total:	(nullable NSUInteger *)	totalPtr

Returns progress of the current read, from 0.0 to 1.0, or NaN if no current read (use isnan() to check).

The parameters "tag", "done" and "total" will be filled in if they aren't NULL.

◆ progressOfWriteReturningTag:bytesDone:total:

- (float) progressOfWriteReturningTag:	(nullable long *)	tagPtr
bytesDone:	(nullable NSUInteger *)	donePtr
total:	(nullable NSUInteger *)	totalPtr

Returns progress of the current write, from 0.0 to 1.0, or NaN if no current write (use isnan() to check).

The parameters "tag", "done" and "total" will be filled in if they aren't NULL.

◆ readDataToData:withTimeout:buffer:bufferOffset:maxLength:tag:

- (void) readDataToData:	(NSData *)	data
withTimeout:	(NSTimeInterval)	timeout
buffer:	(nullable NSMutableData *)	buffer
bufferOffset:	(NSUInteger)	offset
maxLength:	(NSUInteger)	length
tag:	(long)	tag

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 if 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 FMLiveSwitchAsyncSocketReadMaxedOutError. 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.

◆ readDataToData:withTimeout:buffer:bufferOffset:tag:

- (void) readDataToData:	(NSData *)	data
withTimeout:	(NSTimeInterval)	timeout
buffer:	(nullable NSMutableData *)	buffer
bufferOffset:	(NSUInteger)	offset
tag:	(long)	tag

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 if 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.

◆ readDataToData:withTimeout:maxLength:tag:

- (void) readDataToData:	(NSData *)	data
withTimeout:	(NSTimeInterval)	timeout
maxLength:	(NSUInteger)	length
tag:	(long)	tag

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 FMLiveSwitchAsyncSocketReadMaxedOutError. 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.

◆ readDataToData:withTimeout:tag:

- (void) readDataToData:	(NSData *)	data
withTimeout:	(NSTimeInterval)	timeout
tag:	(long)	tag

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.

◆ readDataToLength:withTimeout:buffer:bufferOffset:tag:

- (void) readDataToLength:	(NSUInteger)	length
withTimeout:	(NSTimeInterval)	timeout
buffer:	(nullable NSMutableData *)	buffer
bufferOffset:	(NSUInteger)	offset
tag:	(long)	tag

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 if 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].

◆ readDataToLength:withTimeout:tag:

- (void) readDataToLength:	(NSUInteger)	length
withTimeout:	(NSTimeInterval)	timeout
tag:	(long)	tag

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.

◆ readDataWithTimeout:buffer:bufferOffset:maxLength:tag:

- (void) readDataWithTimeout:	(NSTimeInterval)	timeout
buffer:	(nullable NSMutableData *)	buffer
bufferOffset:	(NSUInteger)	offset
maxLength:	(NSUInteger)	length
tag:	(long)	tag

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 if 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].

◆ readDataWithTimeout:buffer:bufferOffset:tag:

- (void) readDataWithTimeout:	(NSTimeInterval)	timeout
buffer:	(nullable NSMutableData *)	buffer
bufferOffset:	(NSUInteger)	offset
tag:	(long)	tag

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 if 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].

◆ readDataWithTimeout:tag:

- (void) readDataWithTimeout:	(NSTimeInterval)	timeout
tag:	(long)	tag

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.

◆ readStream

- (CFReadStreamRef) readStream

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

Questions? Have you read the header file?

See the documentation for the performBlock: method above.

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 FMLiveSwitch API isn't notified properly in this case.

◆ setAttemptDscp:

+ (void) setAttemptDscp: (bool) attemptDscp

◆ setDelegate:delegateQueue:

- (void) setDelegate:	(nullable id< FMLiveSwitchAsyncSocketDelegate >)	delegate
delegateQueue:	(nullable dispatch_queue_t)	delegateQueue

◆ socket4FD

- (int) socket4FD

Questions? Have you read the header file?

◆ socket6FD

- (int) socket6FD

Questions? Have you read the header file?

◆ socketFD

- (int) socketFD

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

Questions? Have you read the header file?

See the documentation for the performBlock: method above.

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.

◆ sslContext

- (SSLContextRef) sslContext

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

See the documentation for the performBlock: method above.

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

◆ startTLS:

- (void) startTLS: (nullable NSDictionary< NSString *, NSObject * > *) tlsSettings

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:

FMLiveSwitchAsyncSocketManuallyEvaluateTrust 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 FMLiveSwitchAsyncSocket will invoke the delegate method socket:shouldTrustPeer: passing the SecTrustRef.

Note that if you set this option, then all other configuration keys are ignored. 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.
FMLiveSwitchAsyncSocketUseCFStreamForTLS (iOS only) The value must be of type NSNumber, encapsulating a BOOL value. By default FMLiveSwitchAsyncSocket 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 FMLiveSwitchAsyncSocket to use the old-fashioned encryption technique by going through the CFStream instead. So instead of using SecureTransport, FMLiveSwitchAsyncSocket 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 FMLiveSwitchAsyncSocket, 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. See Apple's documentation for SSLSetPeerDomainName.
kCFStreamSSLCertificates The value must be of type NSArray. See Apple's documentation for SSLSetCertificate.
kCFStreamSSLIsServer The value must be of type NSNumber, encapsulationg a BOOL value. See Apple's documentation for SSLCreateContext for iOS. 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.
FMLiveSwitchAsyncSocketSSLPeerID The value must be of type NSData. You must set this value if you want to use TLS session resumption. See Apple's documentation for SSLSetPeerID.
FMLiveSwitchAsyncSocketSSLProtocolVersionMin
FMLiveSwitchAsyncSocketSSLProtocolVersionMax The value(s) must be of type NSNumber, encapsulting a SSLProtocol value. See Apple's documentation for SSLSetProtocolVersionMin & SSLSetProtocolVersionMax. See also the SSLProtocol typedef.
FMLiveSwitchAsyncSocketSSLSessionOptionFalseStart The value must be of type NSNumber, encapsulating a BOOL value. See Apple's documentation for kSSLSessionOptionFalseStart.
FMLiveSwitchAsyncSocketSSLSessionOptionSendOneByteRecord The value must be of type NSNumber, encapsulating a BOOL value. See Apple's documentation for kSSLSessionOptionSendOneByteRecord.
FMLiveSwitchAsyncSocketSSLCipherSuites The values must be of type NSArray. Each item within the array must be a NSNumber, encapsulating See Apple's documentation for SSLSetEnabledCiphers. See also the SSLCipherSuite typedef.
FMLiveSwitchAsyncSocketSSLDiffieHellmanParameters (Mac OS X only) The value must be of type NSData. See Apple's documentation for SSLSetDiffieHellmanParams.

==== The following UNAVAILABLE KEYS are: (with throw an exception)

kCFStreamSSLAllowsAnyRoot (UNAVAILABLE) You MUST use manual trust evaluation instead (see FMLiveSwitchAsyncSocketManuallyEvaluateTrust). Corresponding deprecated method: SSLSetAllowsAnyRoot
kCFStreamSSLAllowsExpiredRoots (UNAVAILABLE) You MUST use manual trust evaluation instead (see FMLiveSwitchAsyncSocketManuallyEvaluateTrust). Corresponding deprecated method: SSLSetAllowsExpiredRoots
kCFStreamSSLAllowsExpiredCertificates (UNAVAILABLE) You MUST use manual trust evaluation instead (see FMLiveSwitchAsyncSocketManuallyEvaluateTrust). Corresponding deprecated method: SSLSetAllowsExpiredCerts
kCFStreamSSLValidatesCertificateChain (UNAVAILABLE) You MUST use manual trust evaluation instead (see FMLiveSwitchAsyncSocketManuallyEvaluateTrust). Corresponding deprecated method: SSLSetEnableCertVerify
kCFStreamSSLLevel (UNAVAILABLE) You MUST use FMLiveSwitchAsyncSocketSSLProtocolVersionMin & FMLiveSwitchAsyncSocketSSLProtocolVersionMin 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.

IMPORTANT SECURITY NOTE: 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.

◆ synchronouslySetDelegate:

- (void) synchronouslySetDelegate: (nullable id< FMLiveSwitchAsyncSocketDelegate >) delegate

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

◆ synchronouslySetDelegate:delegateQueue:

- (void) synchronouslySetDelegate:	(nullable id< FMLiveSwitchAsyncSocketDelegate >)	delegate
delegateQueue:	(nullable dispatch_queue_t)	delegateQueue

◆ synchronouslySetDelegateQueue:

- (void) synchronouslySetDelegateQueue: (nullable dispatch_queue_t) delegateQueue

◆ unmarkSocketQueueTargetQueue:

- (void) unmarkSocketQueueTargetQueue: (dispatch_queue_t) socketQueuesPreviouslyConfiguredTargetQueue

See header file for big discussion of this method.

◆ writeData:withTimeout:tag:

- (void) writeData:	(NSData *)	data
withTimeout:	(NSTimeInterval)	timeout
tag:	(long)	tag

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 FMLiveSwitchAsyncSocket 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.

◆ writeStream

- (CFWriteStreamRef) writeStream

Questions? Have you read the header file?

◆ ZeroData

+ (NSData *) ZeroData

Property Documentation

◆ alternateAddressDelay

- (NSTimeInterval) alternateAddressDelay

readwriteatomicassign

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.

◆ autoDisconnectOnClosedReadStream

- (BOOL) autoDisconnectOnClosedReadStream

readwriteatomicassign

Traditionally sockets are not closed until the conversation is over.

See header file for big discussion of this method.

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.

◆ connectedAddress

- (NSData *) connectedAddress

readatomicassign

Returns the local or remote address to which this socket is connected, specified as a sockaddr structure wrapped in a NSData object.

@seealso connectedHost @seealso connectedPort @seealso localHost @seealso localPort

◆ connectedHost

- (NSString *) connectedHost

readatomicassign

Returns the local or remote host and port to which this socket is connected, or nil and 0 if not connected.

The host will be an IP address.

◆ connectedPort

- (uint16_t) connectedPort

readatomicassign

◆ connectedUrl

- (NSURL *) connectedUrl

readatomicassign

◆ delegate

- (id) delegate

readwriteatomicweak

◆ delegateQueue

- (dispatch_queue_t) delegateQueue

readwriteatomicassign

◆ IPv4Enabled

- (BOOL) IPv4Enabled

readwriteatomicassign

By default, both IPv4 and IPv6 are enabled.

For accepting incoming connections, this means FMLiveSwitchAsyncSocket automatically supports both protocols, and can simulataneously accept incoming connections on either protocol.

For outgoing connections, this means FMLiveSwitchAsyncSocket can connect to remote hosts running either protocol. If a DNS lookup returns only IPv4 results, FMLiveSwitchAsyncSocket will automatically use IPv4. If a DNS lookup returns only IPv6 results, FMLiveSwitchAsyncSocket 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.

◆ IPv4PreferredOverIPv6

- (BOOL) IPv4PreferredOverIPv6

readwriteatomicassign

◆ IPv6Enabled

- (BOOL) IPv6Enabled

readwriteatomicassign

◆ isConnected

- (BOOL) isConnected

readatomicassign

◆ isDisconnected

- (BOOL) isDisconnected

readatomicassign

Returns whether the socket is disconnected or connected.

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.

◆ isIPv4

- (BOOL) isIPv4

readatomicassign

Returns whether the socket is IPv4 or IPv6.

An accepting socket may be both.

◆ isIPv6

- (BOOL) isIPv6

readatomicassign

◆ isSecure

- (BOOL) isSecure

readatomicassign

Returns whether or not the socket has been secured via SSL/TLS.

◆ localAddress

- (NSData *) localAddress

readatomicassign

◆ localHost

- (NSString *) localHost

readatomicassign

◆ localPort

- (uint16_t) localPort

readatomicassign

◆ userData

- (id) userData

readwriteatomicstrong

User data allows you to associate arbitrary information with the socket.

This data is not used internally by socket in any way.

Instance Methods

Class Methods

Properties

Method Documentation

◆ acceptOnInterface:port:error:

◆ acceptOnPort:error:

◆ acceptOnUrl:error:

◆ attemptDscp

◆ connectToAddress:error:

◆ connectToAddress:viaInterface:withTimeout:error:

◆ connectToAddress:withTimeout:error:

◆ connectToHost:onPort:error:

◆ connectToHost:onPort:viaInterface:withTimeout:error:

◆ connectToHost:onPort:withTimeout:error:

◆ connectToUrl:withTimeout:error:

◆ CRData

◆ CRLFData

◆ disconnect

◆ disconnectAfterReading

◆ disconnectAfterReadingAndWriting

◆ disconnectAfterWriting

◆ getDelegate:delegateQueue:

◆ getHost:port:family:fromAddress:

◆ getHost:port:fromAddress:

◆ hostFromAddress:

◆ init

◆ initWithDelegate:delegateQueue:

◆ initWithDelegate:delegateQueue:socketQueue:

◆ initWithSocketQueue:

◆ isIPv4Address:

◆ isIPv6Address:

◆ LFData

◆ lookupHost:port:error:

◆ markSocketQueueTargetQueue:

◆ performBlock:

◆ portFromAddress:

◆ progressOfReadReturningTag:bytesDone:total:

◆ progressOfWriteReturningTag:bytesDone:total:

◆ readDataToData:withTimeout:buffer:bufferOffset:maxLength:tag:

◆ readDataToData:withTimeout:buffer:bufferOffset:tag:

◆ readDataToData:withTimeout:maxLength:tag:

◆ readDataToData:withTimeout:tag:

◆ readDataToLength:withTimeout:buffer:bufferOffset:tag:

◆ readDataToLength:withTimeout:tag:

◆ readDataWithTimeout:buffer:bufferOffset:maxLength:tag:

◆ readDataWithTimeout:buffer:bufferOffset:tag:

◆ readDataWithTimeout:tag:

◆ readStream

◆ setAttemptDscp:

◆ setDelegate:delegateQueue:

◆ socket4FD

◆ socket6FD

◆ socketFD

◆ sslContext

◆ startTLS:

◆ synchronouslySetDelegate:

◆ synchronouslySetDelegate:delegateQueue:

◆ synchronouslySetDelegateQueue:

◆ unmarkSocketQueueTargetQueue:

◆ writeData:withTimeout:tag:

◆ writeStream

◆ ZeroData

Property Documentation

◆ alternateAddressDelay

◆ autoDisconnectOnClosedReadStream

◆ connectedAddress

◆ connectedHost

◆ connectedPort

◆ connectedUrl

◆ delegate

◆ delegateQueue

◆ IPv4Enabled

◆ IPv4PreferredOverIPv6

◆ IPv6Enabled

◆ isConnected

◆ isDisconnected

◆ isIPv4

◆ isIPv6

◆ isSecure

◆ localAddress