URLSessionWebSocketTask and CFNetwork connectivity in Airplane mode

1. URLSessionWebSocketTask logs ominous error messages even with a .normalClosure. I never figured out if I was using the API incorrectly, or if these error messages were expected.

2. URLSessionWebSocketTask.receive appears to require recursive calls. This seems to open up the possibilities for race conditions, stack overflows, and overall just unnecessary general confusion. Could the API change to a publisher?

3. Having to pass a URLSessionWebSocketDelegate into a URLSession means that you can have a strong reference to "self" if your websocket wrapper class implements this protocol. A strong reference means that you open up the possibility for a memory leak since the class isn't disposed when dereferenced. I avoided a strong reference with an inner class object, but I would prefer if the API avoided this issue altogether.

4. There should be an easier way to discover connection issues. For instance Vapor's websocket-kit simply lets you set a variable (i.e. "ws.pingInterval = TimeAmount.seconds(10)") and the library will automatically close the connection if it doesn't receive a pong within an interval after sending a ping.

5. As mentioned above, URLSessionWebSocketTask seems to close the input stream if the server sends a message too soon after a connection is upgraded to a websocket connection. What makes things more confusing is that the websocket's output stream still appears to be connected to the server and the server can receive messages, but the server can no longer send messages to the websocket client.

6. It would be nice if the library differentiated between the initial GET connection, and then when the connection is upgraded to a websocket connection.

Code Block 
protocol WebSocketConnection: MessageClient {
  func connect()
  func disconnect()
  var status: AnyPublisher<ConnectionStatus, Never> { get }
  var message: AnyPublisher<String, Never> { get }
}
protocol MessageClient {
  func send(text: String)
}
enum ConnectionStatus {
  case idle
  case connected
  case upgraded(MessageClient)
  case disconnected(DisconnectReason)
  case reconnect(Date)
}
enum DisconnectReason {
  case error(Error)
  case unknown(Int)
  case unauthorized
  case not_found
  case normal
}

Popping in to say Ethan's advice saved me hours of headache. I've fought with the native URLSession and WebSocketTask APIs for about eight months, and used it across our fleet. Out of nowhere, socket connections would make no progress, and just retry every ten seconds. The instructions for debugging CFNetwork were of no use, and I had nearly no logs from CFNetwork explaining what was going on. Setting the debugging environment variable did nothing, the task just wouldn't budge. It's on brand with the overall experience of the Network framework, unfortunately.

I switched over to WebSocketKit and have been beyond pleased. It has a very simple API and makes it very easy to migrate your URLSession code to it, usually with far less code being needed.

There seems to be some serious confusion about Apple’s WebSocket APIs in this thread. There are two APIs for WebSocket [1]:

• Foundation’s NSURLSession, via NSURLSessionWebSocketTask

• Network framework, via NWConnection

All of the issues discussed in this thread seem to be related to the Foundation API. That certainly matches my experience. In contrast, I’ve found Network framework’s WebSocket implementation to be solid.

If you’re having problems with the Foundation WebSocket implementation, try using Network framework. If you have problems with that, I recommend that you start a new thread, with the Network tag, and either Matt or I will take a look.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Ignoring the web view and browser stuff.