私は、単一のサーバーに対してユーザーのデスクトップで複数の GUI クライアントを実行するプロジェクトに取り組んでいます。クライアントはグローバルに分散され、WAN 経由で接続されます。
GUI 自体のリリース パッケージとは別に、クライアント PC で実行されているアプリケーションに依存関係がないことを確認したいと考えています。トランスポート自体は信頼できるものでなければなりません (メッセージがドロップされず、未確認のメッセージが再生されます)。
私は、アプリケーション用のカスタム TCP ソケット ベースのトランスポートを作成し、ドロップされたメッセージや未確認のメッセージを検出するロジックを実装することを考えました。
ActiveMQ (TCP/IP トランスポート経由で JMS を使用) の使用も検討しています。他の代替案や提案はありますか？
編集: TCP は信頼できるトランスポートですが、クライアントが切断または再起動した場合にドロップされた可能性のあるメッセージを検出して再生する必要があります。
TCP は、アプリケーション エラーやクラッシュのない幸せな世界での配信を保証します。
一部の TCP データはネットワーク スタックによって認識される場合がありますが、処理される前に、アプリケーションがクラッシュ (またはサーバー クラッシュ) した可能性があります。
トランザクションを使用した ActiveMQ を使用すると、それらを処理できます。AMQ のアプリケーション層の ack でも信頼性が得られますが、システムの複雑さが増します (もちろん)。
TCP [伝送制御プロトコル] は、これらすべてを既に処理しています。
すべてのデータを取得し、正しい順序で取得するか、送信者に一部のデータを送信できないことが通知されることを保証します。すべての TCP パケットにはストリーム内の位置が含まれており、プロトコルは受信した各パケットに対して肯定応答を送信します。送信者が確認応答を受信しない場合、受信者が持っていない可能性のあるすべてのデータを再送信します。レシーバーは、アプリケーション層が必要とするデータ (常にストリームの次のバイト) を取得した後でのみ、そのデータをアプリケーション層に送ります。
TCP 接続がデータを送受信できない場合 (データを受信しないという理由だけでなく)、TCP は最終的にあきらめ、送信側で I/O 例外が発生します。受信者がデータを受信する必要があることを知っている場合 (または送信するデータがある場合、またはキープアライブを有効にしている場合)、受信者もあきらめます。TCP プロトコルがあきらめるまでの時間を調整できます。デフォルト値で十分です。
切断によって失われたデータの量を知りたい場合 (ただし、クライアントはすぐには接続されない可能性があります)、アプリケーション層でも確認応答を送信できます。I/O 例外が発生した場合 (例外が発生した場合のみ)、最後に確認されたメッセージ ID をデータベースに保存し、再接続時に転送を再開します。
TCP で失われたパケットを再送信したくない場合は、代わりに UDP を使用してください。UDP は、受信者が受信したもの、送信者が送信したもの、および同じパケットを 2 回配信しようとしないという 2 つのことのみを保証します。