Post

Replies

Boosts

Views

Activity

Reply to Socket Becomes Unresponsive in Local Connectivity Extension After Lock Screen
one more question, The extension uses CFStream to establish a TCP connection with the server, primarily for receiving real-time notifications. To keep the connection stable, it sends a keep-alive packet every second. Since .voIP is deprecated, which StreamNetworkServiceTypeValue should be used in this scenario? Available options: @available(iOS 4.0, *) public static let voIP: StreamNetworkServiceTypeValue // ⚠️ Deprecated @available(iOS 5.0, *) public static let video: StreamNetworkServiceTypeValue @available(iOS 5.0, *) public static let background: StreamNetworkServiceTypeValue @available(iOS 5.0, *) public static let voice: StreamNetworkServiceTypeValue @available(iOS 10.0, *) public static let callSignaling: StreamNetworkServiceTypeValue The goal is to ensure the extension’s TCP connection remains active and reliable in the background. Which value best supports that behavior?
Apr ’25
Reply to Socket Becomes Unresponsive in Local Connectivity Extension After Lock Screen
Thanks for the response. Here are my answers to the questions below: ❓1. What network(s) have you reproduced this on? • The clients connect to Access Points which provide an address on our internal network with outside internet access. • The server runs on our internal network, but on a network without internet access. • The network uses a bridge to connect these two address spaces. • We do not use DNS hostnames; we strictly utilize direct IP addressing and rely on the network bridge. • These two address spaces are internal to a single building. • We have only used the single internal network, with variations on the Access Point the phone connects through: • An Access Point managed by our IT department • An Access Point managed by the engineering group Note: Both provide addresses on our ‘Production’ network. ❓2. Is your server located on the same local network as the clients or is it on a remote network or otherwise isolated from the clients? • The server is on a separate internal network, but within the same physical building. • A network bridge connects the client and server subnets. • Clients use direct IP addressing to reach the server (no DNS resolution). ❓3. Is there an intermediate NAT server involved? • No. • Our network design does not use NAT between clients and the server. • All communication is over direct internal IPs, routed via the internal bridge. ❓4. What happens when the client identifies the problem and reconnects? Is it able to reconnect immediately or is there some delay/issue? The client detects the disconnection sometime between 30 seconds and 1 minute, which is the time gap of seemingly non-activity. (No logs from any services occured) Upon connection loss detected, the extension attempted a reconnection and is successful within an expected time frame.
Apr ’25
Reply to Socket Becomes Unresponsive in Local Connectivity Extension After Lock Screen
Correction for the original post: On the extension, from our logs there was no gap in sending packets. From it’s perspective, all packets were sent with no error.. this is wrong ,there is a gap in sendKeepAlive message from extension to server. this is what we want to understand 2025-03-24 18:34:50.692 sendKeepAliveRequest() // 65 seconds gap 2025-03-24 18:35:55.063 sendKeepAliveRequest()
Mar ’25
Reply to Regarding Long-Term Socket Connections in iOS Apps (TCP/UDP)
Thank you for your previous response. I have a follow-up question regarding Local Push Connectivity. Since this is an extension that runs in the background, I’d like to know whether it’s possible to maintain a long-term TCP/UDP socket connection in this context. Can the extension keep such a connection active for a long time? Are there any specific restrictions or best practices related to Local Push Connectivity that we should follow to ensure stable connectivity? thanks For reference:https://developer.apple.com/documentation/networkextension/local_push_connectivity
Oct ’24