Proto4J
1.0.0
他のモジュール用のユーティリティの範囲。 LambdaMetafactoryによって作成された関数インターフェイスを介して、インスタンスのフィールド値を設定および取得したり、コンストラクターにアクセスしたりできるLambdaReflectionが含まれています。
あらゆるバッファ実装をサポートする抽象シリアル化ライブラリ。デフォルト型のフィールド、 Proto4jSerializable実装、またはその他の@AutoSerializableメンバーで構成される@AutoSerializableでマークされたクラスを自動的に (逆) シリアル化します。
継承もサポートします。シリアル化可能なクラスは他の@AutoSerializableを拡張でき、その場合、すべての親フィールドも推移的にシリアル化されます。
シリアル化中に無視する必要があるフィールドには、 @Transientの注釈を付ける必要があります。
信頼性を設定可能なカスタム UDP ベースの実装を備えたネットワーキング ライブラリ。
Proto4jServerとProto4jClient使用すると、ソケット間でデータグラムを使用してデータを転送できます。
デフォルトでは、送信データは順序付けされており、信頼性があり、複数の UDP パケットに分割して受信側で結合して戻すことが許可され、配信されることが保証されています。
送信されるすべての UDP パケットは次の構造になっています。
データの送信方法を選択するのはあなたの選択です。送信方法のフラグを指定することで設定できます。これらはすべてProto4jPacketにあります。 Flag 。
次のフラグが使用可能です。
| 名前 | 価値 | 意味 |
|---|---|---|
CONFIRMATION | 0x01 | このパケットが他のパケットが正常に受信されたことを示すものであることを示します。伝送の信頼性のために必要です。通常、内部使用のみを目的としています。 |
PARTIAL | 0x02 | この正確な UDP パケットがより大きなパケットの一部であることをマークします。 CONFIRMATIONフラグと一緒に使用すると、より大きなパケットの一部が配信されたことを示します。 |
UNORDERED | 0x04 | このパケットが順不同で処理できることを示します。 |
UNSIGNED_BODY | 0x08 | デフォルトでは、送信されるすべてのパケットはCRC32 を使用して署名されますが、そのフラグが指定されたパケットの場合は、パケットのヘッダーのみが署名されます。これは、パケットに無効なバイトが含まれる可能性があることを意味します (ただし、データ損失がないことは保証されています)。 |
UNRELIABLE | 0x10 | このパケットを確認を必要としないものとしてマークします。受信者がこのパケットを受信しない場合、送信者はそれに対して何も行いません。 |
INDIVISIBLE | 0x20 | UDP パケットの長さは制限されているため、 Proto4J は巨大なデータをいくつかの小さなパケットに分割します。このフラグは、パケットが単一パケットのサイズ制限を超えた場合に、分割を実行する代わりに例外がスローされることを示します。 |
このレベルではハンドシェイクや ping はサポートされていませんが、 Proto4jSocket .setInitialPacketHandler(BiConsumer<C, Proto4jPacket>)メソッドを使用して独自のパケット ハンドラーをセットアップできます。この時点に到達するパケットにはCONFIRMATIONフラグやPARTIALフラグが付けられることはありません。そのため、そこで処理されるすべてのProto4jPacketインスタンスには、送信者によって送信された正確なデータ ( UNSIGNED_BODYフラグまで) が含まれます。
また、ソケットを開始するときにCompletionStage<Void>が返されます。これは、ソケット間の通信ロジックを開始するのに役立ちます。
Proto4Jでソケットをインスタンス化しようとしているときは、ワーカー スレッドとハンドラー スレッドをソケット コンストラクターに渡す必要があります。
ワーカーはソケットからデータを読み取るためにのみ使用されます。
ハンドラーは、新しいパケットが出現したときにロジックを処理するために使用されます。
これは、前のレベルよりも高いレベルのインターフェイスです。これを使い始めるには、 Proto4jHighServerとProto4jHighClient 、またはその基本実装であるBaseProto4jHighServerとBaseProto4jHighClientを見てください。
クライアントは最初にサーバーと対話するときにハンドシェイクを開始します。完了後、サーバーとクライアントは接続が失われないように相互に ping を実行します。
Low levelとは対照的に、生のバイトを操作するだけでなく、複雑なエンティティを使用してネットワーク全体に高レベルのパケットを送信することもできます。これを行うには、 EnumeratedProto4jPacketまたはCallbackProto4jPacketを拡張する独自のクラスを作成します。これを機能させるために必要なのは、 write(Buffer)メソッドとread(Buffer)メソッドを実装し、両側のPacketManagerにパケットを登録することだけです。
また、 Proto4jPacketの代わりにこれらのパケットを処理する代替PacketHandlerクラスもあります。
送信されたパケットに対する応答を待つのが一般的なシナリオです。これらの機能はこのレベルですでに実装されています。最大待機時間を指定し、希望する方法で応答を処理できます。これは、 HighChannel使用して最初のパケットを送信することで実行できます。 sendWithCallback(CallbackProto4jPacket)メソッド。
以下は、モジュールの内部動作に影響を与えるために使用できるシステム プロパティのリストです。時間値はすべてミリ秒単位で指定します。
| 名前 | デフォルト値 | 説明 |
|---|---|---|
proto4j.maxDatagramSize | 508 | 許可されるデータグラムの最大サイズ。 UDP パケット全体のサイズがカウントされることに注意してください。 |
proto4j.maxSequenceNumber | 2_000_000_000 | パケットの最大シーケンス番号。内部カウンタがこの値に達すると、ゼロにリセットされます。 |
proto4j.reliabilityThreshold | 20 | 未確認の（ UNRELIABLEフラグがマークされていない）パケットの遅延。 |
proto4j.callbacksRegistryDelay | 100 | コールバックのレジストリ チェックがタイムアウトしたコールバックを取得する速度。 |
proto4j.callbacksInitialDelay | 500 | これは、パケットが送信され、待機時間が明示的に指定されていない場合に常に使用されるデフォルトの時間です。 |
proto4j.highTimeout | 10_000 | サーバーがクライアントからパケットを長期間受信しない場合、クライアントは切断されます。 |
proto4j.highPingDelay | 1_000 | サーバーは、その期間クライアントとの送受信がなかったことを示すと、クライアントに応答を送信し、ping パケットを待ちます。 |
これは、高レベル API よりも高レベルの API です。パケットとその処理を手動で実装する代わりに、サービスを介して作業します。
操作を開始するには、 RpcServerとRpcClient使用します。
このレベルのサーバーはルーティングの目的でのみ使用されますが、クライアントはサービス ユーザーと実装者の両方として機能します。
サービスはインターフェース部分と実装部分で構成されます。サービス ユーザーは、 RpcClient .getServiceManager().getService(Class<S>)を介してサービス インターフェイス インスタンスを取得できます。そのすべてのメソッドは登録された実装にプロキシされ、リモートで実行されます。
独自のサービスを作成するには、インターフェイスから開始し、それに @Proto4jService の注釈を付けます。
サービス インターフェイスにはデフォルト メソッドと静的メソッドを持つことが許可されていますが、戻り値の型はvoid 、serializable、または以前の型のCompletionStageである必要があります。また、すべての引数はシリアル化可能である必要があります。
シリアル化可能な型は次のとおりです。
StringとUUID@AutoSerializableアノテーションが付けられたクラスBufferSerializable実装するクラスList 、 Set 、 Map登録されているすべてのサービス実装でメソッドを実行する必要がある場合は、 @Broadcastの注釈を付ける必要がありますが、そのようなメソッドはvoidまたはCompletionStage<Void>のみを返すことができます。
デフォルトでは、メソッドを呼び出すと、ランダムな実装で実行されます。実行分散を制御したい場合は、メソッドの引数の一部を@Indexでマークします。メソッドが呼び出されるたびに、マークされた引数のハッシュ コードに基づいて実装が選択されます。
サービスが登録されるたびに、すべてのメソッドが整数の識別子に変換されます。同じ識別子を持つ 2 つのメソッドは存在できませんが、そのような状況が発生する可能性があります。これを処理するには、明示的に指定された静的識別子を使用してメソッドに@MethodIdentifierアノテーションを付けます。
すでにサービス インターフェイスを作成している場合は、その実装を作成し、 RpcClient .getServiceManager().registerService(Class<S>, I)使用して登録します。
一般的なシナリオは、2 組のクライアントにサービス インターフェイスがあり、そのうちの 1 組にのみ実装されているというものです。
これは、基本的な RPC の上位層です。
分散バックエンド (マイクロサービスなど) を作成する場合、障害点の数を最小限に抑えることをお勧めします。前のセクションで説明したスキームには障害点が 1 つだけあり、それは単一のサーバー インスタンスです。 Conclave は、同時に動作する一連のサーバーです。
Conclave上のすべてのサーバーは相互に接続されていますが、すべてのクライアントは 1 つのサーバーにのみ接続されています。 RPC クエリはネットワーク全体に適切に分散およびルーティングされるため、心配する必要はありません。
Conclaveの使用を開始するには、 RpcConclaveServerとRpcConclaveClientを参照してください。これらのいずれかをインスタンス化するには、 List<InetSocketAddress> (すべてのサーバーの宛先ポイントのリスト) を渡す必要があります。
Transportモジュールに関しては、 RPCモジュールで検索される一連のシステム プロパティがあります。
| 名前 | デフォルト値 | 説明 |
|---|---|---|
proto4j.conclaveWorkers | 2 | 各サーバー内部クライアント (他のサーバーへのアクセスに使用されている) によって使用されるワーカー スレッドの数。 |
proto4j.conclaveHandlers | 2 | 各サーバー内部クライアント (他のサーバーへのアクセスに使用されている) によって使用されるハンドラー スレッドの数。 |
proto4j.conclaveTimeout | 1_000 | 他のサーバーとのハンドシェイクが完了するまでサーバーが待機する最大時間。それ以外の場合、後者は実行されていない接続とみなされ、自身の接続試行が終了します。その場合、接続は、起動時に別の接続からの要求があった場合にのみ再開されます。 |
