xinetdのサーバーの記述のしやすさは魅力的で、本当に簡単です：stdinとstdoutで動作する任意の言語で簡単なスクリプトを書くことができ（最も単純な場合は通常のREPLです ）、1つのボトルにコンソールユーティリティとネットワークサーバーの両方を取得します。
xinetd構成を編集するために1分後に、telnetまたはnetcatで接続し、コンソールで結果を確認できる稼働中のサーバーを取得します。
すべてが簡単で美しいです。 しかし、（リモート）コンソールユーティリティがあるので、さらに先に進みたいと思います-それで作業を自動化します。 手で何百ものクエリを実行しないでください。また、画面の出力を調べて動作を確認しないでください。 つまり、ネットワーク言語を話すには、クライアント部分が必要です。
ここでは、当然、netcat（nc）を使用します.stdoutにコマンドを発行し、stdinから受信した応答を解釈してnetcatに接続する単純なスクリプトを作成します（したがって、スクリプト自体はこれを認識しませんが）。
このような「サーバー」および「クライアント」スクリプトがあると、ボーナスとしてそれらをローカルで実行する機会が得られます。 コーディング中に、ネットワークの操作に関して1行も記述しなかったという事実は言うまでもありません。
ほとんどの場合、これで十分に機能します。
しかし、 微妙な違いがあります 。
このようなリモートユーティリティをいくつか作成して祝いましたが、この方法で記述されたクライアントとサーバー間の通信プロセスがハングすることがありました。
このトピックについてGoogleで検索することはできませんでした。自分で解決する必要がありました。結果を示します。
誰のせいですか？
xinetdの仕組み：ソケットを開き、標準入出力ストリームにフックして、外部プログラムリンクを起動します。
netcatの仕組み（たとえば、-e）：ソケットを開き、標準入出力ストリームにフックして、外部プログラムリンクを起動します。
つまり、同じです。
したがって、両方のプログラムが端末で動作するように調整されている場合、誰も書き込みまたは読み取りの能力をチェックしません。 読む必要がある場合は、読んでください。 書く必要がある-ただ書く。
端末の代わりに、すでにネットワークソケットがあり、そのようなネットワークで作業する人はいません。
十分な交通量があると、ドラゴンの状況は互いに尾を食い尽くす可能性があります。両側の読み取りバッファーはいっぱいですが、作業サイクルの論理によると、両側はお互いに何かを言いたいだけです。
その結果、両方のプロセスがwrite（）で永久にハングアップします。
最大量のデータを差し引くことで問題を安価に解決しようとしても、問題は解決されず、延期されるだけです。
しかし、この話の中で何よりも、netcatは私を怒らせました。
strace ncでソケットの非ブロックモードを設定するための呼び出しが見つからなかったため、apt-getソースを調べましたが、実際にはそのようなものは見つかりませんでした。
Netcatは同期モードのソケットで動作し、「コンソール用に作成された外部プログラム」がなくても、フリーズの可能性を引き起こします。
悲しみは、netcatが実際には標準であるという事実によって追加されますが、実際には、一般的なケースでの使用には適していません。
どうする
2つの出力があります。
1.ネットワークであることを考慮してxinetdのサーバーを記述します（fcntl O_NONBLOCK、stdinおよびstdoutで選択します）が、xinetdの意味は単純なものの単純なラッパーとして失われます。 すでに完全なサーバーを作成できます。
2.サーバーが応答するのを待機し、読み取りおよび書き込みのためのバッファーオーバーフローを防ぐ同期クライアントを作成します。ここでは、netcatの単純さが失われ、バッファーをオーバーフローせずに複数の要求を同時に送信して複数の処理を行えるように、パフォーマンスで何かを行う必要があります応答。
私の場合、半秒同期オプションを選択しました：
•10件のリクエストを送信する
•送信するものがあるとき{リクエストを1つ送信する。 一つの答えを読む}
•10個の回答を読む
...これは私の特定のケースではうまくいきましたが、一般的な解決策としてはもちろん良くありません。