{"id":2390,"date":"2016-01-03T11:54:11","date_gmt":"2016-01-03T17:54:11","guid":{"rendered":"http:\/\/dev.iachieved.it\/iachievedit\/?p=2390"},"modified":"2020-07-18T18:22:51","modified_gmt":"2020-07-18T23:22:51","slug":"tcp-sockets-with-swift-on-linux","status":"publish","type":"post","link":"https:\/\/dev.iachieved.it\/iachievedit\/tcp-sockets-with-swift-on-linux\/","title":{"rendered":"TCP Sockets with Swift on Linux"},"content":{"rendered":"

A long time ago in a galaxy far, far away, software developers wrote client-server applications with TCP\/IP<\/a> sockets<\/a>. That was before the dark times, before HTTP<\/a>.<\/p>\n

I am of course, joking. HTTP can be leveraged to provide a wide variety of client-server applications and is of course at the base of REST<\/a> applications. What HTTP brings to the table though is not the plumbing to get packets on the wire, but an agreed upon protocol structure (and to some degree a standard as to what port is being used) for those packets. Action verbs such as GET, POST, PUT, etc. and the HTTP header itself are what makes HTTP ideal for developing client-server applications.<\/p>\n

In the end though, at the bottom of the stack, bits and bytes are marshaled through your operating system’s socket interface<\/a>. The API for interacting with network sockets is quite rich and many a tutorial<\/a> and books<\/a> have been written on the topic. IP networking routines in C can be considerably verbose, and were one of the first “real-world” APIs encapsulated in object-oriented routines with C++. That tradition continued with Foundation’s CFStream<\/code><\/a> class and now our Swift swiftysockets<\/code> API.<\/p>\n

Swiftychat<\/h2>\n

To illustrate how to use TCP\/IP network sockets with Swift, we’ll be developing Swiftychat, a basic “chat system” application. It’s quite a naive application, limited in functionality, and would stand no chance in being used in the real world, but, even still, it’s a working example of how to send and receive strings on TCP\/IP sockets in Swift.<\/p>\n

swiftysockets<\/h3>\n

Swiftychat will make use of swiftysockets<\/a>, a Swift Package Manager-ready TCP\/IP socket implementation that was originally developed by the Zewo<\/a> team. Unfortunately due to packaging constraints we have to do a little bit of a dance first to get an underlying C library, Tide<\/a>, installed on our system. So let’s do that now.<\/p>\n

\n$ git clone https:\/\/github.com\/iachievedit\/Tide\nCloning into 'Tide'...\n...\n$ cd Tide\n$ sudo make install\nclang -c Tide\/tcp.c Tide\/ip.c Tide\/utils.c\nar -rcs libtide.a *.o\nrm *.o\nmkdir -p tide\/usr\/local\/lib\nmkdir -p tide\/usr\/local\/include\/tide\ncp Tide\/tcp.h Tide\/ip.h Tide\/utils.h Tide\/tide_swift.h tide\/usr\/local\/include\/tide\n# copy .a\ncp libtide.a tide\/usr\/local\/lib\/\nmkdir -p \/usr\/local\ncp -r tide\/usr\/local\/* \/usr\/local\/\n<\/pre>\n
At some point we believe the Swift Package Manager will be able to compile C libraries<\/a> that can be linked against in the rest of your package build.  Until then, this is the best we can do.<\/p>\n
Once Tide is installed we can leverage swiftysockets in our Swiftychat apps.<\/p>\n
Start Coding!<\/h3>\n
Our main.swift<\/code> file is as simple as it gets.  Create a ChatterServer<\/code> and start<\/code> it.<\/p>\n
main.swift<\/code><\/p>\n
\nif let server = ChatterServer() {\n  server.start()\n}\n<\/pre>\n
Of course, a brief main.swift<\/code> can only mean one thing.  Invasion.  Oh wait, I’m done with the Star Wars references.<\/p>\n
A brief main.swift<\/code> means our implementation is tucked away in the ChatterServer<\/code> class, which looks like this:<\/p>\n
ChatterServer.swift<\/code>:<\/p>\n
\nimport swiftysockets\nimport Foundation\n\nclass ChatterServer {\n\n  private let ip:IP?\n  private let server:TCPServerSocket?\n\n  init?() {\n    do {\n      self.ip     = try IP(port:5555)\n      self.server = try TCPServerSocket(ip:self.ip!)\n    } catch let error {\n      print(error)\n      return nil\n    }\n  }\n\n  func start() {\n    while true {\n      do {\n        let client = try server!.accept()\n        self.addClient(client)\n      } catch let error {\n        print(error)\n      }\n    }\n  }\n\n  private var connectedClients:[TCPClientSocket] = []\n  private var connectionCount = 0\n  private func addClient(client:TCPClientSocket) {\n    self.connectionCount += 1\n    let handlerThread = NSThread(){\n      let clientId = self.connectionCount\n      \n      print(\"Client \\(clientId) connected\")\n      \n      while true {\n        do {\n          if let s = try client.receiveString(untilDelimiter: \"\\n\") {\n            print(\"Received from client \\(clientId):  \\(s)\", terminator:\"\")\n            self.broadcastMessage(s, except:client)\n          }\n        } catch let error {\n          print (\"Client \\(clientId) disconnected:  \\(error)\")\n          self.removeClient(client)\n          return\n        }\n      }\n    }\n    handlerThread.start()\n    connectedClients.append(client)\n  }\n\n  private func removeClient(client:TCPClientSocket) {\n    connectedClients = connectedClients.filter(){$0 !== client}\n  }\n\n  private func broadcastMessage(message:String, except:TCPClientSocket) {\n    for client in connectedClients where client !== except {\n      do {\n        try client.sendString(message)\n        try client.flush()\n      } catch {\n        \/\/ \n      }\n    }\n  }\n}\n<\/pre>\n
Breaking down our server we have:<\/p>\n
1.<\/b>  Initialization<\/p>\n
We make use of the init?<\/code> initializer to signal that nil<\/code> is a possible return value since both the IP<\/code> and TCPServerSocket<\/code> classes (from swiftysockets) can throw an error.  IP<\/code> encapsulates our IP address and port information nicely and we provide an instance of it to the TCPServerSocket<\/code> initializer.  If init<\/code> succeeds we now have TCP socket on the given port ready to accept incoming connections.<\/p>\n
2.<\/b>  The Main Loop<\/p>\n
Name the function startListening<\/code>, start<\/code>, main<\/code>, we don’t care.  It is the main event loop that accepts new client connections (server!.accept()<\/code>) and adds them to the list of connected clients.  server!.accept()<\/code> is a blocking function that hangs out and waits for new connections.  Pretty standard stuff.<\/p>\n
3.<\/b>  Client Management<\/p>\n
The rest of the ChatterServer<\/code> contains all of the “client management” functions.  There are a few variables and three routines that manage clients.<\/p>\n
Our variables are straightforward:<\/p>\n