コマンドと応答の相互作用を高速化するためのプロトコルを設定する必要があります。私の本能は、SMTPやPOP3の動作のように、CRLFで区切られたASCII文字列を使用して単純なプロトコルを組み合わせ、セキュリティで保護する必要がある場合はSSH/SSLを介してトンネリングするように指示しています。
これは可能ですが、OSが提供するソケットライブラリインターフェイスではなく、使いやすいライブラリを使用できるように、既存のテクノロジに基づいて構築することをお勧めします。
私は欲しい...
何かアイデアはありますか？
要求/応答だけが必要な場合、HTTP は非常に単純です。それはすでに要求/応答プロトコルです。クライアント側とサーバー側は、ほとんどの言語で広く実装されています。それを拡大することはよく理解されています。
これを使用する最も簡単な方法は、コマンドを POST 要求としてサーバーに送信し、サーバーが応答の本文で応答を返すことです。独自の動詞を使用して HTTP を拡張することもできますが、その場合、キャッシング プロキシや HTTP を理解するその他のインフラストラクチャを利用する方が効率的になります。
非同期通知が必要な場合は、pub/sub プロトコル (Spread、XMPP、AMQP、JMS 実装、または TibcoRV、Tibco EMS、Websphere MQ などの商用 pub/sub メッセージ ブローカー) を調べてください。選択するプロトコルまたは実装は、構築しているシステムの信頼性、レイテンシ、およびスループットのニーズによって異なります。たとえば、ネットワークが混雑しているときに通知がドロップされても問題ないでしょうか。クライアントがオフラインの場合、通知はどうなりますか? クライアントが再接続したときに通知が破棄されるか、キューに入れられますか。
AMQPは有望に聞こえます。あるいは、XMPPは、かなりのオーバーヘッドがありますが、必要なものの多くをサポートしていると思います。
とはいえ、達成しようとしていることによっては、単純なアドホックプロトコルの方が簡単な場合があります。
SNMPのようなものはどうですか？アプリが使用するモデルに正確に適合するかどうかはわかりませんが、非同期通知とプル (つまり、TRAP と GET) の両方をサポートしています。
これは考慮すべき変数が非常に多い素晴らしい質問です。この質問では、パケット形式、非同期メッセージングと同期メッセージング、およびセキュリティなど、いくつかの変数のみが言及されています。考えられることは他にもたくさんあります。7 層のプロトコル スタック (OSI/ISO) の説明に目を通し、それらの層で何が必要か、その層を構築するか、他の場所から取得するかを自問することをお勧めします。(主にレイヤ 6 と 7 に関心があるようですが、下位レイヤについても言及されています。)
これが安全性が重要なアプリケーションであるか、正式な V&V を備えたシステムの一部であるかについても考えてください。本当に優れた信頼できる通信システムを設計するのは簡単ではありません。また、「能力の低い」プロトコルは、エラー回復を行うためにアプリケーションに多くのコーディングの負担をかける可能性があります。
最後に、あなたのアプリケーションに似た他のアプリケーションがどのように機能するかを調べることをお勧めします (オープンソースをチェックする、本を読むなど)。また、米国特許庁のデータベースなども役立ちます。彼らが解決しようとしていたコミュニケーションの問題の説明を読むだけで、素晴らしいアイデアを得ることができます。