انجام دسته ای از درخواست های RPC.
این عملیات به صورت ناهمزمان یا یک درخواست RPC یا دسته ای از درخواست ها را انجام می دهد. درخواست های RPC توسط سه پارامتر اصلی تعریف می شوند:
- "آدرس" (میزبان+پورت یا آدرس BNS درخواست) - "روش" (نام روش برای درخواست) - "درخواست" (رشته پروتوی سریال یا بردار رشتهها، آرگومان درخواست RPC).
برای مثال، اگر یک سرویس RPC دارید که روی پورت localhost:2345 اجرا میشود و رابط آن با اعلان پروتو زیر پیکربندی شده است:
service MyService {
rpc MyMethod(MyRequestProto) returns (MyResponseProto) {
};
}
این عملیات را با آرگومانها فراخوانی کنید: address = "localhost:2345"
method = "MyService/MyMethod"
تانسور `درخواست` یک تانسور رشتهای است که نشان دهنده آن است. رشته های سریال MyRequestProto. و «response» تانسور رشته خروجی همان شکل را خواهد داشت و (پس از تکمیل موفقیت آمیز) رشته های «MyResponseProto» سریالی متناظر را شامل می شود.به عنوان مثال، برای ارسال یک «MyRequestProto» خالی، این عملیات را با «درخواست = «»» فراخوانی کنید. برای ارسال 5 درخواست خالی موازی ، این عملیات را با `درخواست = ["، "، "، "، ""]` فراخوانی کنید.
بهطور کلیتر، میتوان یک دسته از پروتوهای سریالی MyRequestProto را از تانسورهای دستهای معمولی با استفاده از عملیات «encode_proto» ایجاد کرد و با استفاده از عملیات «decode_proto»، پروتوهای سریالسازی شده «MyResponseProto» را به تانسورهای دستهای تبدیل کرد.
نکته کار با رشته های پروتو سریالی سریعتر از نمونه سازی اشیاء پروتو واقعی در حافظه است، بنابراین در مقایسه با نوشتن هسته های سفارشی برای این گردش کار، هیچ کاهش عملکردی انتظار نمی رود.
برخلاف عملیات استاندارد «Rpc»، اگر اتصال از کار بیفتد یا کارگر راه دور وضعیت خطا را برگرداند، این عملیات استثنا را دوباره افزایش نمیدهد . درعوض، ورودی «کد_وضعیت» و «پیام_وضعیت» برای تماس RPC مربوطه با خطای برگشتی از تماس RPC تنظیم میشود. تانسور «پاسخ» حاوی مقادیر پاسخ معتبر برای ورودیهای کوچک دستهای است که RPCهای آنها شکست نمیخورد. بقیه ورودی ها رشته های خالی خواهند داشت.
کلاس های تو در تو
کلاس | TryRpc.Options | ویژگی های اختیاری برای TryRpc |
ثابت ها
رشته | OP_NAME | نام این عملیات، همانطور که توسط موتور هسته TensorFlow شناخته می شود |
روش های عمومی
استاتیک TryRpc | |
استاتیک TryRpc.Options | failFast (بولی failFast) |
استاتیک TryRpc.Options | پروتکل (پروتکل رشته ای) |
خروجی < TRString > | واکنش () همان شکل «درخواست». |
خروجی < TINT32 > | وضعیت کد () همان شکل «درخواست». |
خروجی < TRString > | پیام وضعیت () همان شکل «درخواست». |
استاتیک TryRpc.Options | timeoutInMs (Long timeoutInMs) |
روش های ارثی
ثابت ها
رشته نهایی ثابت عمومی OP_NAME
نام این عملیات، همانطور که توسط موتور هسته TensorFlow شناخته می شود
روش های عمومی
ایجاد عمومی ایستا TryRpc ( محدوده دامنه ، عملوند < TString > آدرس، عملوند < TString > متد، عملوند < TString > درخواست، گزینهها... گزینهها)
روش کارخانه برای ایجاد کلاسی که عملیات TryRpc جدید را بسته بندی می کند.
مولفه های
محدوده | محدوده فعلی |
---|---|
نشانی | «0-D» یا «1-D». آدرس (یعنی host_name:port) سرور RPC. اگر این تانسور بیش از 1 عنصر داشته باشد، چندین درخواست rpc موازی ارسال می شود. این آرگومان با «روش» و «درخواست» پخش میشود. |
روش | «0-D» یا «1-D». آدرس روش در سرور RPC. اگر این تانسور بیش از 1 عنصر داشته باشد، چندین درخواست rpc موازی ارسال می شود. این آرگومان با «آدرس» و «درخواست» پخش می شود. |
درخواست | «0-D» یا «1-D». رشته های پروتو سریالی شده: آرگومان درخواست rpc. اگر این تانسور بیش از 1 عنصر داشته باشد، چندین درخواست rpc موازی ارسال می شود. این آرگومان با «آدرس» و «روش» پخش می شود. |
گزینه ها | مقادیر ویژگی های اختیاری را حمل می کند |
برمی گرداند
- یک نمونه جدید از TryRpc
عمومی استاتیک TryRpc.Options failFast (Boolean failFast)
مولفه های
شکست سریع | "بولی". اگر «true» (پیشفرض)، پس اتصال ناموفق (یعنی سرور بلافاصله پاسخ نمیدهد) باعث خرابی RPC میشود. |
---|
پروتکل عمومی استاتیک TryRpc.Options (پروتکل String)
مولفه های
پروتکل | پروتکل RPC برای استفاده رشته خالی یعنی از پروتکل پیش فرض استفاده کنید. گزینه ها عبارتند از "grpc". |
---|
خروجی عمومی < TINT32 > statusCode ()
همان شکل «درخواست». مقادیر مربوط به کدهای enum وضعیت تنسورفلو هستند.
خروجی عمومی < TString > پیام وضعیت ()
همان شکل «درخواست». مقادیر مربوط به پیامهای وضعیت برگشتی از تماسهای RPC است.
عمومی استاتیک TryRpc.Options timeoutInMs (Long timeoutInMs)
مولفه های
timeoutInMs | "int". اگر «0» (پیشفرض)، هسته درخواست RPC را اجرا میکند و تنها در صورتی که مهلت RPC بگذرد یا پایان جلسه تمام شود، زمان پایان مییابد. اگر این مقدار بیشتر از «0» باشد، اگر RPC بیشتر از «timeout_in_ms» طول بکشد، عملیات یک استثنا ایجاد میکند. |
---|