TryRpc

RPCリクエストのバッチを実行します。

この操作は、単一のRPC要求または要求のバッチのいずれかを非同期的に実行します。 RPCリクエストは、次の3つの主要なパラメータによって定義されます。

-`address`（リクエストのホスト+ポートまたはBNSアドレス）-`method`（リクエストのメソッド名）-` request`（RPCリクエスト引数のシリアル化されたプロト文字列または文字列のベクトル）。

たとえば、ポートlocalhost：2345でRPCサービスを実行していて、そのインターフェイスが次のproto宣言で構成されている場合：

service MyService {
   rpc MyMethod(MyRequestProto) returns (MyResponseProto) {
   
 };
 }

次に、引数を指定してこのopを呼び出します：

address = "localhost:2345"
 method = "MyService/MyMethod"
 

`request`テンソルは、シリアル化された` MyRequestProto`を表す文字列テンソルです文字列;また、出力文字列テンソル `response`は同じ形状を持ち、（正常に完了すると）対応するシリアル化された` MyResponseProto`文字列を含みます。

たとえば、単一の空の `MyRequestProto`を送信するには、` request = "" `を指定してこの操作を呼び出します。 5つの並列の空の要求を送信するには、このopを `request = [" "、" "、" "、" "、" "]`で呼び出します。

より一般的には、 `encode_proto`opを使用して通常のバッチテンソルから` MyRequestProto`シリアル化されたプロトのバッチを作成し、 `decode_proto`opを使用して応答` MyResponseProto`シリアル化されたプロトをバッチテンソルに変換できます。

注シリアル化されたプロト文字列の操作は、メモリ内の実際のプロトオブジェクトをインスタンス化するよりも高速であるため、このワークフローのカスタムカーネルを作成する場合と比較して、パフォーマンスの低下は予想されません。

標準の `Rpc`操作とは異なり、接続が失敗した場合、またはリモートワーカーがエラーステータスを返した場合、この操作は例外を再発生させません。代わりに、対応するRPC呼び出しの `status_code`および` status_message`エントリは、RPC呼び出しから返されたエラーで設定されます。 `response`テンソルには、RPCが失敗しなかったミニバッチエントリの有効な応答値が含まれます。残りのエントリには空の文字列が含まれます。