gRPC Streaming, Deadline و Backpressure

۱. Streaming یک قرارداد تعامل است، نه نشان «سریع‌تر بودن»

در gRPC یک RPC می‌تواند unary، server-streaming، client-streaming یا bidirectional-streaming باشد. انتخاب درست از نیاز تعامل می‌آید: چه کسی چند پیام تولید می‌کند، آیا دو جهت مستقل‌اند و cancellation یا پایان ناقص چگونه باید مدیریت شود. صرفِ انتخاب streaming هیچ مدرکی برای بهتر بودن performance نیست.

خروجی محدود این درس gRPC Streaming Reliability Record v1 است. برای یک سناریوی local مربوط به inventory باید RPC shape، جهت، deadline صریح، وضعیت slow receiver، مشاهده write، مشاهده cancellation، قانون application buffer/admission، نتیجه محدود و residual risk را ثبت کنید.

۲. سناریوی local

Fixture سه تعامل محدود دارد. GetSnapshot unary است. WatchUpdates server-streaming است: client یک درخواست می‌فرستد و server چند update محدود تولید می‌کند. CommandStream برای تمرین transfer یک stream دوطرفه است که هر دو سمت ممکن است burst تولید کنند.

این درس ادعا نمی‌کند server-streaming همیشه از unary بهتر است. در baseline فقط به این دلیل انتخاب می‌شود که یک درخواست feed را باز می‌کند و server تولیدکننده چند پیام است.

۳. Deadline بخشی از policy فراخوانی است

راهنمای رسمی deadline می‌گوید gRPC به‌صورت پیش‌فرض deadline مفیدی برای شما تعیین نمی‌کند؛ بدون deadline صریح ممکن است client عملاً بی‌نهایت منتظر بماند. پس deadline یک تصمیم application است و باید با evidence latency سیستم اعتبارسنجی شود، نه با یک عدد جهانی.

Fixture یک deadline عادی و یک deadline عمداً کوتاه دارد. قبل از اجرا پیش‌بینی کنید stream کامل می‌شود یا با DEADLINE_EXCEEDED تمام خواهد شد. بعد از اجرا budget تنظیم‌شده و status مشاهده‌شده را جدا ثبت کنید.

۴. Deadline expiry ثابت نمی‌کند همه workها متوقف شده‌اند

دیدن DEADLINE_EXCEEDED در client فقط نشان می‌دهد call از دید آن سمت از deadline عبور کرده است. این موضوع به‌تنهایی ثابت نمی‌کند worker، coroutine، queue task یا downstream callهایی که application ساخته متوقف شده‌اند. server باید cancellation را ببیند و workهای خودش را متوقف کند.

به همین دلیل fixture دو observation جدا دارد: status سمت client و marker مربوط به cleanup/cancellation سمت server. اگر فقط status code ثبت شود evidence ناقص است.

۵. Flow control وظیفه محدودی دارد

Flow control برای streaming RPCها کاربرد دارد و کمک می‌کند sender سریع receiver را از ظرفیتش خارج نکند. Framework ممکن است وقتی receiver ظرفیت ندارد progress را کند کند. برگشت موفق write به این معنی نیست که پیام حتماً روی network رفته یا peer آن را پردازش کرده است.

Learner runtime با پیام‌های بزرگ اما محدود و receiver عمداً کند کار می‌کند و timing مربوط به write/yield را ثبت می‌کند. این observation فقط evidence همین fixture و runtime محلی است، نه تضمین throughput برای همه محیط‌ها.

۶. Transport flow control برابر business admission control نیست

ممکن است transport sender را کند کند ولی application همچنان queue نامحدود، producer کنترل‌نشده یا work غیرقابل‌قبول داشته باشد. بنابراین Lab یک application buffer/admission rule مستقل می‌خواهد. Starter پارامتر queue محدود را نشان می‌دهد اما policy نهایی overload را به‌جای learner انتخاب نمی‌کند.

در record باید این لایه‌ها جدا باشند: flow control در transport، ظرفیت queue در application، admission/rejection دامنه و retry policy. این درس فقط boundary دو مورد اول و یک تصمیم محدود را مالک است.

۷. Cancellation و cleanup

