TryRpc

בצע קבוצות של בקשות RPC.

פעולה זו מבצעת באופן אסינכרוני בקשת RPC בודדת, או אצווה של בקשות. בקשות RPC מוגדרות על ידי שלושה פרמטרים עיקריים:

- `כתובת` (המארח+פורט או כתובת ה-BNS של הבקשה) - `שיטה` (שם השיטה לבקשה) - `request` (מחרוזת הפרוטו המסודרת, או וקטור המחרוזות, של ארגומנט הבקשה RPC).

לדוגמה, אם יש לך שירות RPC שפועל על port localhost:2345, והממשק שלו מוגדר עם הצהרת הפרוטו הבאה:

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

אז קרא ל-op זה עם ארגומנטים:

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

טנסור ה-'request' הוא טנסור מחרוזת המייצג מחרוזות 'MyRequestProto' בסידרה; ולמחרוזת הפלט 'תגובה' תהיה אותה צורה והיא תכיל (עם השלמתה מוצלחת) מחרוזות 'MyResponseProto' תואמות.

לדוגמה, כדי לשלוח יחיד, ריק, `MyRequestProto`, קרא למבצע הזה עם `request = ""`. כדי לשלוח 5 בקשות ריקות מקבילות , התקשר לפעולה זו עם `request = ["", "", "", "", ""]`.

באופן כללי יותר, אפשר ליצור אצווה של 'MyRequestProto' פרוטו סדרתי מטנזורים אצווה רגילים באמצעות האופציה של 'encode_proto', ולהמיר את התגובה 'MyResponseProto' פרוטו סידורי לטנזורים אצווה באמצעות האופ של 'decode_proto'.

הערה עבודה עם מחרוזות פרוטו מסודרות מהירה יותר מאשר מופע של אובייקטי פרוטו ממשיים בזיכרון, כך שלא צפויה ירידה בביצועים בהשוואה לכתיבת גרעינים מותאמים אישית עבור זרימת עבודה זו.

בשונה מהאופציה הרגילה של `Rpc`, אם החיבור נכשל או שהעובד המרוחק מחזיר סטטוס שגיאה, פעולה זו אינה מעלה מחדש את החריג. במקום זאת, הערך `status_code` ו`status_message` עבור קריאת ה-RPC המתאימה מוגדרים עם השגיאה שהוחזרה משיחת ה-RPC. טנסור ה-'response' יכיל ערכי תגובה חוקיים עבור אותם ערכי מיני-אצט שה-RPC שלהם לא נכשל; לשאר הערכים יהיו מחרוזות ריקות.