העברת סגירה-למחצה של TCP לאחר ניקוז הבתים הממתינים

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

שקול לקוח ששולח בקשה, סוגר את צד השליחה שלו וממתין לתשובה:

client -- request, then FIN --> proxy --> service
client <-------- reply ------- proxy <-- service

לפרוקסי יש שני חיבורי TCP ושני זרמי בתים שנעים באופן בלתי תלוי. עליו להעביר הלאה את סימן סוף הקלט, לאחר שהעביר את הבתים שלפניו.

נקז את התור לפני העברת EOF

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

לאחר שנוקז התור מהלקוח אל השירות, קרא ל-shutdown(service_socket, SHUT_WR) על שקע POSIX. זה מסיים שליחה נוספת אל השירות ומשאיר את הכיוון מהשירות אל הלקוח זמין. כשהשירות מסיים את תגובתו, החל את הפעולה המשתקפת לאחר ניקוז תור התגובות.

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

מוכנות היא הזמנה לקרוא

שקע קריא יכול להכיל נתונים או מצב EOF. קרא ל-recv ופרש את התוצאה. ספירות חיוביות הן בתים להעברה; אפס הוא סוף הכיוון. בשקע לא חוסם, EAGAIN או EWOULDBLOCK פירושם שאין כרגע קלט נוסף, ואילו EINTR עשוי לחייב ניסיון חוזר. אף אחד מהם אינו אותו אירוע כמו EOF.

אל תחפש דגל FIN בחוצץ הבתים המוחזר. TCP מספק ל-API הזה זרם בתים מסודר; גבולות מנות וקטע ה-FIN אינם מטען יישום רגיל.

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