各ピアごとに新しいソケットを作成してpingを実行する

Question

C++でQtソケットを使用して小さなクロスプラットフォームアプリケーションを作成しましたが（これはC++またはQt固有の質問ではありません）。

アプリにはピアに接続しようとする小さな「ping」機能があり、小さなチャレンジ（送信されたカスタムデータとカスタムデータが返信されます）を聞いて生きているかどうかを確認します。

私は各ピアごとに1つのソケットをオープンしていますので、pingが始まるとすぐにSYN_SENTにいくつかのソケットがあります。

これはチャレンジ付きのpingのようなプロトコルを実装する適切な方法ですか？ソケットを浪費していますか？私はこれを行うべきであるより良い方法はありますか？

Answer 1

私はあなたのオプションがあると言うだろう：

1. （ICMPエコーパケットを使用して）実際のping。これはオーバーヘッドが低くなりますが、ホストが起動しているかどうかだけを示します。また、パケットの消失、タイムアウト、再送信を処理する必要があります。

2. UDPベースのプロトコル。これはまた、カーネルのオーバーヘッドも低くなりますが、タイムアウトの設定、失われたパケットの処理、再送信を担当します。これは、プログラムがピアで実行されていることを確実に確認できるという利点があります。追加するピアの数にかかわらず、単一のソケットエンドポイントで実装できます。 （すべてがローカルネットワーク上にある場合はブロードキャストで複数のピアに一度に送信することも、マルチキャスト[複雑な設定が必要なこともあります）。

3. TCPソケット今やっている。これはコード作成が非常に簡単で信頼性が高く、タイムアウトを自動的に提供します（ピアが応答しないと、最終的には失敗します）。それはあなたの同輩がそこにあり、プログラムを実行していることを確実に知ることができます。これにはさらに多くのカーネルオーバーヘッドがありますが、ホストごとに1つのソケットエンドポイントを使用することになりますが、何千ものピアがあると思わない限り、重要な問題ではありません。

だから、最後に、あなたが判断する必要があります：ホストの数千人が参加され、このピングが頻繁に起こるために起こっている場合は、UDPソリューションをコーディングしたほうが良いかもしれません。 pingがまれであるか、それほど多くのピアを期待していない場合、私はTCPルートに行きます。 （そして、私はソケットの無駄を考慮しません。その利点はTCPがとても一般的に使用される理由です）。

Answer 2

質問に記載されているテクニックは実際に接続のためにpingを実装しておらず、接続自体が生存しているかどうかをテストします。このテクニックは、ピアが新しい接続をリッスンしている（そして応答している）ことを確認するだけです...

「サーバーはアップしていますか？ 「キープアライブ」のpingよりもテストに適しています。

"キープアライブ" pingを議論している場合、この手法よりも失敗します。

たとえば、接続のreadまたはwriteの部分が閉じていると、わからないことがあります。また、接続が不適切に閉じられた場合（つまり、接続が中断されたため）、pingは問題を公開しません。

一部のネットワーク接続やプロトコルでは、接続のタイムアウトをリセットしないことが最も重要です...そのため、ピアが接続タイムアウトをチェックしている場合、このpingは役に立ちません。

「キープアライブ」のpingについては、特定のプロトコルpingを実装することをお勧めします。

pingが既存の（同じ）接続内で実行され、新しい接続を開く必要がないことを確認してください。