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