1

私の iOS アプリは GCDAsyncSocket を使用してサーバーからデータを受信して​​います。サーバーは 1 分に 1 回、外部データを収集しています。アプリは定期的にサーバーに接続し、このデータを受信します。サーバーは送信された内容を追跡するため、1 分間のデータは 1 回だけ送信されます。サーバーは過去 1 時間のデータのみを保持しています。各分のデータは、約 100 バイト (+/- 20 バイト) の文字列です。

文字列が受信され、分単位で区切られ、各分が各分のデータのさまざまな量に分割されます。

アプリがサーバーに 1 時間以上接続していない場合、アプリは 60 分間分のデータをダウンロードします。これが発生すると、約 15 分のデータしか取得できません。これは、メソッド readDataWithTimeout が readQueue に 1 つのパケットしかロードしないため、1460 バイトに制限されているという事実まで突き止めました。キューに 2 番目のパケットを追加すると、さらに 1460 バイトのデータが得られることがわかりました。文字列が最大長で、60 個の文字列をダウンロードする場合、すべてをキャプチャするには 5 パケットで十分です。

  1. 読み取りキューに必要以上のパケットを追加し、ほとんどの読み取りで 1 つのパケットしか使用しない場合、最終的にパケット キューがオーバーフローすることはありますか? 未使用のパケットを一掃するために何らかのタイムアウトを適用できますか? 特定の読み取りイベントに必要なパケット数をアプリが予測する方法はありません。

もう 1 つの問題は、パケットのデータ文字列の最後の 1 分が必然的に 2 つのパケットに分割されることです。私がやりたいのは、すべてのパケットの NSData インスタンスを収集し、それらを 1 つの大きな NSData インスタンスに連結し、それを文字列に変換し、その文字列を通常どおり解析することです。

  1. NSData を結合して結果の文字列を解析できるように、特定の読み取り要求に対して受信される最後のパケットがいつ受信されたかを知るにはどうすればよいですか? 各分の文字列は感嘆符「!」で終わりますが、送信の終わりを示す一意の記号はありません。問題1を解決するのと同じタイムアウトが問題2を解決すると思います。

このアプリはすでに Android 向けに公開されています。したがって、可能であれば、iOS バージョンに対応するためにサーバーと Android コードを変更することは避けたいと考えています。

4

1 に答える 1

1

読み取りを要求するたびにreadQueueに5パケットを追加し、読み取りにタイムアウトを追加して、キューがオーバーフローしないようにしました。また、didReadDataコールバックの最後に2秒後に起動するようにNSTimerを設定しました。タイマーが経過すると、使用可能なすべてのデータが読み取られたと見なされ、文字列が処理されます。各タイマーは同じNSTimerインスタンスを使用しているため、タイマーがアクティブで、別のdidReadDataイベントが発生すると、新しいタイマーが開始され、古いタイマーが消去されます。

于 2012-05-04T19:14:05.890 に答える