עזרה בתקשורת נתונים - רשתות ואינטרנט - HWzone פורומים
עבור לתוכן
  • צור חשבון

עזרה בתקשורת נתונים

aviaderi

נוצר על ידי aviaderi
ב רשתות ואינטרנט

Recommended Posts

aviaderi Zone Freak

aviaderi

פורסם
פורסם

שלום לכולם,

בקורס תקשורת נתונים נתנו לנו את השאלה הבאה:

עודד הממציא הציע את ההרחבה הבאה לפרוטוקול UDP לה הוא מבקש לקרוא Reliable UDP

מחשב ששולח סדרת חבילות UDP. ימספר אותן במספר סידורי .

מחשב המקבל חבילה מספר I לפני שקיבל חבילה מספרI-1 ישלח חבילת UDP לשולח ובה יבקש שליחה מחדש של חבילה מספר I.

המקבל יצבור את כל החבילות הבאות ולא יעביר אותן הלאה לפני שיקבל את החבילה החסרה.

הסבר לעודד מה תהיה הבעיה בפרוטוקול Reliable UDP במקרה של:

1. אובדן בקשה למשלוח מחודש

2. שברור חבילות

אז לגבי 1 התשובה שאני חושב היא:

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

השאלה שלי היא לגבי 2. לא הסבירו לנו את הנושא (הזכירו את המילה שברור פעמיים לאורך כל הסמסטר), :kopfpatsch: ואני לא מצליח להבין מה הבעייתיות בזה.

תודה למי שיכול לעזור או להפנות אותי לחומר טוב בנושא.

אביעד

קישור לתוכן
שתף באתרים אחרים
pig_750 Zone Freak

pig_750

פורסם
פורסם

משהו לא נראה לי הגיוני פה, אני ינסה להסביר :

נניח שיש 6 סגמנטים שמחשב X רוצה לשלוח למחשב Y , עכשיו בגלל ש ל RUDP (אני יקרא ככה ל Reliable" UDP" מעכשיו)

אין את האפשרות לבצע "תהליך הסכמה" על Sequence Number התחלתי (ISN ) שישמש למספר את הסגמנטים, עודד היה

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

מ 0 - 5 , אוקי אז X שלח אותם והם הגיעו ל Y בסדר הבא: 0 ואז 1 ואז 3 ואז 5 ואז 4 ו2 "נפל" בדרך.

Y "יעבד" אותם פחות או יותר ככה:

0 תאגור >> 1 תאגור >> 3 תאגור >> שלח פאקט עם בקשה ל 3 >> 5 תאגור >> שלח פאקט אם בקשה ל 5 >> 4 תאגור >>

>> 3 (כי הוא ביקש שוב את 3 ) זרוק >> שלח פאקט עם בקשה ל 3 >> 5 זרוק >> שלח פאקט עם בקשה ל 3 >> 3 זרוק >> שלח פאקט עם בקשה ל 3

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

הבעיה פה שאתה מבקש פאקט שכבר יש (I) לך אם הפאקט הקודם לא הגיעה (I-1).

בוא "נשכלל" קצת את התנאי מעכשיו נגיד שאם I מגיע לפני I-1 שלח בקשה ל I-1, אתה בטח חושב שזה הולך להיות הפוטוקול הכי מפגר

שנכתב (ואתה צודק!) אבל לפחות הוא לא יעשה לעצמו denial of service - אז אתה טועה, בוא ניקח את הדוגמה הקודמת:

0 >> תאגור >> 1 תאגור >> 3 תאגור >> שלח פאקט עם בקשה ל 2 >> תאגור את 5 >> שלח פאקט עם בקשה ל 4 >> 4 תאגור >>

2 תאגור >> 4 זרוק

אוקי אז זה נראה כאילו זה עבד, אבל שים לב שצבעתי חלק בכחול וחלק באדום.

מה שצבעתי בכחול זאת דוגמה לחוסר יעילות האדיר שיש ל RUDP , שים לב שביקשנו את 4 למרות שהוא הגיע מיד אחרי 5

ומה שצבעתי באדום זאת "נקודה השבירה" של RUDP ,תחשוב מה היה קורה אם הבקשה ל 2 או התשובה לבקשה שמכילה את 2 ,

לא היו מגיעים, בגלל של RUDP אין מנגנון זמן (לפחות לא שאני יודע על אחד) לא היה קורה כלום, במילים אחרות Y היה

מחכה לסגמנט 2 "לנצח".

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

אני לא מרגיש שיש צורך לפרט.

אני חושב שמדובר ב .packet fragmentation (למה שברור מה רע בפיצול?)

אם מדובר ב packet fragmentation אז זה קשור לשיכבה 3 כלומר ל IP . ו UDP , TCP או במקרה שלנו RUDP לא צריכים

לדאוג לגבי זה כי הם מקבלים את הסגמנט שלם (כמובן אם אין שגיאות ש IP או השכיבה שניה לא גילו).

אני חושב שהוא התכוון לדוגמה עם סגמנט 4 (מה שצבעתי בכחול).

קישור לתוכן
שתף באתרים אחרים

ארכיון

דיון זה הועבר לארכיון ולא ניתן להוסיף בו תגובות חדשות.

עבור לרשימת הדיונים
×
  • צור חדש...