2 つの iOS NSURLConenctions (1 つはダウンロード、もう 1 つはアップロード) の間でデータをストリーミングしようとしていますが、うまくいかないようです。
- 2 つの NSURLConnections を同時に実行しています。
- 1 つは、GET 要求を使用して URL からコンテンツをダウンロードすることです。
- もう 1 つは、PUT 要求の要求本文で、受信したばかりの同じコンテンツを別の URL にアップロードすることです。
- アップロード接続では、 setHTTPBodyStream を使用して、読み取りメソッドが他の接続から以前に受信したデータを返すカスタム NSInputStream を指定しています。
- 両方の NSURLConnections は、別々のバックグラウンド スレッドの実行ループでスケジュールされているため、(ブロックしている可能性がある) デリゲート コールバックが互いに (メイン スレッドとも) 干渉しないようになっています。
だから私はそれが次のように機能すると思った：
- アップロード接続は、入力ストリームで [read:maxLength] (オーバーライドしました) を呼び出します。
- 利用可能なデータがまだないため、読み取り呼び出しはブロックされます。
- 別のスレッドでは、ダウンロード接続のデリゲートで [connection:didReceiveData:] が呼び出されます。
- 受信したデータを共有バッファーに入れ、アップロード接続の入力ストリームで使用できるようにします。
- アップロード ストリームの読み取り呼び出しがブロックされなくなり、データのチャンクを返すことができるようになりました。
残念ながら、実際にはこれは機能しません。アップロード ストリームの読み取りメソッドがブロックされた後、ダウンロード接続のデリゲート メソッド (didReceiveData など) は呼び出されなくなります。(アップロード側でブロックを無効にすると、ダウンロード側の didReceiveData が正常に呼び出されることに注意してください。)
これは、アップロード入力ストリームの read メソッドが、接続とストリーム オブジェクトが作成されたスレッドではなく、別のスレッド (明らかに Cocoa によって作成された) で呼び出されるという事実と関係があると思われます。これが両方の NSURLConnections で使用される共有スレッドであるかのように、ブロックされると、他のすべての接続も同様に機能しなくなります。またはそのようなもの。
実際に何が起こっているのか、誰かが考えを持っていますか?
また、リクエストボディ入力ストリームの read メソッドが呼び出されるスレッドを制御する方法はありますか?