Hello,
Im trying to open a TCP socket to transmit a data packet to the remote host device.
The iphone is already connected to the device after linking up via
NEHotspotConfigurationManager.shared.apply(myconfig)I attempted to use a ping command I found on another forum.
func start(name: String, port: Int, tls: Bool, ping: String) {
self.ping = ping.data(using: .utf8)!
let streams = Stream.streamsToHost(name: name, port: port)
self.streams = streams
if tls {
let success = streams.inputStream.setProperty(StreamSocketSecurityLevel.negotiatedSSL as AnyObject, forKey: Stream.PropertyKey.socketSecurityLevelKey)
precondition(success)
}
for s in [streams.inputStream, streams.outputStream] {
s.schedule(in: .current, forMode: .defaultRunLoopMode)
s.delegate = self
s.open()
}
}
func ping(streams: (inputStream: InputStream, outputStream: OutputStream)) {
let data = self.ping
let dataCount = data.count
let bytesWritten = data.withUnsafeBytes { (p: UnsafePointer) -> Int in
return streams.outputStream.write(p, maxLength: dataCount)
}
if bytesWritten < 0 {
NSLog("stream write error")
} else if bytesWritten < data.count {
NSLog("stream write short %d / %d", bytesWritten, data.count)
} else {
NSLog("stream task write %@", data as NSData)
}
}however, the socket always seem to tmieout for me. See output below:
nw_socket_handle_socket_event [C1:1] Socket SO_ERROR [60: Operation timed out]could anyone help shed some light on how I could resolve this please?
Thanks
I ended up creating TCP socket using C thats called wihtin my swift class. Would this be allowed on Apple Store?
Only App Review can give you definitive answers about what will or won’t be allowed on the store. I will say that:
BSD Sockets is a supported API on our platforms.
BSD Sockets has many caveats on our platforms (you can find some, but not all, of them listed in this post), but many of them aren’t relevant if you’re talking to a locally-connected peer.
The purpose of this app is to:
1) Connect to my broadcasting device
2) Transmit my home router details to this device (SSID, security type and password)
3) This device will then attempt to connect to my home router using the credentials sent via my IOS app
The best way to implement this functionality is via WAC. Pasted in at the end of this email you’ll find my standard spiel about that.
Coming back to the issue you’re currently wrestling with, the most likely cause of the problem you’re seeing is the delay between the
NEHotspotConfigurationManager completion handler being called and the Wi-Fi interface actually coming up completely. I generally avoid that problem by searching for the accessory using Bonjour [1]. Once the Wi-Fi interface comes up completely, Bonjour will discover the accessory and you can then communicate with it.
Does your accessory advertise itself with Bonjour? If not, I’d consider fixing this in your accessory. Bonjour is relatively easy to implement and it will make it easier to configure your accessory in all sorts of concern cases. Specifically, the combination of Bonjour and IPv6 guarantees that you’ll always be able to discover and talk to your accessory regardless of the local network environment.
If you can’t get your accessory to speak Bonjour then the first step here is discovering your accessory. How do you do that?
Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
let myEmail = "eskimo" + "1" + "@apple.com"[1] Bonjour is an Apple marketing term for:
RFC 6762 Multicast DNS
RFC 6763 DNS-Based Service Discovery
The best way to integrate your Wi-Fi accessory with iOS is Wireless Accessory Configuration (WAC). You can learn more about this technology by following the links in QA1942 iOS Wi-Fi Management APIs.
The main drawback with WAC is that your accessory must be built under the aegis of the MFi programme, and my understanding is that supporting WAC requires modifications to your hardware.
IMPORTANT Much of the technical details about MFi accessories are not public, and thus can’t be discussed in this area of DevForums. If you want to get involved with MFi, you should follow the link to the MFi developer programme page in QA1942.
An alternative approach is to use
NEHotspotConfigurationManager. This does not require any special privileges but it does have its own drawbacks. Specifically,
NEHotspotConfigurationManager requires you to know in advance the SSID and password of the accessory’s access point. Unless all of your accessories have the same SSID and password, you’ll need to find a way to work these out.
There’s three common ways to do this:
Have the accessory advertise that information via Bluetooth LE, at which point you can find it using the Core Bluetooth API.
Print these details on the side of the accessory using some sort of barcode, and have your app scan that.
Ask the user )-:
My overall advice is that you pursue a dual strategy. In the long-term you should look at supporting WAC in future hardware, because that produces an ideal user experience. As for your current hardware, you should see what you can do with
NEHotspotConfigurationManager.