איך מבטיחים סדר הודעות ב-RUD PDC? הסבר למתחילים (כולל דוגמה מוחשית)

במערכות תקשורת יש תופעה טבעית: הודעות לא תמיד מגיעות לפי הסדר שנשלחו.

לדוגמה:

שלחנו: 1 → 2 → 3 אבל נקבל: 2 → 3 → 1

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

אבל האפליקציה חייבת לקבל הכול לפי סדר. לכן UET מספק שתי דרכים ברורות להבטחת סדר.

למה RUD PDC לא מבטיח סדר בעצמו?

כי RUD PDC הוא מנגנון אמין, אבל לא מסודר. הוא מבטיח שהודעה תגיע - לא שהיא תגיע בזמן, או “בסדר”.

ממש כמו חבילות דואר:

• כולן יגיעו
• אבל לא בהכרח אחת אחרי השנייה

UET נועד להוסיף את שכבת הסדר שאינה קיימת.

השיטה הראשונה: Tagged Send

הוספת מספרים לכל הודעה, ואז סידור לפי מספרים

הודעה 1 → מקבלת תג 1 הודעה 2 → מקבלת תג 2 הודעה 3 → מקבלת תג 3

התהליך המקבל:

• בודק את מספר ההודעה
• יודע מה חסר
• יודע מה הגיע מוקדם מדי
• יודע איזה הודעה צריכה להיות הבאה בתור

דוגמה

A שולח:

1. “פתח קובץ” - תג 1
2. “כתוב שורה” - תג 2
3. “סגור קובץ” - תג 3

המקבל יכול לקבל:

• הודעה 2
• הודעה 1
• הודעה 3

אבל לפי התגים - הוא מסדר מחדש:

1 → 2 → 3

וזה בדיוק מה שנמסר לאפליקציה.

השיטה השנייה: Ordering Logic בתוך UET

UET עצמו הופך ל”שוער” שמסדר הכול לפני שהאפליקציה רואה משהו

במקום שהאפליקציה תטפל בסדר:

• UET מחזיק הודעות עד שהכול שלם
• משחרר אותן לפי סדר נכון
• מונע העברת הודעות קדימה כשהסדר לא תקין

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

האפליקציה אפילו לא יודעת שהיה אי-סדר.

דוגמה מוחשית נוספת

בלי UET:

A שולח:

1. “התחל פעולה”
2. “עדכן נתון”
3. “סיים פעולה”

B מקבל בסדר:

• 3
• 1
• 2

האפליקציה עלולה לקרוס.

עם UET:

UET בודק תגים:

“קיבלתי 3, אבל 1 ו-2 עוד לא הגיעו - אעצור רגע”

כשהם מגיעים - UET מארגן מחדש

B מקבל: 1 → 2 → 3

הכול שקוף לאפליקציה.