עמוד:148

בעיה שנייה : הפרוטוקול מאבד מנות מספור המנות פותר את הבעיה שבה נתקלנו , לכן אפשר לחשוב כי הפרוטוקול , כפי שהוצג , הוא תקין . אך תכנון של פרוטוקולים הוא משימה קשה , הדורשת לתת את הדעת על כל צירוף אפשרי של אירועים . נעבור אפוא לתיאור בעיה נוספת שיכולה להיווצר בפרוטוקול זה . הבעיה שנתאר נובעת משידור חוזר המבוצע לפני הגעת האישור . אין אפשרות להיות בטוחים שזמן ההמתנה , שנקבע לפני ביצוע שידור חוזר , יספיק תמיד . האישור עשוי להתמהמה בגלל עומס אצל המקבל , או בגלל סיבות אחרות , וזמן ההמתנה שהקציב השולח עלול להסתיים לפני הגעת האישור . במקרה כזה , השולח יבצע שידור חוזר , למרות שייתכן כי המנה הקודמת שנשלחה , התקבלה בהצלחה . jNb / j V'Qp i ( R TT ) 0 iei p l < f r > jH b קקאמ . / . ק $ 1-7 X 0 ת 7 > £$ 1 אחד המדדים של רשת התקשורת הוא זמן הלון-ושוב . ( RTT round-trip time ) זהו משך הזמן שהשולח ממתין עד הגעת אישור למנה ששלח . הזמן נקרא "זמן הלוךושוב" משום שהוא כולל את זמן המסע של המנה מהשולח ליעד ואת זמן המסע של האישור בדרך חזרה . כפי שלמדנו בפרק 1 ( ראו סעיף , ( 1 . 2 . 4 מנות עלולות להשתהות ברשת פרק זמן ניכר . כזכור , זמן ההשהיה מורכב מגורמים כמו זמני השידור , השהיות ההתפשטות , זמני עיבוד וזמני המתנה בתורים . דוגמה 3 . 5 לעיל תיארה כיצד אפשר לקבוע את זמן ההמתנה בשכבת הערוץ , משום שבערוץ נל"ן זמן הלוך-ושוב הוא צפוי ויכול להשתנות רק מעט ( בגלל עומסים במחשב שבקצה השני של הערוץ . ( לעומת זה RTT-n של שכבת התובלה עשוי להשתנות באופן ניכר ממנה למנה . כאשר הרשת אינה עמוסה , האישור עשוי להתקבל בתוך כמה מילי-שניות , או אף פחות . כאשר הרשת עמוסה , ייתכן שהאישור יגיע רק אחרי דקות , או שלא יגיע כלל . לכן , קביעת זמן ההמתנה בפרוטוקול שכבת תובלה היא בעייתית . זמן המתנה קצר מדי יגרום לשידורים חוזרים מיותרים . זמן המתנה ארוך מדי יגרום להמתנה ארוכה מדי עד השידור החוזר . בסעיף הבא נלמד כיצד פתרו מתכנני פרוטוקול TCP בעיה זו . נתאר רצף אירועים שבו משתבשת פעולת הפרוטוקול , בגלל המתנה קצרה מדי לפני שידור חוזר ( איור : ( 3 . 11

מטח : המרכז לטכנולוגיה חינוכית


לצפייה מיטבית ורציפה בכותר