ローカル クライアント サーバー モデルを検討している Python でプログラムを作成していますが、サーバーがクライアントと通信するための最良の方法を見つけるのに苦労しています。シンプルな既製のソリューションが最適です。車輪を再発明するつもりはありません。このプログラムに対する私のニーズは次のとおりです。
- Linuxで実行
- サーバーとクライアントは同じシステム上にあるため、ネットワークを経由する必要はありません。
- インタラクティブなユーザーにとって煩わしくないレイテンシ。
- 複数のクライアントが同じサーバーに接続できます。
- クライアントはサーバーとは独立して起動され、いつでも接続/切断できます。
- クライアントの数は数十に及びます。非常に高くスケーリングする必要はありません。
- クライアントには、いくつかの異なるフレーバーがあります。
- ストリーム リーダー - データの連続ストリームを読み取ります (実際には、これはすべてテキストです)。
- 状態リーダー - 時々更新されるいくつかの状態情報を読み取ります。
- ライター - サーバーにデータを送信し、毎回応答を受け取ります。
クライアント タイプ 1 は単純に思えます。それは一方向のダムパイプです。クライアント タイプ 2 はもう少し興味深いものです。サーバーを単純にポーリングして新しいデータを定期的にチェックすることは避けたいと思います。これは、ユーザーにとって顕著な遅延が追加されるためです。サーバーは、クライアントがサーバーから更新された状態を受信できるように、状態情報が更新されたときに、関連するすべてのクライアントのみに通知する何らかの方法を必要とします。クライアント タイプ 3 は双方向である必要があります。ユーザーが提供したデータをサーバーに送信し、送信するたびに何らかの応答を受け取ります。
Python の IPC ページ ( http://docs.python.org/2/library/ipc.html ) を見てきましたが、これらのソリューションのいずれも私のニーズに合っているとは思いません。subprocess モジュールは完全に不適切であり、他のすべては私が望むよりも少し低レベルです。
同様の質問Efficient Python to Python IPCはまったく同じではありません。Python オブジェクトを転送する必要はありません。使用するクライアントの数に対する CPU 効率については特に心配していません。Linux のことしか気にかけません。とにかく、その質問に対する答えはどれも特に役に立ちません。
アップデート：
フレームワーク/ライブラリ/モジュール/ツールを指し示すだけの答えを受け入れることはできませんが、3つの異なるサーバーとクライアントの関係にどのように使用できるかを実際に説明する必要はありません。「名前付きパイプで全部できる！」と言うなら。「どうやって？」と尋ねなければなりません。コード スニペットが理想的ですが、ソリューションの概要を説明することもできます。