פתרון רכיב מתקשר תחת כשל

פתרון התרגיל הראשון

נפריד OperationState לפי request ID מAttemptState לפי attempt ID. תוצאת commit שמאומתת עבור אותה עבודה ואותו תוכן יכולה להיות שימושית גם אם הגיעה מניסיון ישן. היא לא מקבלת סמכות לסגור socket או לשחרר buffer של ניסיון אחר.

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

פתרון התרגיל השני

לקוח ישן מול שרת ישן משתמש בStart. לקוח ישן מול שרת חדש ממשיך להשתמש באותו חוזה, בלי שינוי בIID הישן. לקוח חדש מול שרת חדש מברר את הממשק החדש ומשתמש בdeadline לפי משמעותו המתועדת.

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

פתרון התרגיל השלישי

בחשד לדליפת reference נאסוף מסלול יצירה, בעלי references ורישומי subscriptions או packets. מספר הקצאות גדול בזמן פעילות אינו מספיק; נבדוק אחרי סיום וניתוק. אם האובייקט מוחזק במכוון בcache מוגבל שמתפנה לפי חוזה, הממצא מפריך את הטענה שמדובר בהכרח בדליפה.

בחשד לחסימת STA נאסוף stacks של כל הthreadים וwait graph. אם הSTA מעבד קריאות והעיכוב נמצא בשרת TLS לפני תשובה, נחליף את ההשערה. בחשד לcertificate נבדוק את השם שביקשנו, שרשרת האמון וקוד השגיאה המדויק, בלי להדפיס סודות ובלי לבטל validation. הצלחת TCP אינה מפריכה כשל אימות TLS.