1

私は問題があります。この問題についてスタックオーバーフローに関する多くのトピックを読みましたが、何も役に立ちませんでした。コメット接続を介してクライアントサーバー通信を実装しようとしています。メッセージの送信を担当するインスタンスと、メッセージの受信を担当するインスタンスがあります。プロセスは次のとおりです。 - 送信インスタンスがサーバーに GET 要求を送信し、サーバーが受信インスタンスに応答します。最初の呼び出しは正常に機能し、最初の応答を取得して必要なデータを取得できますが、次の要求で didReceiveData コールバックがトリガーされません。しかし、サーバーがデータを送信したことがわかります。サーバーログに表示され、クライアントマシンのwiresharkに表示されます。興味深いことに、応答に「content-length: 0」を追加する前に、最初の応答でコールバックがトリガーされていませんでした。NSUrlConnection の文書化されていない機能? NSUrlConnection に応答が有効であると思わせるには、他に何を考慮する必要がありますか? 代替手段: ソケットからデータを強制的にフェッチしますが、NSUrlConnection で可能かどうかはわかりません (男はそれについて無言です)

永続的な接続コード:

  NSURL* requestUrl = [NSURL URLWithString:[[NSString alloc] initWithUTF8String:rq->url.c_str()]];
  NSMutableURLRequest* request = [NSMutableURLRequest requestWithURL:requestUrl   cachePolicy:NSURLRequestUseProtocolCachePolicy timeoutInterval:600];
  m->connection = [[NSURLConnection alloc] initWithRequest:request delegate:request_delegate() startImmediately:NO];

  [m->connection scheduleInRunLoop:[NSRunLoop mainRunLoop]
                              forMode:NSDefaultRunLoopMode];
  [m->connection start];
4

1 に答える 1

0

nginx サーバーは、ヘッダー セクションの "content-length" を大きな値に設定する必要があります。これは、クライアントがパケットを取得して受信バイト数を増やし、ヘッダーに設定されたバイト数を受信した後、それ以上の応答を受信しないためです。content-length セクションを省略すると、デリゲートの呼び出しがブロックされます。それが理由だった

于 2013-12-06T09:33:33.103 に答える