CocoaAsyncSocket is a fantastic socket library for Cocoa (iOS and MacOS). It comes in RunLoop and GCD flavours, but either way its asynchronous, which means that you can fire off and receive data without your code blocking (which means your code can get on with other things, like providing GUI interactivity, etc.)

However, one of the problems I found with CocoaAsyncSocket (using the RunLoop version) was that despite its asynchronous nature, when building a server application handling multiple sockets that also required interactivity, managing a large number of sockets and packets could cause significant slowdown to my app.

To resolve this, I decided to move my RunLoop-based AsyncSocket instances onto a separate thread. Unfortunately, this is not a particularly well-documented procedure. After some initial frustration, I switched my app over to the GCD version, which solved the slowdown problem but introduced a whole host of new issues.

I returned to the RunLoop-based CocoaAsyncSocket library and will now share how to move your RunLoop-based AsyncSockets onto their own separate thread.

First, you need to create a separate thread for your socket to run in. You would normally put this in the init method of whatever class is using the socket (you also need to create an ivar of type NSThread called socketsThread to hold a reference to this new thread as we will need to pick it up later):

socketsThread = [[NSThread alloc] initWithTarget:self selector:@selector(socketsThread) object:nil];
[socketsThread start];

The first line creates a new thread running the socketsThread method, and the second line starts the new thread. Simple enough!

Next, you need to actually provide your socketsThread method. You should add this to the same class (since you specified the target as self in the previous snippet) and also add another ivar of type NSRunLoop called socketsRunLoop as again, we will need this later (and of course you need your socket ivar of type AsyncSocket):

- (void)socketsThread {
    socket = [[AsyncSocket alloc] initWithDelegate:self];
    socket.delegate = self;
    [NSTimer scheduledTimerWithTimeInterval:DBL_MAX target:self selector:@selector(ignore:) userInfo:nil repeats:NO];
    socketsRunLoop = [NSRunLoop currentRunLoop];
    [socketsRunLoop run];
}

What’s going on here is that you are creating your new socket (this is the listening, server socket — although it doesn’t strictly need to be created here) and setting its delegate to your current class. You then schedule a timer to run for a very, very long time which will keep your RunLoop alive and stop it quitting immediately. You then get a reference to the RunLoop for this thread which is stored in the socketsRunLoop ivar and then you start the RunLoop.

At this point, everything is set up and running, so all you need to do is tell your socket and all future sockets which RunLoop it should be using:

- (NSRunLoop *)onSocket:(AsyncSocket *)sock wantsRunLoopForNewSocket:(AsyncSocket *)newSocket {
return socketsRunLoop;
}

This tells all sockets with their delegate set to your current class to use socketsRunLoop as its RunLoop (which runs on the socketsThread thread). Just bear this in mind if you are handling multiple sockets through the same owner class.

So from now on, your listening socket as well as all other sockets will all be using socketsRunLoop (which is on a separate thread) for handling inbound and outbound communication). What you need to remember now is that when the socket delegate methods are called, they are being called from a separate thread. This means that if you want to update the UI from a delegate method (for example onSocketDidDisconnect:), then you should use:

[self performSelectorOnMainThread:@selector(something) withObject:nil waitUntilDone:NO];

waitUntilDone is of course a matter of preference, but the important thing is that you update the UI from the main thread and not from the socketsThread, as this will cause your program to crash.

The same applies vice-versa: you cannot perform operations on the socket from the main thread (i.e. the UI thread). So let’s say you have a button which when pushed sends a packet — you cannot simply write this data to the packet from the button’s callback directly. Instead, you need to make sure that you only perform it on socketsThread. To ensure this, make sure you perform any relevant selector on the correct thread:

[self performSelector:@selector(sendMessage:) onThread:socketsThread withObject:message waitUntilDone:NO];

Again, waitUntilDone is a matter of preference but the important thing is to ensure that any interaction with the sockets is done by performing the selector on the correct thread.

I hope that this post unravels some of the mystery surrounding CocoaAsyncSocket and helps other developers to skip past some of the complexities that I had to deal with in order to get this up & running.

This entry was posted on Friday, December 2nd, 2011 at 11:52 am and is filed under iOS Development. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.