I’m really surprised about the Remoting SDK and it’s possibilities. Thank you for this great solution!
I created a simple client-server application to control some GPIOs from remote and I’m happy to see it working.
The only bigger problem I have occurs on my iPhone 7 iOS 10.2 device when after some requests the client doesn’t get any response. I can see the network indicator at the status bar circle without end.
To get a response again I have to send 3-4 new requests until the server will start to answer again.
This scenario doesn’t occur when using the simulator. There are now network problems.
My server is built up with Delphi 7 Indy 9. I checked if there are any incoming data when the problem occurs, but there will be no request recognizable.
I can’t install Indy10 in the next few weeks. So it would be great If I could get the Indy9 server running.
But isn’t it strange that the app works without any problem on simulator? (Edit: it just takes longer, but the same problem occurs as well)
On device just the first two requests will be successful. Almost every following requests will hang up although the timeout was set to 5 seconds.
When a request fails and I manually cancel it and I then restart the server, nothing will change. All new requests will still fail until I restart the app. So I guess it’s more a client problem.
Curious. we did some fixes that should prevent occasional lock-ups of NSURLSession for 9.1, but we’re not aware of any outstanding problems isn that area :(. We’ll need to investigate. Any particular steps needed to make this reproduce with the iOSBackgroundCompletion sample? What version of Xcode, SDK and the Simulator are you using?
I have played the whole day around with the iOSBackgroundCompletionServer. Here’s the summary:
First I built up a new network to exclude suchlike problems. Then I installed (on a new PC) Delphi XE5 and the newest Indy 10.6.0.5040. Thereby I compiled the iOSBackgroundCompletionServer with the newest ROSDK version 9.1.99.1273. Next I compiled the provided client side with xcode (8.2.1(8C1002), ROSDK version 9.1.99.1273) for my iPhone 7 (iOS 10.2(14C92)). Running the app and requesting 2-3 times in succession (immediately after the server responded) a 1 second sleep will show up exactly the same problem.
I have no idea what goes wrong… I’ve my back to the wall.
Can you test one more thing for me? when the client gets to the point where all RO requests hang — can you, on a separate thread (i assume Main() is still responsive), laugh a plain NSURLSession request (see here request to any random domain (say https://www.apple.com), and check if that too hangs?
I’ve seen scenarios where all of NSURLSession just gets completely stuck (RO or no RO), and knowing if tisanes the case here will narrow this down.
Hm, unfortunately the NSURLSession requests will work…
What I found out: if you reference the outgoing RORequests and kill them when they hang, the following requests will have a chance to be answered.
EDIT: ok, if you fire enough you don’t need to cancel them
What I saw is that the xcode network monitor won’t show any traffic when all RO request hang and I send new requests. The manual NSURLSession request is visible.
i’ve started looking into this issue, and i’m i cannot reproduce the problem with the iOSBackgroundCompletionService app. i can start as many requests as i try, and the all succeed, and sorting hangs. What could i be missing?
Hmm… I have no idea. I took the xcode sample, the Delphi 7 sample and built them without any changes. Then I executed both and tried it as described.
I think it’s better If we talk about the same source code. I attached the Delphi server version and a Oxygene client version (I don’t like Xcode). Press the appearing UIButton up to 10 times and the problem occurs (on device).
Reproduced, and — i think — fixed. I’ll PM you an updated ROClientChannel.m file — can you rebuild RO with that and see if that solves the problem for you, as well? (it’s a tentative fix and will need more cleanup before i fully commit).
Thanks! It got more than 100% better. But the problem still occurs.
One app do like 10 requests at the same time. At least one request will hang.
If the app fires only one request at the same time, it needs some more time until the app doesn’t accept new requests.
Ok :(. is this with 10 (long) requests fired of in the iOS Backgrounding sample? or with a different app that runs 10 requests tab the same time? in the latter case, can you give me a testcase? do you use one client channel for all requests, or 10?
I modified the refresh method from the last sample I uploaded. Check it out.
Press the sleep button as soon as the acitivty indicator stops. After 3-4 tries you will see the problem. I don’t show an alert view anymore, so you can repeat the requests faster. This delay seems to be a deciding factor too.