Rpc

Effectuez des lots de requêtes RPC.

Cette opération exécute de manière asynchrone soit une seule requête RPC, soit un lot de requêtes. Les requêtes RPC sont définies par trois paramètres principaux :

- `address` (l'hôte+port ou l'adresse BNS de la requête) - `method` (le nom de la méthode RPC pour la requête) - `request` (la chaîne proto sérialisée, ou vecteur de chaînes, de l'argument de la requête RPC) .

Par exemple, si vous avez un service RPC exécuté sur le port localhost:2345 et que son interface est configurée avec la déclaration proto suivante :

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

appelez cette opération avec des arguments :

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

Le tenseur `request` est un tenseur de chaîne représentant chaînes `MyRequestProto` sérialisées ; et le tenseur de chaîne de sortie « réponse » aura la même forme et contiendra (une fois terminé avec succès) les chaînes sérialisées « MyResponseProto » correspondantes.

Par exemple, pour envoyer un seul `MyRequestProto` vide, appelez cette opération avec `request = ""`. Pour envoyer 5 requêtes vides parallèles , appelez cette opération avec `request = ["", "", "", "", ""]`.

Plus généralement, on peut créer un lot de protos sérialisés `MyRequestProto` à partir de tenseurs par lots réguliers à l'aide de l'opération `encode_proto`, et convertir la réponse des protos sérialisés `MyResponseProto` en tenseurs par lots à l'aide de l'opération `decode_proto`.

REMARQUE Travailler avec des chaînes de protos sérialisées est plus rapide que d'instancier des objets proto réels en mémoire, donc aucune dégradation des performances n'est attendue par rapport à l'écriture de noyaux personnalisés pour ce flux de travail.

Si la connexion échoue ou si le travailleur distant renvoie un état d'erreur, l'opération relance cette exception localement.

Voir l'opération `TryRpc` si vous préférez gérer manuellement les échecs RPC dans le graphique.