Post not yet marked as solved
Post marked as unsolved with 0 replies, 65 views
Problem
My app needs to send an HTTP-like request over TCP, followed by periodic data and get back a stream of data in the foreground and background in return.
In the background, I need to open and close the socket after receiving a Bluetooth characteristic value, which is an unnecessary overhead that slows the user down and may lead to a lot of lost data.
Currently
In the foreground, it opens an NSSocket (through a framework), sends the initial request and periodically sends and receives data.
While in the background, the app is started when it receives a characteristic value from the bluetooth-central background mode. It then opens the socket to send some initial data, waits for some data in return, and closes the socket.
Considerations
The protocol I need to connect to is HTTP-like (NTRIP), so I considered using a URLSession, which can keep a socket open, even in the background. However, the protocol has some non-standard behaviors. Namely:
It can return a SOURCETABLE response (interchangeable with HTTP/1.1).
Some implementations have a non-standard second status line (e.g. HTTP/1.1 OK 200, followed by HTTP/1.1. Not Authorized 401).
Some rare implementations incorrectly fail to separate the status line and message body with CRLF.
The connection needs to be kept open to periodically send and receive data.
A future revision of NTRIP does enforce HTTP compliance, but is not yet widely used.