WebSocket for iOS 學習筆記

Websocket Introduction

Before WebSocket appears, to dealing with 2-way data communications, we have some choices such as 'Polling'(輪詢), 'Long Polling'(長時間輪詢) or 'Silent Push Notification'(無聲推播).

But, the more 'Polling' we used, the more 'NetWork Request' we caused, and some of them won't even response a new data. Furthermore, sending too much 'Silent Push Notification' isn't that effective, because 'Notification' isn't received at once.

'Long Polling' is the best choice among them, it is the extended version of 'Polling' and will keep an effective link between server and client, but this is also the cons of it, every 'Network Request' will come up with a 'Http OverHead'(Http 開銷), and so, server will need extra maintainance for it's complexity.

This is why WebSocket was created, because it doesn't have any 'Http OverHead' protocols, and when client sends a WebSocket connection request to server, it'll create a 2-way connections stream to receive or send data/messages from any side (not through 'Network Request').

Websocket Message

FIN: the single bit indicates whether this is the final frame of message or if more frames will follow.
opcode: these four bits indicate what type of message this is and how to handle payload data.
- non-control frames: continuation, text, binary
  - thease deal with how to decode the payload
- control frame: connection cloase, ping, pong
  - these are special types of messages
  - when each side receive a 'ping', it must resend a 'pong' in a period of time to ensure the connection is still available.
MASK: this single bit indicates wheter the message is masked. Client-to-Server messgaes must always be masked.
Payload length: use these 7, 23 or 71 bits to explain how big the payload data is in bits, much like HTTP's Content-Length header.
masking key: these four optional bits contain the key you used to mask the message. You can omit them if the MASK bit is 0.
payload data: the rest of the message contains the actual payload.

Usages

IM (Instant Messaging)
Online Games
Co-Editing Document (ex: HackMD)
live streams
stock platforms
IoT

StarScream

Open Resources for Webscoket (iOS 10 or above)
StarScream

URLSessionWebSocketTask

only supports iOS 13 or above
URLSessionWebSocketTask extends URLSessionTask, because it provides a 2-way real-time communication via WebSocket (different from typical HTTP request -> OIOO).

Basic Steps

First, create our WebSocket Connection, this will have server sent back every message it receives.
Second, to open a connection, we need to resume the webSocketTask
Then, you can only send text or binary data, we can't send low-level WebSocket frames like 'ping' or any other control messages, this is fine for most cases, so we can optionally create an enum for this work-flow

-> server received "Hello Socket" ans sent it back.
After that, to receive data coming from server, we need to use URLSessionWebSocketTask.Receive method. This method accepts cpmpletion handler that receives a value of new Result type.

the value of the success case is the same as URLSessionWebSocketTask.Message that we used to send messages.

# The tricky part is: this Receive method is only called once, if you want to receive another message, you'll need to call this method again. So the current solution is by adding a 'defer' to it's own handler:

If your app is not sending message over WebScket within period of time frequency, the server may disconnect your connection due to inactivity, so it's time to use 'PingPong' messages to stay connected.

This method is very basic, it sends only a default ping messages and notifies about it's results.
For most of the time. API won't allow any customization of ping message payload, but for some special cases like statistic, ping messages with custom payload can be used to deliver additional information to the server.
When we no longer need WebSocket conneciton, we still have to close it properly.
URLSessionWebSocketTask has a seperate WebSocket-Specific cancel method.

It accepts close coed and optional reason payload, 'Close Code' is used to tell server why this conneciton is disconnecting.

Obviously, we need to knoe when our WebSocket connection is connected or disconnected and why, to do that we need to use URLSessionWebSockerDelegate

@available(iOS 13.0, *)
public protocol URLSessionWebSocketDelegate : URLSessionTaskDelegate {

optional func urlSession(_ session: URLSession, webSocketTask: URLSessionWebSocketTask, didOpenWithProtocol protocol: String?)

optional func urlSession(_ session: URLSession, webSocketTask: URLSessionWebSocketTask, didCloseWith closeCode: URLSessionWebSocketTask.CloseCode, reason: Data?)

It will notfity you when connection was opened or closed with a close code and a reason form the server.

Resources