質問
ネットワークプロトコルを使用して、サードパーティによって拡張される既存のスタンドアロンアプリケーションがあります。機能は既に実装されています。必要なのは、それらを外部に公開することだけです。
トランスポートプロトコルが既に選択されている(UDP)と仮定すると、アプリケーションプロトコルの設計に役立つリソースはありますか?
ソフトウェア設計に関する多くの情報があるようですが、プロトコル設計に関する情報はありません。 すでにアプリケーションプロトコルの設計を見ました。
解決
Jabberプロトコルの設計ガイドラインおよび RFC 4101 。レビュー担当者がRFCを理解しやすくすることを目的としていますが、このRFCは興味深いアドバイスを提供します。
他のヒント
Googleプロトコルバッファーをご覧になりましたか?この問題を解決する良い方法のようです。
既存のアプリと通信し、protobufferプロトコルを使用して「外部」から応答するエンドポイントを作成できます。バイナリであるため、小さくて高速であり、独自のプロトコルマネージャを記述する必要はありません。Googleのプロトコルマネージャを使用できるからです。欠点は、システムの両側(「サーバー」側およびコンシューマー/クライアント側)に実装する必要があることです。
プロトコルバッファに関する別の推奨事項-少し手間をかけずにすてきなタイトなバイナリ。ただし、バイナリプロトコルは十分に定義されていますが、合意されたRPC標準はまだありません(いくつかは進行中です。TCPまたはHTTPに傾く傾向があります。
この仕様により、クライアントとサーバーを異なるアーキテクチャに簡単に配置できます、これは優れています-さらに、拡張可能です。
警告:私は、 .NETバージョンの著者です。 、だから私は偏っているかもしれません;-p
まず、UDPは主に一方向のブロードキャスト転送方式です。また、損失が発生する可能性があるので、欠落したパケットや異常なパケットを処理できる必要があります。 UDPに何らかのレベルの信頼性が必要な場合、または双方向接続が必要な場合は、TCPからのほぼすべてが必要になるため、最初からネットワークスタックで処理するようにしてください。
次に、データが単一のIPパケットよりも大きい可能性がある場合、各パケットの開始と終了を識別する方法、および違法または破損したパケットを処理する手段が必要になります。パケット長のあるヘッダー、フッター、チェックサムをお勧めします。
次に、メッセージと応答をエンコードする何らかの方法が必要です。周りには多くのRPCプロトコルがあります。 SOAPを見るか、カスタムXMLベースのプロトコル、またはバイナリプロトコルを設計できます。
独自のプロトコルを設計、文書化、維持するか、既存のものを使用するかを真剣に検討する必要があります。ニーズに合った文書化されたプロトコルがすでに存在する可能性があります。あなたが何をしているのかにもよりますが、おそらく最初はやり過ぎに見え、すべての仕様を実装するのは退屈に見え、自分で書くよりもはるかに面白くありませんが、数年後にアプリケーションを積極的に開発するつもりなら、既に存在し、サードパーティに知られているものを使用するために多くの時間とお金。また、そのプロトコルに既存のライブラリを使用できる場合、実装部分ははるかに高速になります。
新しいプロトコルを設計することは、実装するよりも楽しいが、すべての欠陥に耐えなければならないので、維持するよりも楽しい。完璧なプロトコルはありませんが、一度も設計したことがない場合は、代わりに使用できる既存の有名なプロトコルを設計した人々よりも間違いを犯すことを確信できます。
要するに、可能な限り既存のものを活用します。
プロトコルをゼロから構築したくない場合は、 SOAP 。サポートはプログラミング言語によって異なりますが、クロスランゲージコミュニケーションが明確に推奨されます。
残念ながら、UDPとSOAPはまだ初期段階にあるようです。HTTPが最も一般的に使用されています。
XMLを選択する場合、マークアップのオーバーヘッドが非常に大きくなることに注意してください。
単純なバイナリプロトコルも、xmlと比較して解析するためにそれほど多くのリソースを必要としません。
ネットワークプロトコルを使用して、サードパーティによって拡張される既存のスタンドアロンアプリケーションがあります。
あなたのプログラムが何をするのか、そしてこれらのサードパーティの拡張機能の性質についてもう少し知っておくと役立ちます。たぶん、UDPを使用する理由はありますか?