gpt4 book ai didi

objective-c - NSURLConnection 在约 5 分钟后忽略服务器响应——没有超时

转载 作者:塔克拉玛干 更新时间:2023-11-01 21:27:47 27 4
gpt4 key购买 nike

我遇到了 NSURLConnection 的问题,我现在有一段时间无法解决了。

我向服务器发出请求,但数据需要很长时间才能处理(平均约 7 分钟)。因此客户端需要等待响应,因此我尝试通过在 NSURLRequest 中设置较长的超时时间来保持 HTTP 连接打开。我现在不想诉诸基于轮询的解决方案。

请求代码:

- (void)sendNextExample
{
url = ...
json = ...

NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:url
cachePolicy:NSURLRequestReloadIgnoringCacheData
timeoutInterval:600.0];
[request setHTTPMethod:@"POST"];
[request setHTTPBody:json];
NSURLConnection *newConnection = [[NSURLConnection alloc] initWithRequest:request
delegate:self
startImmediately:NO];
if (!queue)
{
queue = [NSOperationQueue new];
}
[newConnection setDelegateQueue:queue];

self.connectionStatus = @{@"index" : @(i), @"data" : [NSMutableData data]};
[newConnection start];
}

处理代码(简化):

- (void)connection:(NSURLConnection *)connection didReceiveData:(NSData *)data
{
NSMutableData *buffer = self.connectionStatus[@"data"];
[buffer appendData:data];
}

- (void)connection:(NSURLConnection *)connection didFailWithError:(NSError *)error
{
// log and interrupt process
}

- (void)connectionDidFinishLoading:(NSURLConnection *)connection
{
// do sth with buffer data
// finalize
}

问题是,我从来没有从服务器收到任何东西并且连接超时(在 600 秒 = 10 分钟后,如 NSURLRequest 中所定义),即使该过程看起来在服务器端完成。在连接超时之前,任何时候都不会调用任何委托(delegate)方法。


为了验证服务器处理并将数据正确地返回给客户端,我通过使用 curl 从完全相同的客户端向完全相同的服务器执行多个请求来进行测试:

curl -H "Content-Type: application/json" -X POST -d '{"foo":0.0, "bar":1.0}' serveraddress:8000

这些请求似乎按预期工作,即上述请求在 7 分钟后返回正确的数据:

{"bar":0.5, "baz":10.0} // expected data

因此,我怀疑罪魁祸首在于 NSURLConnection,所有其他事情都是一样的。

作为下一步,我用不同持续时间的服务器端进程执行了几个请求,并发现 NSURLConnection 在请求后大约 5 分钟后开始忽略响应。


所以问题自然是,有人经历过吗?这种行为看起来正常/符合预期吗?

是否有任何原因(甚至可能是操作系统介导的)NSURLConnection 会忽略在一定时间后收到的数据,即使在请求中正确设置了超时?是否有任何细则或未记录的“功能”可能导致此问题?

最终,切换到 NSURLConnection 以外的其他东西(例如 AFNetworking)是否能让我有机会绕过这个明显的“限制”?

(当然,如果有任何关于如何以其他方式执行所描述的任务的建议,我们也非常欢迎!)


为了清楚起见,客户端是Yosemite机器(Xcode 7),服务端使用.Net 4.5(Windows 8机器)中的HttpListener编写。服务器已在其他场合测试,正常运行。


编辑:这个问题发布半年多了,问题依然存在。我设法通过从 cocoa 调用 curl 来完成我的工作(不是很优雅,但可以工作),因此无数次验证了罪魁祸首确实在于 NSURLConnection。我最终得出结论,这是一个错误,并将发布它(如果我有时间这样做的话),但老实说,我并没有抱太大希望。

EDIT2:轮询显然是这里的替代方案。但是,我不能使用轮询,因为我的一些请求需要非常快地返回(<<1 秒),而其他请求则需要很长时间(>1 分钟)。使用轮询意味着增加请求/响应所需的最短时间。

最佳答案

如果 NSURLConnection 失败,NSURLSession 和基于它的所有内容也有可能失败,所以不,AFNetworking 不应该有任何区别。

我很好奇你为什么要为每个请求创建一个单独的 NSOperationQueue 实例。那太浪费资源了; NSURLConnection 本质上是异步的,所以它不会阻塞操作队列,除非它正在运行回调代码。很少有理由使用您自己的操作队列,除非您的委托(delegate)方法出于某种原因必须执行一些繁重的工作。

无论哪种方式,即使使用 curl(如果你真的需要这样做,你应该只链接到 libcurl 而不是运行一个单独的进程),该设计仍然存在根本问题,因为一旦你最终陷入困境网络,您将在服务器完成处理您的请求之前很久超时。此外,如果连接似乎不再使用,一些基于 NAT 的防火墙可能会忘记映射,此时您的请求将永远不会完成。

最好将这种方法更改为您上传数据,服务器为您提供一个 URL,您可以在其中检查进度,您的客户端请求该 URL,然后服务器提供状态。然后,您的客户端可以不时地重新检查状态,最终通过发出请求来检索已处理的数据并删除服务器上的文件来结束。

如果您不介意在您的 Web 服务器中保持一个线程,您还可以使用 MIME 多部分响应,这样当您请求该状态 URL 的内容时,Web 服务器会发回一个新的状态 blob 每隔 < em>n 秒,但这是否是个好主意取决于您的服务器架构。

关于objective-c - NSURLConnection 在约 5 分钟后忽略服务器响应——没有超时,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/34323270/

27 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com