שאלה לגבי פרוטוקול NTP

[jackhammer]

שלום לכולם.

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

מה שקצת לא הבנתי זה הקטע של ה 32/64 ביט של הפרוטוקול.

בעקרון הפרוטוקול עכשיו הוא 64 ביט שמחולקים ל32 ביט עבור השניות ועוד 32 ביט עבור חלקי השניה.

2 בחזקת 32 שניות בחישוב מהיר יוצא 136 שנים.

בגלל שהפרוטוקול הזה מתחיל מ1/1/1900 זה אומר שב 2036 יגמר הטווח של השניות (ובעצם של כל הזמן שהפרוטוקול הזה יכול להציג).

השאלה היא מה בדיוק הולך לקרות?

הבנתי שכבר יש דיבורים של NTP בגרסאת 128 ביט (64 ביט עבור שניות ו64 ביט עבור חלקי השניות).

למה לא חשבו על זה קודם? מה ההבדל (מבחינת כמות עבודה/מאמץ) בין ישום 2 הפרוטוקולים? למה לא עבדו עם ה128 ביט מלכתחילה??

2 בחזקת 64 שניות יוצא 150 ומשהו מליארד שנים (שזה יותר מהגיל של היקום), זתומרת שלא נצטרך לעבור יותר פרוטוקולים.

תודה לעונים.

[yonizaf]

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

