My Server-AppはTIdTCPServerを使用し、いくつかのクライアントアプリケーションはTIdTCPClientを使用してサーバーに接続します（すべてのコンピューターは同じLANにあります）。ベストプラクティス：転送ごとにTCP/IP接続を開いたままにするか閉じる
クライアントの中には、数分おきにサーバーに接続する必要があるものもあれば、1秒に1回しかなくても1秒に20回程度しかないものもあります。
クライアントとサーバーの間の接続を開いたままにしておくと、再接続は保存されますが、接続が失われているかどうかを確認する必要があります。
転送ごとに接続を閉じると、毎回再接続する必要がありますが、接続がまだ存在するかどうかを確認する必要はありません。
これを行うにはどのような方法が最適ですか？
データ転送の頻度は一般的にオープンにしておく必要がありますか？
両方のシナリオには他にどのような長所と短所がありますか？
私は2つの組み合わせをお勧めします。新しい接続が開かれたら、アイドルタイマーを開始します。データが交換されるたびに、タイマーをリセットします。タイマーが経過したら、接続を閉じます。データを送信する必要があるときに接続が閉じられている場合は、新しい接続を開いて繰り返します。こうすることで、使用頻度の低い接続を定期的に閉じることができますが、頻繁に使用される接続は開いたままにしておくことができます。
レミー、素晴らしい作品私はIndyのTCPコンポーネントを広範囲に使用しています。私は分散アプリケーションフレームワークの本質的な部分として広範囲に使用しています。あなたはそれを見てみたいかもしれません。 – Misha
数分おきに1回アクティブなアプリケーションで接続や切断を行うと問題が発生することがありますが、接続を開いたままにするとパフォーマンスが向上します。
また、開いている接続を常に開いたり、閉じたり、診断したりしない場合は、コードが非常に簡単になります。適切なオープンとクローズのロジックとSEHを読んだり書いたりすることで、ソケットを使用する前に接続しているかどうかをテストする必要はありません。それは問題があるときあなたに教えてくれるでしょう。
私はほとんどのエンタープライズアプリケーションで単一の接続を開いたままにしておくことにします。一般的には、コードをよりクリーンにすることができ、管理しやすくなります。実験から
/twocents
二セント...
私の最初のTCP/IPクライアント/サーバーアプリケーションが要求ごとに新しい接続や新しいスレッドを使用していた...年前...次に、閉鎖された接続はすべて実際には破棄されず、しばらくの間は特定の状態にとどまるため、ネットワークリソースを消費していることがわかりました（ProcessExplorerを使用）。多くのスレッドが作成されました...
私は多くの並行したリクエストにいくつかの接続の問題がありました。サーバーに十分なポートがありませんでした。
したがってI rewrote it、HTTP/1.1方式、およびKeepAliveの機能に従います。それはずっと効率的で、少数のスレッドを使い、ProcessExplorerは私の新しいサーバーが好きです。私は決して港をもう一度使い果たしません。 :)
クライアントをシャットダウンする必要がある場合、私は、少なくとも、クライアントごとにスレッドを作成しないためにのThreadPoolを使用します...要するに
：あなたができるならば、あなたのクライアントを保ちます接続は数分間生きています。
私はそれがあなたの目標と、サーバー上の利用可能な帯域幅とハードウェアについて言及していない特定の時間にサーバー上で行われた要求の量に左右されますね。
あなたは将来も考えなければなりません。将来的には接続を開いておく必要がありますか？もしそうなら、あなた自身の質問に答えました。
チャットシステムは、〜50人（2ヶ月ごとに増えています）が常に接続されているチャットシステムを実装しました。チャットの他に、データ転送、特定のコマンドを使用したデータベース操作なども含まれます。実装はサーバーへの接続をアプリケーションの起動からアプリケーションの終了まで開いたままにしていますが、これまでの問題はありませんが、何らかの理由で接続が失われた場合、自動的に再確立され、
全体的には、接続を開いたままにして使用した後で閉じることをお勧めします。
何百もの同時接続にスケーリングしていない限り、私は間違いなくオープンにしています - これは2つのオプションのほうが優れています。過去数百人を一度に何千もの同時接続に拡張したら、削除して再接続する必要があります。私はこれが（http://www.csinnovations.com/framework_overview.htm）の周りの私の全体のフレームワークを設計したので、必要な時にいつでもサーバからクライアントにデータを「プッシュ」することができます。接続が稼働していること（ネットワークのドロップアウト、時間指定されたpingなど）を確実にするためにかなりのコードを書く必要がありますが、 "フレームワーク"でこれを行うと、アプリケーションコードはそのような接続が常に「アップ」していると仮定することができます。
問題は、アプリケーションあたりのスレッド数が約1400スレッドに制限されていることです。最大1300のクライアントが同時に接続されます。+ - 。
OSスレッドプールは（クライアントスレッドではなく）Indyサーバーで実装されているとは思っていますが、あなたがここで主張していることは正しくありません。 https://blogs.msdn.microsoft.com/oldnewthing/20050729-14/?p=34773 – Victoria
クライアントとして接続を閉じると、使用していたポートはしばらく使用できなくなります。したがって、大容量では異なるポートの負荷を使用しています。何か繰り返しのために私はそれを開いたままにしておきます。
新しいTCP接続を作成するオーバーヘッドは、主に数回のラウンドトリップです。 LAN上ではかなり高速です。だから私はそれを使用しないで数秒後に接続を閉じるだろう。 – CodesInChaos
しかし、私はシンプルな方法（ほとんどの場合は即時閉鎖）でそれを書いて、パフォーマンスが満足できるかどうかをチェックします。 – CodesInChaos
この質問への私の答えを参照してください：http://stackoverflow.com/questions/4872800/socket-open-and-close-on-1-sec-or-to-hold-open/4873002#4873002 –