פתרון פרויקט שירות מקבילי ורשת

הפתרון מתחיל בstate machine של protocol שאינה מכירה את מנגנון ההמתנה. הparser מחזיק progress בין chunks, בודק אורכים לפני הקצאה ומסיים בקשה רק אחרי frame שלם. הtransport מעביר events אל המצב ומקבל ממנו פעולות מוגבלות.

בbackend של epoll, readiness אומרת שניתן לנסות פעולה, ועדיין מטפלים בEAGAIN ובהעברה חלקית. בbackend ישיר של io_uring, הבקשה מחזיקה את הbuffer עד completion. אם משתמשים בPollAdd בלבד, מתעדים שזו השוואת readiness ולא טענה לגבי כל מסלול הI/O.

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

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

הניתוק אחרי effect נבדק עם מזהה בקשה יציב וquery או deduplication לפי חוזה המנוע. הניסיון החוזר עם מזהה חדש אינו פתרון לאותה פעולה. הדוח כולל timeouts וכישלונות לצד האחוזונים כדי שלא ייראה שיפור שמקורו בהעלמת בקשות איטיות.