אבל האמת היא שדווקא כן חשבו על זה, והפרוטוקול בהחלט יכול לציין תאריכים מוקדמים או מאוחרים יותר. הסיבה היא שהפרוטוקול כולו אינו 64 ביט כפי שציינת, זהו רק גודלו של רכיב הזמן בפרוטוקול. בפועל הפרוטוקול מכיל רכיבים אחרים, ואחד מהם נקרא era number. הרכיב הזה מציין באיזו תקופה של 136 שנים נמצא אותו הזמן. 0 מציין את התקופה הנוכחית שמתחילה ב1900, 1 מציין את התקופה הבאה שמתחילה ב2036 וכן הלאה. כדי לציין תאריך מוקדם יותר אפשר להשתמש גם במספרים שליליים (1- עבור המאה ה19 וכו').

[jackhammer]

הERA NUMBER זה רכיב שכבר עכשיו נכלל בגרסא הקיימת של הNTP? או שצריך לבצע עדכון קטן?

ובIPV4 אומרים שלא חשבו מספיק קדימה כי זה היה נראה ממש ממש ממש רחוק. כנ"ל לגבי 4GB ראם.

זה נראה לי היה הרבה יותר רחוק מ136 שנה עבור פרוטוקול הזמן לא?

אחרי הכל IPV4 הומצא בתחילת ה70... כל הקונספט של רשתות מחשבים היה בגדר של אירגונים עם תקציבי על (אני לא מדבר מנסיון אישי אלא ממה שקראתי).... אז כנראה שאף אחד לא חשב שהדבר הזה יגדל למה שהיום נקרא "אינטרנט"

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

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

[Cheif]

הבעיה בתזמון ה-NTP דומה במהותה לבעית "באג 2038". למזלנו יש עוד כמה שנים טובות עד שבאמת ידרש פתרון לבעיה הזו וסביר להניח שרק לקראת תחילת שנות ה-30 של המאה הזו תתחיל עבודה על הנושא - בדומה למה שהיה לגי באג 2000.

http://he.wikipedia.org/wiki/%D7%91%D7%90%D7%92_2038

[yonizaf]

הERA NUMBER זה רכיב שכבר עכשיו נכלל בגרסא הקיימת של הNTP? או שצריך לבצע עדכון קטן?

עד כמה שידוע לי, זה כלול בגרסה הנוכחית של NTP (שהיא גרסה 4 כמדומני). זה באמת לא משהו שהיה מלכתחילה. זה כמובן אומר שיישומים ישנים יותר של הפרוטוקול לא כוללים את זה, ואם יישארו כאלה עוד 22 שנה ייתכן שאכן תהיה להם בעיה. אם כי, לפחות בחלק מיישומים אלה היה כבר טריק ששימש להארכת הזמן במידה מוגבלת: היות שפרוטוקול NTP מיועד להגדיר את הזמן הנוכחי, הטריק הוא שאם אתה יודע תאריך התחלתי כלשהו (למשל תאריך היצירה של המחשב או התוכנה), אתה יכול לקחת בחשבון שהזמן הנוכחי הוא לא לפני אותו התאריך, ולבצע rollover לתאריך בעצמך, אם הוא מוקדם מדי.

ובIPV4 אומרים שלא חשבו מספיק קדימה כי זה היה נראה ממש ממש ממש רחוק.

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

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

ספר את זה לכל האנשים שיישמו (אפילו בחומרה) תאריך עם שנה של 2 ספרות בשנות ה80 וה90(!), בלי לחשוב שעוד שנים ספורות המערכת שלך כבר לא תעבוד. האמת העצובה היא שאנשים בד"כ פשוט לא חושבים קדימה, לפעמים אפילו לא לשנה הבאה.

הבעיה בתזמון ה-NTP דומה במהותה לבעית "באג 2038". למזלנו יש עוד כמה שנים טובות עד שבאמת ידרש פתרון לבעיה הזו וסביר להניח שרק לקראת תחילת שנות ה-30 של המאה הזו תתחיל עבודה על הנושא - בדומה למה שהיה לגי באג 2000.

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

ורק לציין שברוב מערכות 64 ביט הבעיה כבר לא קיימת, ובחלק ממערכות 32 ביט תוקנה כבר גם כן. סביר להניח שעד שנות ה30 ישארו כבר מעט מאד מערכות ישנות שעדיין זקוקות לתשומת לב (מה שאולי עשוי לגרום למצב הפוך - של חוסר מודעות וסיכוי גבוה יותר לתקלות בפועל)

[jackhammer]

הבעיה בתזמון ה-NTP דומה במהותה לבעית "באג 2038". למזלנו יש עוד כמה שנים טובות עד שבאמת ידרש פתרון לבעיה הזו וסביר להניח שרק לקראת תחילת שנות ה-30 של המאה הזו תתחיל עבודה על הנושא - בדומה למה שהיה לגי באג 2000.

http://he.wikipedia.org/wiki/%D7%91%D7%90%D7%92_2038

מעניין. לא ידעתי שיש גם באג 2038.

אבל לא ממש הבנתי משהו. אם המערכת היא 32 ביט, למה רק 31 ביטים בשימוש?

למה משמש הביט ה32?

ולמה 1 עם 31 אפסים שווה ערך לתאריך של 1901?

[yonizaf]

כי הערך שבו נעשה שימוש הוא מסוג signed, כלומר, עם סימן חיובי/שלילי (-\+). הביט ה32 משמש לסימון אם המספר שלילי. השיטה שבה משתמשים עבור המספרים השליליים היא כנראה two's complement, שבה 1 מוביל והשאר 0 פירושו המספר השלילי הנמוך ביותר, שכמובן מציין את התאריך המוקדם ביותר.

[jackhammer]

כי הערך שבו נעשה שימוש הוא מסוג signed, כלומר, עם סימן חיובי/שלילי (-\+). הביט ה32 משמש לסימון אם המספר שלילי. השיטה שבה משתמשים עבור המספרים השליליים היא כנראה two's complement, שבה 1 מוביל והשאר 0 פירושו המספר השלילי הנמוך ביותר, שכמובן מציין את התאריך המוקדם ביותר.

הבנתי

זתומרת ש1 עם 31 אפסים זה בעצם המקביל השלילי ל32 אפסים?

מעניין.

למדתי משהו חדש

אז למה בעצם שעון צריך לעשות שימוש בזמנים שליליים? למה צריך את הביט הזה לטובת הסימן?

[yonizaf]

מה? לא. 1 עם 31 אפסים זה 2,147,483,648-. הרעיון הוא שאם תהפוך את כל הביטים של המספר, תקבל את המספר השלילי שלו (האמת שזה one's complement, אבל זה כמעט אותו דבר, ואין לי כח להסביר את . Two's complement. אם בא לך תקרא על זה). כלומר, אם 0 עם 31 אחדות זה המספר הגבוה ביותר, אז 1 עם 31 אפסים זה המספר הגבוה ביותר בתוספת סימן מינוס - כלומר בעצם המספר הנמוך ביותר.

למה בחרו להשתמש במשתנה מסוג signed? לא יודע. אולי עצלנות של מתכנתים. אני די משוכנע שהם לא התייחסו אל זה כ"זמנים שליליים" אלא אולי פשוט בחרו משתנה מהסוג הסטנדרטי כי חשבו שזה "לא משנה". וזה באמת לא משנה - זה לא כאילו אם היית משתמש בUnsigned פתאום היה נוסף לך יותר זמן או משהו. כמות המספרים ש32 ביט יכול ליצג נשארת קבועה בכל מקרה.

[needacomp]

עד חלונות 2003 / 7 מיקרוסופט לא מימשה את פרוטקול NTP בתוך חלונות, אלא רק את הפרוטוקול הנחות יותר בשם SNTP...

זה תלוי באיזה שיטת משלים אתה עובד:

http://en.wikipedia.org/wiki/Ones'_complement

http://en.wikipedia.org/wiki/Two's_complement

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

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

[jackhammer]

למה בחרו להשתמש במשתנה מסוג signed? לא יודע. אולי עצלנות של מתכנתים. אני די משוכנע שהם לא התייחסו אל זה כ"זמנים שליליים" אלא אולי פשוט בחרו משתנה מהסוג הסטנדרטי כי חשבו שזה "לא משנה". וזה באמת לא משנה - זה לא כאילו אם היית משתמש בUnsigned פתאום היה נוסף לך יותר זמן או משהו. כמות המספרים ש32 ביט יכול ליצג נשארת קבועה בכל מקרה.

כמות המספרים אכן לא משתנה אבל בגלל שאתה מבזבז ביט אחד על הסימן אז יש לך רק 31 ביטים פונקציונליים לטובת הזמן ומשם בעצם המגבלה של 68 ומשהו שנים (לעומת 136 שנים עם 32 ביטים מלאים - שזה כפול מ31 ביטים)

[needacomp]

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

[jackhammer]

אבל כל הבעיה היא עם החצי השלילי לא?

בגלל זה הוא מחזיר כביכול את התאריך ל1901 לא?

[yonizaf]

לא. גם אם הערך היה unsigned, עדיין היו נגמרים לו המספרים. ההבדל הוא רק במה שהיה קורה בדיוק לערך במצב כזה - במקום לעבור אחורה בזמן, הוא היה נותן שגיאת integer overflow, אלא אם כן השגיאה תטופל באיזשהו אופן (ומה כבר הם יכולים לעשות? לעצור את הזמן? להעביר אחורה בכוונה תחילה?)

[jackhammer]

לא. גם אם הערך היה unsigned, עדיין היו נגמרים לו המספרים. ההבדל הוא רק במה שהיה קורה בדיוק לערך במצב כזה - במקום לעבור אחורה בזמן, הוא היה נותן שגיאת integer overflow, אלא אם כן השגיאה תטופל באיזשהו אופן (ומה כבר הם יכולים לעשות? לעצור את הזמן? להעביר אחורה בכוונה תחילה?)

נכון שכמות המספרים הייתה נגמרת גם ב32 ביט מלאים אבל זה היה קורה אחרי 136 שנים במקום אחרי 68