私はTCPソケットを介してデータを送信しようとします。iOS TCPクライアントの遅延
ローカルのpc（サーバー：javaベース、nagleアルゴリズムdisbled）からサンプルios tcpクライアントにデータを送信しました。 私はiPhoneで "CocoaAsyncSocket"と "FastSocket"という異なるライブラリを試しています。両方とも、クライアントはすぐにデータを受信することがあり、3回ごとにデータが到着するには500ms〜4000msが必要です。
私はクライアントとしてアンドロイドデバイスを使って同じことを試みましたが、それは魅力的でした！
提案がありますか？私は同じ問題に直面しています
が、それだけで時々私はすべてが瞬時に送信してセッション全体を通過することができ、私のデバイスで発生し、時々私は、私がメッセージをしても送信されていないと思うほど大きな遅延を取得しますしかし、時にはほぼ1分後に、467バイトの小さなパッケージが到着します。
私はこのドキュメントを読んでいます。これは、tcpが継続的な流れを持つことを望んでいることを示唆し、時折メッセージを送信すると問題を引き起こす可能性があると著者は示唆しています。リンクから
引用：
全体的な概要は仕事にTCPステートマシンのデータの連続的な流れがあるとき、高速再送などの、TCPはとても素晴らしい作るメカニズムの多くは、最高の仕事ということですに。データのブロックを送信してから停止して、相手側からのアプリケーション層確認応答を待つと、ステートマシンは不安定になる可能性があります。それはプライムを失うウォーターポンプのようなものです - パイプライン全体が水で満たされていれば、ポンプはうまく動作し、水は流れますが、水の後に水がたくさんある場合、ポンプはインペラーには何も押しつけられません。
TCPを介して要求/応答アプリケーション層プロトコルを記述している場合は、少なくとも二重バッファで実装する必要があります。最初の要求を送信し、まだ待機中応答のために、あなたの秒を生成し、送信してください。その後、最初のリクエストに対する応答を取得したら、3番目のリクエストを生成して送信します。このようにして、常に2つの要求が残っています。あなたが要求nの応答を待っている間、要求のn + 1は、概念的に沿ってデータをプッシュ、リターンパイプラインでその背後にあります。
私はまだこれを試したことはありませんが、この情報はうまくいけばあなたや他の人を助けることができます。
よろしく、 ボー
編集 の負荷を送信している間、私はちょうどテストしたメッセージ（ない場合）毎秒の0.05（行き過ぎ私が知っている）、物事、すべての重要なメッセージを向上させるために思われます私は即座に受信取得しているように見える役に立たないものの中で、私はちょうど分未満のためにテストしてみたが、違い
を作るように見える送ります