私はperlipc perldocを読んでいて、「IO::Socket を備えた対話型クライアント」というタイトルのセクションに混乱していました。これは、サーバーに接続してメッセージを送信し、応答を受信し、別のメッセージを送信し、応答を無限に受信するクライアント プログラムを示しています。著者の Tom Christiansen は、クライアントを単一プロセスのプログラムとして書くのは「はるかに難しい」と述べ、STDIN の読み取りとサーバーへの送信専用の子プロセスを fork する実装を示し、親プロセスは次の読み取りを行います。サーバーからSTDOUTに書き込みます。
これがどのように機能するかは理解していますが、単一プロセスのプログラムとして書くのが (難しいというよりも)単純ではない理由がわかりません:
while (1) {
read from STDIN
write to server
read from server
write to STDOUT
}
多分私は要点を見逃しているかもしれませんが、これは悪い例のように思えます。クライアントが次のクエリを入力している最中に、サーバーが突然別のことを考えて端末に文字を挿入する可能性があるクライアント/サーバー アプリケーション プロトコルを実際に設計することはありますか?
更新 1:この例では非同期性が許可されていることを理解しています。私が困惑しているのは、CLIクライアントとサーバー間の同時 I/O が望ましい理由です (端末でのテキストの入力と出力がごちゃ混ぜになるため)。クライアント/サーバーであろうとなかろうと、それを行うCLIアプリは考えられません。
更新 2:ああ!! 当たり前ですが、クライアントから送信されたすべての行に対して、サーバーから送信された行が1行だけある場合にのみ、私のソリューションは機能します。サーバーが応答で不明な数の行を送信できる場合、「サーバーからの読み取り」ループに座らなければなりません。プロトコルで特別な「応答終了」トークンが定義されていない限り、ループは終了しません。送信と受信を別々のプロセスで処理することにより、「応答の終了」の検出を端末のユーザーに任せることができます。
(通常、コマンド プロンプトを生成するのはクライアントなのか、それともサーバーなのか? 私は常にクライアントだと思っていましたが、今ではサーバーである方が理にかなっていると考えています。)