8

ローカル「サーバー」と GUI クライアントで構成されるアプリがあります。サーバーは Python で作成されていますが、GUI は変更可能であることを意図しており、Flex 4 で作成されています。クライアントはローカル サーバーに情報を照会し、それに応じて表示します。どちらのアプリケーションも同じコンピューターで実行することを想定しており、ローカルでのみ通信します。現時点では、クライアントと Python サーバーは基本的なソケットを介して通信し、クライアントがリクエストをソケットに書き込み、ソケットがデータを返します。

しかし、私はデスクトップ アプリを書いているので、ソケットの代わりに標準ストリームを使用するシステムを維持し、洗練する方が簡単かもしれないと考えました。サーバーは継続的にリッスンしraw_input()、stdin に書き込まれた内容に従って出力します。この場合、クライアントは、NativeProcessソケットを使用するのではなく、AIR のクラスを使用して stdout と stdin の読み取りと書き込みを行います。

クライアントとサーバーは別々のプロセスですが、ほぼ同時に開始されることを意図しています。複雑なネットワーキングは必要ありません。ローカルの言語間コミュニケーションだけが必要です。

各アプローチの長所と短所は何ですか? ソケットを使用することで得たり失ったりするものと、標準ストリームを使用して通信することで得たり失ったりするものは何ですか? どちらがより効率的ですか?メンテしやすいのはどっち?

4

1 に答える 1

11

UNIX ライクなプラットフォームでは、stdin/stdout の使用はソケットであるため、違いはありません。つまり、stdout をリダイレクトしてプロセスを起動する場合、通常は socketpair を使用して実行されるため、独自の UNIX ドメイン ソケットを作成して通信する必要はありません。ただし、stdin/stdout を処理するための Python クラスでは、基礎となるソケットの完全な柔軟性にアクセスすることはできないため、自分で設定する必要があります。たとえば、Windows sys::stdin をソケットにすることはできませんし、常に UNIX 上にあるわけでもないため、そのクロスプラットフォームを提供することはできません)。

ローカル TCP 接続の良いところは、それがクロスプラットフォームであり、どこでも予測可能なセマンティクスを提供することです。たとえば、出力を閉じて入力から読み取ることができるようにしたい場合は、どこでも同じソケットを使用してこの種のことを行う方がはるかに簡単です。それがなくても、わかりやすくするために、TCP ソケットを使用することは、名前付きパイプの風変わりな Windows の混乱を回避するための合理的な方法です。

于 2013-03-12T18:31:44.270 に答える