2

QTCPSocketTCPサーバー（Ubuntuで実行されている）に接続するために使用しています。サーバーは、少なくとも 40 ミリ秒ごとに 1 バイトのパケットを送信しています。私のアプリケーションはリアルタイムなので、余分なネットワーク トラフィックを犠牲にしてデータをできるだけ速く受信することが重要です。

Windows から TCP クライアントに接続すると、パケットの受信を開始します。ただし、readyRead()からの信号はQTCPSocket200 ミリ秒ごとに 1 回だけ送信されます (パケット内に 5 バイトあります)。Wireshark でパケットを確認しましたが、実際には 5 バイトのパケットが送信されています。

ただし、QTCPSocketMac (実際にはまったく同じコード) で使用すると、毎回個別のパケットが取得され、送信された 1 バイト パケットはすべて 1 バイト パケットとして到着します。これは素晴らしいことです。

生の Windows ソケット (を使用しないQTCPSocket) を作成してみましたが、Windows と同じ動作をQTCPSocketします。

Mac ソケットがはるかに高い時間分解能でパケットを受信する原因となる違いは何ですか? setsockopt()この 200 ミリ秒のバッファリングが発生しないように設定できるものはありますか?

サーバー側で設定することでおそらく問題が解決することは承知していTCP_NODELAYますが、Mac TCP クライアントが意図したとおりに動作することを考えると、Windows でも同じ動作を得る方法があるはずです。

4

3 に答える 3

0

設定 mySocket->setSocketOption(QAbstractSocket::LowDelayOption, 1); サーバー側では、この問題を解決するために私が見つけた唯一の方法です

于 2013-02-21T11:23:44.317 に答える
0

検索エンジンからこれに出くわした他の人のために：

oggmonsterによる上記の (正しい) 回答は、次のように説明することもできます。

int on = 1;
if (setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, (char*)&on, sizeof(on)))
  {
  return -1;
  }
于 2016-10-01T19:34:45.700 に答える
-1

受信したデータの各バイトを確認して、応答 ACK にピギーバックするデータを与える必要があります。あなたのプロトコルを設計した人に相談してください。

「X では機能するのに Y では機能しないのはなぜですか」などの質問に答えようとすることは、両方の動作が正しくない場合にのみ役立ちます。アプリケーション レベルの確認応答がない場合は、どちらの動作も正しいです。それらのいずれかが正しくない場合、プロトコルには、アプリケーション層の確認応答など、それを制御するメカニズムが必要です。そうでない場合は、プロトコルが壊れています。壊れたプロトコルが機能しない理由を理解しようとするのは無意味です。壊れているから機能しません。

于 2013-02-15T14:38:22.647 に答える