Cancellation می‌تواند صریح، ناشی از deadline یا ناشی از I/O failure باشد. server local بررسی می‌کند RPC هنوز active است یا نه و در صورت cancellation loop کاری خود را متوقف می‌کند. Fixture observation خام cleanup را می‌نویسد ولی آن را به verdict reliability تبدیل نمی‌کند.

در سرویس واقعی که خودش downstream call دارد، propagation هم مهم می‌شود. راهنمای رسمی توضیح می‌دهد جزئیات propagation بین زبان‌ها متفاوت است. این درس رفتار یکسان همه runtimeها را ادعا نمی‌کند.

۸. مرز deadlock در streaming دستی

راهنمای flow control درباره deadlock در patternهای synchronous/manual هشدار می‌دهد؛ مخصوصاً وقتی هر دو سمت زیاد write می‌کنند و read انجام نمی‌دهند. Lab عمداً hang کنترل‌نشده ایجاد نمی‌کند. به‌جای آن یک watchdog محدود، policy «write-heavy/no-read» را شبیه‌سازی می‌کند و اگر در زمان محدود progress ممکن نباشد آن را deadlock risk ثبت می‌کند.

Repair باید read/write discipline باشد، نه صرفاً بزرگ‌تر کردن timeout. در transfer مشخص کنید هر سمت چه زمانی read می‌کند، چه زمانی write دارد و queue/admission محدود چگونه است.

۹. Baseline و probeهای منفی

Baseline از server-streaming feed، deadline صریح واقع‌بینانه، تعداد پیام محدود و receiver نسبتاً سریع استفاده می‌کند. سپس هر بار فقط یک بعد تغییر می‌کند: بدون deadline در برابر deadline کوتاه، receiver کند، cancellation هنگام work فعال و simulation محدود write-heavy/no-read.

تغییر یک بعد در هر probe باعث می‌شود observation قابل نسبت‌دادن باشد. Evidence table هر run را به یک سؤال reliability مشخص وصل می‌کند.

۱۰. Runner چه کاری حق دارد انجام دهد

Runner می‌تواند server disposable روی loopback اجرا کند، probeهای local محدود را انجام دهد و observation خام مثل status، timing، cleanup marker و watchdog result را بنویسد. Runner حق ندارد بگوید production شما safe است، deadline جهانی انتخاب کند یا flow control transport را policy کامل backpressure معرفی کند.

Learner ابتدا باید prediction و decision file را تکمیل کند. بدون آن و بدون --confirm-local runner به‌صورت fail-closed متوقف می‌شود.

۱۱. Evidence Record

برای هر case این ستون‌ها را کامل کنید: RPC Shape / Direction / Deadline / Slow Receiver Condition / Write Observation / Cancellation Observation / Application Buffer/Admission Rule / Result / Residual Risk. Factهای رسمی و observationهای محلی را در آرایه‌های جدا نگه دارید.

یک row خوب دقیق است: «server-streaming؛ deadline برابر 180 ms؛ sleep گیرنده 60 ms برای هر پیام؛ DEADLINE_EXCEEDED مشاهده شد؛ cleanup marker سمت server true؛ queue bound برابر 4؛ bounded failure؛ residual risk: timing فقط evidence grpcio 1.80.0 محلی است.» جمله «backpressure کار می‌کند» evidence کافی نیست.

۱۲. Transfer — Bidirectional Command Stream

در context جدید هر دو سمت ممکن است burst تولید کنند. read/write discipline مستقل، deadline/cancellation behavior و overload rule محدود تعریف کنید. policy server-streaming را بدون reasoning کپی نکنید. در bidi دو جهت مستقل‌اند و طراحی‌ای که هر دو سمت تا پر شدن buffer فقط write کنند و بعد read کنند، همان ریسکی است که باید حذف شود.

Transfer وقتی کامل است که بتوانید rule transport را از policy application جدا توضیح دهید.

۱۳. Freshness و محدودیت‌ها

Source boundary دقیقاً سه صفحه رسمی gRPC است: Core Concepts، Deadlines و Flow Control. در 2026-09-15 دوباره بررسی شدند و برای claimهای این درس material drift دیده نشد. review_due برابر 2026-10-17 است یا زودتر در صورت تغییر material منابع.

این درس production capacity، timing یکسان همه زبان‌ها، deadline بهینه جهانی، durability شبیه broker، exactly-once delivery یا معماری کامل overload control را ثابت نمی‌کند. Runtime evidence محلی عمداً bounded است.