Sockets: Setting up a client and server - ios11

Question

I want to create a toy example with a client and an echo server.
Is there a way for an iOS app running in the Simulator to connect to a server running on my Macbook? Or, is there something similar to localhost in iOS? For instance, can I run a client and a server in two different background threads? I actually tried that, but the server doesn't receive any data from the client:
//This uses SwiftSocket installed with Cocoapods:
override func viewDidLoad() {
super.viewDidLoad()
// Do any additional setup after loading the view, typically from a nib.
DispatchQueue.global(qos: .background).async {
let udpServer = UDPServer(address: "localhost", port:12033)
var count = 1
while true {
print("Server about to recv() \(count)")
let(data, sender, port) = udpServer.recv(6)
print("data: \(data)\nsender: \(sender)\nport: \(port)\n\n")
if let data = data {
print("Server received: \(data) from \(sender) on port \(port)")
}
sleep(1)
count += 1
}
}
DispatchQueue.global(qos: .background).async {
let udpClient = UDPClient(address: "localhost", port: 12033)
switch udpClient.send(string: "Hello\n") {
case .success:
print("Client sent message to server.")
case .failure(let error):
print("Client failed to send message to server: \(error)")
}
udpClient.close()
}
}
--output:--
Server about to recv() 1
Client sent message to server.
data: nil
sender: no ip
port: 0
Server about to recv() 2
data: nil
sender: no ip
port: 0
Server about to recv() 3
data: nil
sender: no ip
port: 0
Server about to recv() 4
data: nil
sender: no ip
port: 0
I'm a little confused by the recv(). Shouldn't that block?

Answer 1

Okay, the server will receive the data (and the recv() blocks), if I use "127.0.0.1" for the host string instead of "localhost".
And, if I run a server on my Macbook that listens on "127.0.0.1" (and I get the ports to match in my iOS code and the server code!), then the server running on my Macbook receives the data from the iOS client.
One question I had was whether the recv() for a UDP socket needs to be the exact length of the data. My results show that you can recv() in efficient chunks, and if the length of the data is shorter than the specified chunk, the recv() will read what is available, then return.
And if you are confused about whether you need to loop over a recv() to gather all the data that was in a send(), here is a great post on the matter:
Examples. Blocks of contiguous characters correspond to send() calls:
TCP:
Send: AA BBBB CCC DDDDDD E Recv: A ABB B BCC CDDD DDDE
All data sent is received in order, but not necessarily in the same
chunks.
UDP:
Send: AA BBBB CCC DDDDDD E Recv: CCC AA E
Data is not necessarily in the same order, and not necessarily
received at all, but messages are preserved in their entirety.
With TCP, you need to loop over the recv() until you find the marker that indicates the end of the data you are trying to read e.g. a newline, a special sequence of characters, or maybe the blank string that is returned by recv() when the socket is closed by the sender.
With UDP, one recv() will read all the data in a send().